Re: ext4: possible circular locking dependency at ext4_xattr_inode_create

[Sergey Senozhatsky <senozhatsky@chromium.org>]

Hi Ted,

On (24/11/12 10:29), Theodore Ts'o wrote:
> > I've a following syzkaller report (no reproducer); the report is
> > against 5.15, but the same call-chain seems possible in current
> > upstream as well.  So I suspect that maybe ext4_xattr_inode_create()
> > should take nested inode_lock (I_MUTEX_XATTR) instead.  Does the
> > patch below make any sense?
> 
> These syzkaller reports result from mounting a corrupted (fuzzed) file
> system typically when an inode is used in multiple contexts (e.g., as
> a directory and an EA inode, etc.) at the same time.

I certainly see your point, and I don't argue.

> I'd have to take a closer look to see if it makes sense, but in
> general, very often whenever we try to fix one of these it ends up
> triggering some other syzkaller failure.

I see, the one-liner that I posted sort of looks like an addition to
d1bc560e9a9c7 which landed in ext4 recently.

> And, these sorts of things don't actually result in actual security
> problems (at worst, a hang / denial of service attack), and the right
> thing to do is to just run fsck on the !@#?!? file system before
> mounting the thing.

So in our particular case reboot is a bad scenario.  Looking at reports
from the fleet I see a bunch of hung-task reboots with ext4 frames,
e.g. ext4_update_i_disksize()->down_write()->schedule() /* forever */,
but I can't claim that this is the deadlock that syzkaller has reported,
it very well might not be.