From: "Theodore Tso" <tytso@mit.edu>
To: ????????? <haochengyu@zju.edu.cn>
Cc: security@kernel.org, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ext4: Fix KASAN slab-use-after-free in ext4_find_extent due to corrupted eh_entries
Date: Mon, 1 Dec 2025 22:24:23 -0500 [thread overview]
Message-ID: <20251202032423.GC29113@macsyma.lan> (raw)
In-Reply-To: <1975626f.37736.19ada7d3de4.Coremail.haochengyu@zju.edu.cn>
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
next prev parent reply other threads:[~2025-12-02 3:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-01 15:17 [PATCH] ext4: Fix KASAN slab-use-after-free in ext4_find_extent due to corrupted eh_entries 余昊铖
2025-12-02 3:24 ` Theodore Tso [this message]
2025-12-02 7:45 ` 余昊铖
2025-12-02 8:18 ` Zhang Yi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251202032423.GC29113@macsyma.lan \
--to=tytso@mit.edu \
--cc=haochengyu@zju.edu.cn \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=security@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox