public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Tso" <tytso@mit.edu>
To: 余昊铖 <3230100410@zju.edu.cn>
Cc: security@kernel.org, linux-ext4@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ext4: Fix KASAN use-after-free in ext4_find_extent
Date: Sun, 14 Dec 2025 12:17:30 +0900	[thread overview]
Message-ID: <20251214031730.GA50322@macsyma.local> (raw)
In-Reply-To: <2edd9a0c.3e90f.19b0314cfc8.Coremail.3230100410@zju.edu.cn>

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

  reply	other threads:[~2025-12-14  3:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-09 12:27 [PATCH] ext4: Fix KASAN use-after-free in ext4_find_extent 余昊铖
2025-12-14  3:17 ` Theodore Tso [this message]
2025-12-14  8:52   ` 余昊铖
2025-12-15  1:54 ` Baokun Li
2025-12-15 11:11   ` 余昊铖
2025-12-15 12:42     ` Baokun Li
2025-12-17 15:22       ` 余昊铖
2025-12-18  1:49         ` Baokun Li
2025-12-18  5:42           ` 余昊铖

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=20251214031730.GA50322@macsyma.local \
    --to=tytso@mit.edu \
    --cc=3230100410@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