Message-ID: <f06069a9-6ea6-4ca4-96c0-c78a4006cb27@huaweicloud.com>
Date: Tue, 2 Dec 2025 16:18:15 +0800
From: Zhang Yi <yi.zhang@...weicloud.com>
To: 余昊铖 <3230100410@....edu.cn>,
 Theodore Tso <tytso@....edu>
Cc: security@...nel.org, linux-ext4@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ext4: Fix KASAN slab-use-after-free in ext4_find_extent
 due to corrupted eh_entries

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@...-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

Powered by blists - more mailing lists