Message-ID: <22942473.381f6.19ade05fca6.Coremail.3230100410@zju.edu.cn>
Date: Tue, 2 Dec 2025 15:45:25 +0800 (GMT+08:00)
From: 余昊铖 <3230100410@....edu.cn>
To: "Theodore Tso" <tytso@....edu>
Cc: security@...nel.org, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH] ext4: Fix KASAN slab-use-after-free in
 ext4_find_extent due to corrupted eh_entries

Hi,

Thank you for your advice. For the reproduction, I can trigger 'BUG: KASAN: slab-use-after-free in ext4_find_extent' on my computer stably using the original reproducer. And I only modified a few options in the kernel config(the exact kernel config is in the attachments):


CONFIG_KCOV=y
 
CONFIG_DEBUG_INFO_DWARF4=y
 
CONFIG_KASAN=y
CONFIG_KASAN_INLINE=y
 
CONFIG_CONFIGFS_FS=y
CONFIG_SECURITYFS=y

CONFIG_VIRTIO_NET=y
CONFIG_E1000=y
CONFIG_E1000E=y
 
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="net.ifnames=0"


And I run the reproducer in qemu with command:


sudo qemu-system-x86_64 \
  -m 2G \
  -smp 2 \
  -kernel /mushome/lizao/patch/linux-6.12.51/arch/x86/boot/bzImage \
  -append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0 panic_on_warn=1 panic_on_oops=1" \
  -drive file=/mushome/lizao/patch/image/bullseye.img,format=raw \
  -net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
  -net nic,model=e1000 \
  -enable-kvm \
  -nographic \
  -pidfile vm.pid \
  2>&1 | tee vm.log


So I think something went wrong when I simplified the reproducer. Sorry for my mistake.

And for the deeper analysis, in ext4_iget() (fs/ext4/inode.c), we only call ext4_ext_check_inode() if the inode does not have inline 
data. But the malicious image sets both EXT4_INODE_EXTENTS and EXT4_INLINE_DATA on inode #15. This combination is normally contradictory, but ext4 accepts it, so the inline-data guard short-circuits the extent sanity check entirely. Because of that, the extent root stored inside i_block is never validated even though this inode is later treated as an extent-based regular file. When ext4_find_extent() runs, it trusts the forged header (eh_entries >> eh_max) and calls ext4_ext_binsearch(), which in turn uses EXT_LAST_EXTENT() and walks well past the inline i_block area. The pointers land in unrelated slab objects and trigger the KASAN slab-UAF you saw.

The core bug is that ext4 permits EXT4_INLINE_DATA and EXT4_INODE_EXTENTS to coexist without revalidating the inline extent tree. A crafted inode can therefore bypass __ext4_ext_check(), poison eh_entries, and later crash the kernel as soon as any extent traversal occurs.

Hope this clarifies the root cause and why my patch is validate. Thanks.


> On Mon, Dec 01, 2025 at 11:17:12PM +0800, ????????? wrote:
> > Hello,
> > 
> > I would like to report a potential security issue in the Linux
> > kernel ext4 filesystem, which I found using a modified
> > syzkaller-based kernel fuzzing tool that I developed.
> 
> Thank you for submitting this bug report, and thank you for doing the
> work to create a simplified reproducer and doing the initial analysis.
> It is much appreciated.  Unfortunately, I haven't been able to
> reproduce the issue.  You didn't send me the exact kernel config that
> you used, so I used my default kernel config that I use by testing
> via:
> 
> % install-kconfig --kasan
> % kbuild
> 
> ... using the kvm-xfstests utilities that can be found at [1], in the
> kernel-build directory.
> 
>        https://github.com/tytso/xfstests-bld
> 
> I tried using both the latest mainline kernel, as well as 6.12.51,
> this that was your reported that you were doing your testing.
> 
> % kvm-xfstests shell
>     ...
> root@...-xfstests:~# uname -a 
> Linux kvm-xfstests 6.18.0-rc7-xfstests-kasan-01168-g7b2a79c93971 #312 SMP PREEMPT_DYNAMIC Mon Dec  1 21:30:56 EST 2025 x86_64 GNU/Linux
> root@...-xfstests:~# cd /vtmp/   
> root@...-xfstests:/vtmp# ./repro_simplified 
> [*] Using loop device: /dev/loop0
> [   14.949088] loop0: detected capacity change from 0 to 512
> [   14.953285] EXT4-fs warning (device loop0): ext4_multi_mount_protect:324: MMP interval 42 higher than expected, please wait.
> [   14.953285] 
> [   59.461261] EXT4-fs (loop0): warning: mounting unchecked fs, running e2fsck is recommended
> [   59.463299] EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: writeback.
> [*] Mounted image.img to ./mnt
> [*] Triggering bug...
> [*] sendfile returned: 170
> [*] Done. If kernel didn't crash, the repro finished.
> root@...-xfstests:/vtmp# 
> 
> So I then took a look at the code in question, and at your proposed
> patch.  If you could do some more analysis, please take a look at all
> of the checks done by the function __ext4_ext_check(), which
> implements the checks in the functions ext4_ext_check_inode() and
> ext4_ext_check().  These functions get called when the inode is read
> into memory (for the root extent tree in the inode) or when an extent
> tree block is read into memory.
> 
> So I'm not sure why your patch would make a difference --- and given
> that your simplified reproducer isn't triggering the crash, even when
> KASAN is enabled, I can't validate whether your patch *would* make a
> difference.
> 
> Could you try to do a deeper analysis?   Thanks,
> 
> 						- Ted

Download attachment ".config" of type "application/octet-stream" (143369 bytes)

View attachment "repro.c" of type "text/plain" (28486 bytes)

Powered by blists - more mailing lists