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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251202032423.GC29113@macsyma.lan>
Date: Mon, 1 Dec 2025 22:24:23 -0500
From: "Theodore Tso" <tytso@....edu>
To: ????????? <haochengyu@....edu.cn>
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

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