linux-kernel - Re: [PATCH] ext4: Fix KASAN use-after-free in ext4_find

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: <20251214031730.GA50322@macsyma.local>
Date: Sun, 14 Dec 2025 12:17:30 +0900
From: "Theodore Tso" <tytso@....edu>
To: 余昊铖 <3230100410@....edu.cn>
Cc: security@...nel.org, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ext4: Fix KASAN use-after-free in ext4_find_extent

Thank you for your report.

However, I am not sure we fully understand the true root cause of the
problem.  The inode's root extent tree header is checked when the
inode is first read from disk, in __ext4_iget():

			if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))
				ret = ext4_ext_check_inode(inode);
			else
				ret = ext4_ind_check_inode(inode);

And ext4_ext_check_inode() does basically what your patch adds:

int ext4_ext_check_inode(struct inode *inode)
{
	return ext4_ext_check(inode, ext_inode_hdr(inode), ext_depth(inode), 0);
}

So it looks like when the inode is originally read from the file
system, it is not corruptd.  This is consistent with your finding that
the crafted file system had no corruptions reported by fsck.

What this implies is that somehow the root node of the extent tree is
getting corrupted by the kernel code --- and that's very concerning,
and we should fix _that_, since (a) constantly checking the root
extent tree node every single time we do an extent tree lookup is
extra overhead, and (b) if something is corrupting the extent tree,
_not_ corrupting the file system as opposed to noticing that the file
system has gotten corrupted and then declaring the file system is
corrupted requiring that the file system needs to be fixed by fsck.ext4.

If you have time to do that further investigation, I would really
appreiciate it.  Otherwise, I'll schedule time to do that deeper
investigation in the next few weeks.

By the way, the patch that you included was white-space corrupted,
probably by your mail client (presumably, gmail?).  One way to avoid
this is to attach the patch as a file, or send it separately using git
send-email.  See the [1] for more details.

[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html

Thanks,

						- Ted