[lvc-project] [PATCH 6.1 14/29] xfs: use xfs_defer_pending objects to recover intent items

[Fedor Pchelkin]

On Fri, 21. Mar 10:42, Leah Rumancik wrote:
> Hey Fedor,
> 
> Thanks a bunch for the report! I don't see xfs/235 running on my
> setup. I will look into why and see if I can repro.
> 
> Few questions,
> 
> Were you able to confirm that e5f1a5146ec3 fixes the issue on 6.1.y?

Oh, it probably wasn't obvious from my initial report but the problem
concerns only 6.1.132-rc1 at the moment. It's in testing phase and hasn't
been finally released yet. So it hasn't reached 6.1.y.

Unfortunately, it's hard to port the proposed fix directly on top of
6.1.132-rc1 since it depends on a number of non-trivial changes done in
mainline. The conflicts are huge and require a solid amount of expertise
in the code and I'm not ready to do this to be honest.

Well, as I perceive, the reason to port the following patches

[PATCH 6.1 13/29] xfs: don't leak recovered attri intent items
[PATCH 6.1 14/29] xfs: use xfs_defer_pending objects to recover intent items
[PATCH 6.1 15/29] xfs: pass the xfs_defer_pending object to iop_recover
[PATCH 6.1 16/29] xfs: transfer recovered intent item ownership in ->iop_recover

to stable (6.1, in particular) is to fix a UAF when intent recovery fails.
This is stated in upstream patchset [1] where the patches come from.

[1]: https://lore.kernel.org/linux-xfs/170191741007.1195961.10092536809136830257.stg-ugh@frogsfrogsfrogs/

Taking as a fact that 6.1.y is vulnerable to that bug (though I failed
to find an exact blamed commit), I think that the whole series of 8
patches should be ported, otherwise it looks not complete. But only 4/8
patches have been taken to 6.1-queue and 6.6 so far.

> If so, we can just port this patch, otherwise we might want to drop
> the xfs set while we investigate further.

I'd suggest to drop the xfs set from 6.1-queue for now until the problem
is addressed in some way.

> 
> Also, the backport set you mentioned was based on a set from 6.6.y. I
> don't see the suggested fix (e5f1a5146ec3) there either. If it's not
> too much hassle, could you see if we have the same problem for 6.6.y
> as well?

Yes, the crash occurs there, too. And for 6.6 case it actually is for a
released kernel (since v6.6.24).

The remaining four patches of the original upstream series [1] - one of
which is e5f1a5146ec3 - can be applied there without many problems,
fortunately.

I'll send them to you in a separate thread.