From: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
To: linux-ext4@vger.kernel.org
Cc: tytso@mit.edu, Andreas Dilger <adilger.kernel@dilger.ca>,
Baokun Li <libaokun@linux.alibaba.com>, Jan Kara <jack@suse.cz>,
Ojaswin Mujoo <ojaswin@linux.ibm.com>,
"Ritesh Harjani" <ritesh.list@gmail.com>,
Zhang Yi <yi.zhang@huawei.com>,
Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>,
stable@vger.kernel.org, Simon Brakhane <simon@brakhane.net>
Subject: [PATCH] ext4: validate inode block references during fast commit replay
Date: Mon, 26 Oct 2026 12:48:53 -0400 [thread overview]
Message-ID: <20261026164853.3125835-1-hamzamahfooz@linux.microsoft.com> (raw)
__ext4_iget() currently skips ext4_ext_check_inode() and
ext4_ind_check_inode() when EXT4_FC_REPLAY is set in s_mount_state.
As a result, an extent-mapped inode loaded from disk during fast commit
replay never has its in-inode extent header or root extent entries
validated before replay paths such as ext4_fc_replay_inode() and
ext4_fc_replay_add_range() walk or modify i_data[].
A crafted filesystem image with a fast commit journal and an inode whose
eh_max / eh_entries exceed the four-extent capacity of i_data[] triggers
slab-out-of-bounds reads in ext4_cache_extents() and slab-out-of-bounds
writes in ext4_ext_insert_extent() into adjacent fields of struct
ext4_inode_info and beyond the ext4_inode_cache slab allocation.
ext4_ext_check_inode() and ext4_ind_check_inode() only validate the
in-inode extent header and check block numbers against static superblock
bounds via ext4_inode_block_valid(), not block allocation bitmaps. So,
drop the EXT4_FC_REPLAY exemption in __ext4_iget() so inodes read during
fast commit replay are validated.
Cc: stable@vger.kernel.org
Reported-by: Simon Brakhane <simon@brakhane.net>
Fixes: 8016e29f4362 ("ext4: fast commit recovery path")
Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
---
fs/ext4/inode.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 26f0f9714f03..cf74c5014fa7 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5582,10 +5582,9 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
goto bad_inode;
} else if (!ext4_has_inline_data(inode)) {
/* validate the block references in the inode */
- if (!(EXT4_SB(sb)->s_mount_state & EXT4_FC_REPLAY) &&
- (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
- (S_ISLNK(inode->i_mode) &&
- !ext4_inode_is_fast_symlink(inode)))) {
+ if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
+ (S_ISLNK(inode->i_mode) &&
+ !ext4_inode_is_fast_symlink(inode))) {
if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))
ret = ext4_ext_check_inode(inode);
else
--
2.56.0
next reply other threads:[~2026-10-26 16:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 16:48 Hamza Mahfooz [this message]
2026-10-26 17:07 ` [PATCH] ext4: validate inode block references during fast commit replay sashiko-bot
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=20261026164853.3125835-1-hamzamahfooz@linux.microsoft.com \
--to=hamzamahfooz@linux.microsoft.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=libaokun@linux.alibaba.com \
--cc=linux-ext4@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=simon@brakhane.net \
--cc=stable@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=yi.zhang@huawei.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.