linux-kernel - Re: 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: <7b332aba.423bc.19b1c102253.Coremail.3230100410@zju.edu.cn>
Date: Sun, 14 Dec 2025 16:52:58 +0800 (GMT+08:00)
From: 余昊铖 <3230100410@....edu.cn>
To: "Theodore Tso" <tytso@....edu>
Cc: security@...nel.org, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH] ext4: Fix KASAN use-after-free in ext4_find_extent

Thank you for your detailed feedback and insights.

I will continue with the further investigation of this bug. However, I must admit that I've encountered great difficulty here. Given this challenge, I would greatly appreciate it if you could also schedule some time for this investigation. I believe your guidance could help us find the true root cause much more efficiently.

Regarding the patch, I apologize for the white-space corruption. The patch is now attached as a file in this mail.

Thanks again,
Haocheng Yu


> 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

Download attachment "ext4_find_extent.patch" of type "application/octet-stream" (1644 bytes)