Re: [PATCH] ext4: Fix KASAN slab-use-after-free in ext4_find_extent due to corrupted eh_entries

Zhang Yi
2025-12-02T08:18:26Z

Hello!

On 12/2/2025 3:45 PM, 余昊铖 wrote:
> 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.

Thank you for your thorough and detailed analysis. I suppose this bug
have been fix by Deepanshu in commit 1d3ad183943b3 ("ext4: detect
invalid INLINE_DATA + EXTENTS flag combination"). Please try this
commit.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=1d3ad183943b3

Regard,
Yi.

>
>
>> 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@kvm-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@kvm-xfstests:~# cd /vtmp/
>> root@kvm-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@kvm-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