All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+9db318d6167044609878@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Forwarded: [PATCH] ext4: add defensive checks for extent header corruption
Date: Tue, 30 Sep 2025 15:49:38 -0700	[thread overview]
Message-ID: <68dc5e82.050a0220.25d7ab.0768.GAE@google.com> (raw)
In-Reply-To: <68335d8e.a70a0220.253bc2.008b.GAE@google.com>

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] ext4: add defensive checks for extent header corruption
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

syzbot reported use-after-free bugs when accessing extent headers in
multiple locations. Testing revealed crashes in both ext4_ext_map_blocks()
and ext4_ext_correct_indexes() where extent headers or paths contain
invalid data.

The crashes occur when:
1. In ext4_ext_map_blocks(): After ext4_find_extent() returns, the extent
   header at path[depth] can be corrupted
2. In ext4_ext_correct_indexes(): The path structure itself may be invalid
   when accessed at path[depth]

These issues are more easily triggered after commit 665575cff098 ("filemap:
move prefaulting out of hot write path") which changed timing in write
paths, though the underlying vulnerability appears to be pre-existing.

Add defensive validation checks:
- In ext4_ext_map_blocks(): Validate extent header magic after getting path
- In ext4_ext_correct_indexes(): Check path validity before dereferencing

These checks prevent crashes but don't address the root cause of how
these structures become corrupted. Further investigation is needed for
a complete fix.

Reported-by: syzbot+9db318d6167044609878@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9db318d6167044609878
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/ext4/extents.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index ca5499e9412b..04d2328ee1d4 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -1708,7 +1708,8 @@ static int ext4_ext_correct_indexes(handle_t *handle, struct inode *inode,
 	struct ext4_extent *ex;
 	__le32 border;
 	int k, err = 0;
-
+	if (!path || depth < 0 || depth > EXT4_MAX_EXTENT_DEPTH)
+		return -EFSCORRUPTED;
 	eh = path[depth].p_hdr;
 	ex = path[depth].p_ext;
 
@@ -4200,19 +4201,26 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
 	unsigned int allocated_clusters = 0;
 	struct ext4_allocation_request ar;
 	ext4_lblk_t cluster_offset;
+	struct ext4_extent_header *eh;
 
 	ext_debug(inode, "blocks %u/%u requested\n", map->m_lblk, map->m_len);
 	trace_ext4_ext_map_blocks_enter(inode, map->m_lblk, map->m_len, flags);
-
+	depth = ext_depth(inode);
+	if (depth == 0)
+		eh = ext_inode_hdr(inode);
+	else
+		eh = path[depth].p_hdr;
+	if (!eh || le16_to_cpu(eh->eh_magic) != EXT4_EXT_MAGIC) {
+		EXT4_ERROR_INODE(inode, "invalid extent header at depth %d", depth);
+		err = -EFSCORRUPTED;
+		goto out;
+	}
 	/* find extent for this block */
 	path = ext4_find_extent(inode, map->m_lblk, NULL, flags);
 	if (IS_ERR(path)) {
 		err = PTR_ERR(path);
 		goto out;
 	}
-
-	depth = ext_depth(inode);
-
 	/*
 	 * consistent leaf must not be empty;
 	 * this situation is possible, though, _during_ tree modification;
-- 
2.43.0


  parent reply	other threads:[~2025-09-30 22:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-25 18:12 [syzbot] [ext4?] KASAN: use-after-free Read in ext4_ext_insert_extent syzbot
2025-05-26 14:53 ` syzbot
2025-09-30 15:20 ` Forwarded: [PATCH] ext4: fix use-after-free in ext4_ext_insert_extent() syzbot
2025-10-01 23:11   ` kernel test robot
2025-09-30 20:57 ` Forwarded: [PATCH] ext4: fix use-after-free in extent header access syzbot
2025-09-30 22:05 ` syzbot
2025-09-30 22:49 ` syzbot [this message]
2025-09-30 23:09 ` Forwarded: [PATCH] ext4: add validation checks for corrupted extent headers syzbot
2025-10-01  0:10 ` syzbot

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=68dc5e82.050a0220.25d7ab.0768.GAE@google.com \
    --to=syzbot+9db318d6167044609878@syzkaller.appspotmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.