Re: SYZKALLER BUG: messing with a mounted file system via loop ioctls (was: Re: [PATCH] ext4: add bounds check in ext4_xattr_ibody_get() to) prevent out-of-bounds access

[Dmitry Vyukov]

On Sat, 28 Mar 2026 at 16:02, Deepanshu Kartikey <kartikey406@xxxxxxxxx> wrote:
>
> On Fri, Mar 27, 2026 at 10:01 PM Theodore Tso <tytso@xxxxxxx> wrote:
> >
> > On Fri, Mar 27, 2026 at 08:02:30PM +0530, Deepanshu Kartikey wrote:
> > >
> > > Thank you for the review. I tried moving the fix to check_xattrs()
> > > as you suggested, but the syzbot reproducer still crashes. I added
> > > printk statements to trace the code path and found the root cause.
> > >
> > > The issue is that __xattr_check_inode() runs once during ext4_iget(),
> > > but ext4_xattr_ibody_get() re-reads the inode from disk via
> > > ext4_get_inode_loc() on every call. The reproducer exploits this by
> > > shrinking the loop device after mount, causing the re-read to return
> > > corrupted data.
> >
> > I consider this more a defect in Syzkaller than in ext4.  Syzkaller
> > already unsets CONFIG_BLK_DEV_WRITE_MOUNTED because modifying a
> > mounted file system is not considered a valid security concern.
> > Unfortunately, the syzkaller fuzzer which corrupts a mounted file
> > system by messing with a loop device using a privileged ioctl bypasses
> > !CONFIG_DEV_BLK_WRITE_MOUNTED.
> >
> > I'll accept a change to add a to check_xattrs(), which will protect
> > against static corruptions, but adding an extra check to a hotpath
> > (this would slow down SELinux, which aggressively needs to read the
> > file's sid) to protect against a corruption issue which requires root
> > privs is not something I'm interested in.
> >
> > My priority is improving ext4 --- not reducing the syzkaller reports
> > against ext4 to zero, since there are false positives like this.  For
> > people who care about reducing the syzkaller report gamification, my
> > suggestion is to either extend CONFIG_BLK_DEV_WRITE_MOUNTED to prevent
> > these loop device reconfiguration while a file system is mounted on
> > that loop device, or to fix syzkaller to not create fuzzers like this.

Hi Ted,

Thanks for the report.

https://syzkaller.appspot.com/text?tag=ReproSyz&x=17a43b3a580000

Do you mean LOOP_SET_STATUS64 ioctl? It's the only ioctl in the repro:

ioctl$LOOP_SET_STATUS64(r0, 0x4c04, ...)

Does it mean it should also be prohibited under
CONFIG_BLK_DEV_WRITE_MOUNTED to avoid kernel memory corruption?
Or at least some changes should be prohibited? E.g. I guess changing
lo_offset is equivalent to writing to the mounted device.