linux-kernel - Re: [SECURITY] ext4: KASAN use-after-free and Oops in ext4_xattr_set

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] [day] [month] [year] [list]

Message-ID: <20251106140930.GC826105@mit.edu>
Date: Thu, 6 Nov 2025 09:09:30 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: Greg KH <greg@...ah.com>
Cc: 章怿贺 <12421252@....edu.cn>, security@...nel.org,
        linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [SECURITY] ext4: KASAN use-after-free and Oops in
 ext4_xattr_set_entry with crafted ext4 image

On Thu, Nov 06, 2025 at 05:50:35PM +0900, Greg KH wrote:
> 
> > I ran e2fsck -fn on the extracted image and it does report errors
> > (including “padding at end of block bitmap is not set”), so it seems
> > fsck already detects the corruption. Next time I will evaluate the
> > impact more carefully before contacting the Linux community again.
> 
> That's great to hear, but I'm sure the ext4 developers would still
> appreciate a kernel patch for this if you have one :)

A couple of other things.  First of all, when you send a report which
involves a corrupted file system, please include a copy of the
corrupted file system so the file system developers don't have to
waste a lot of time digging it out of the poc.c file.  For reports
from the upstream syzkaller, developers use syzbot website too
download artifiacts like the corrupted file system, and in cases where
they can't reproduce the problem, they can request that the syzbot
test a proposed patch for them.

One of the problems with academic researchers sending reports from
forked syzkallers is that they often don't stand up the webserver,
which causes a lot of extra effort from upstream maintainers from
responding.

I did spend an hour or so trying to pry out out the image, and took a
look at it long enough to confirm that indeed, the file system was
corrupted and so it's very low priority for me to debug it --- since
as Greg has pointed out, if you can mount a file system, in general
you're asking for problems.  Sure, you can disable setuid programs,
et. al, but for a **long** time, the block device is considered part
of the trust boundary.

Yes, there are some particularly bone-headed decisions made by certain
distributions, such as Red Hat mounting file systems whenever someone
is stupid enough to insert a USB stick (scattered in the parking lot
of the targetted defense contractor by the MSS or the CIA) in their
laptop.  This is **why* e2fsprogs and xfsprogs ships udev rules which
override that particular bit of product-manager driven stupidity.  (I
wlil note that most enterprise sysadmins already disable USB mounts.)
But if someone really wants to do that stupid thing, they should send
us patches; it's not high priority for me to fix.

That being said, it does look that e2fsck doesn't actually fix the
problem.  The issue seems to be a maliciously corrupted inode with
bogus extended attributes inline in the inode structure.  There are
other things corrupted by syzkaller, including block bitmap padding,
but it's not really relevant for the reproducer.

If you want to save time for the upstream maintainer, please try to
minimize the reproducer.  That means removing irrelevant bits from the
file system image, and those bits of the reproducer which is
completely irrelevant.  I'll try to take a look at it later, when I
have free time.  But if you'd like to help me, try to create a minimal
reproducer.

Cheers,

						- Ted