Linux EXT4 FS development
 help / color / mirror / Atom feed
* [PATCH v3] ext4: validate extent root during fast commit replay
@ 2026-11-09 22:12 Jérémy Jean
  2026-11-09 22:32 ` sashiko-bot
  0 siblings, 1 reply; 2+ messages in thread
From: Jérémy Jean @ 2026-11-09 22:12 UTC (permalink / raw)
  To: tytso
  Cc: Andreas Dilger, Baokun Li, Jan Kara, Ojaswin Mujoo,
	Ritesh Harjani, Zhang Yi, linux-ext4, linux-kernel,
	Jérémy Jean, stable

Fast commit replay skips extent tree validation in ext4_iget(). The
replay code then reads and updates the extent root stored in i_data
without validating its header.

The root has space for four extents. A corrupt header with eh_entries
set to 4 and eh_max set to 5 lets replay insert a fifth extent past
the end of i_data, which overwrites other fields in struct
ext4_inode_info.

Check the root in ext4_find_extent() during fast commit replay. Skip
extent replay helpers for non-extent inodes and clear the replay state
before loading the root inode.

Fixes: 8016e29f4362 ("ext4: fast commit recovery path")
Cc: stable@kernel.org
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
---

Changes in v3:
- Skip extent replay helpers for non-extent inodes.
- Clear EXT4_FC_REPLAY before loading the root inode.

Changes in v2:
- Validate replay roots regardless of EXT4_INODE_EXTENTS.
- Rebase on fa4ad798f6f6.

v2: https://lore.kernel.org/all/20261108201906.1417129-2-Jeremy.Jean@oss.cyber.gouv.fr/
v1: https://lore.kernel.org/all/20260821100559.3612643-2-Jeremy.Jean@oss.cyber.gouv.fr/

 fs/ext4/extents.c     | 8 +++++++-
 fs/ext4/fast_commit.c | 4 ++--
 fs/ext4/super.c       | 3 +--
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index ad0d80e33f609..aec75a680bcc7 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -905,6 +905,12 @@ ext4_find_extent(struct inode *inode, ext4_lblk_t block,
 		ret = -EFSCORRUPTED;
 		goto err;
 	}
+	/* ext4_iget() skips extent validation during fast commit replay. */
+	if (unlikely(EXT4_SB(inode->i_sb)->s_mount_state & EXT4_FC_REPLAY)) {
+		ret = ext4_ext_check(inode, eh, depth, 0);
+		if (ret)
+			goto err;
+	}
 
 	if (path) {
 		ext4_ext_drop_refs(path);
@@ -6391,7 +6397,7 @@ int ext4_ext_clear_bb(struct inode *inode)
 	int j, ret = 0;
 	struct ext4_map_blocks map;
 
-	if (ext4_test_inode_flag(inode, EXT4_INODE_INLINE_DATA))
+	if (!ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))
 		return 0;
 
 	/* Determin the size of the file first */
diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
index 0cac890cf3702..b883ce015c303 100644
--- a/fs/ext4/fast_commit.c
+++ b/fs/ext4/fast_commit.c
@@ -2002,7 +2002,7 @@ static int ext4_fc_replay_inode(struct super_block *sb,
 	 * crashing. This should be fixed but until then, we calculate
 	 * the number of blocks the inode.
 	 */
-	if (!ext4_test_inode_flag(inode, EXT4_INODE_INLINE_DATA))
+	if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))
 		ext4_ext_replay_set_iblocks(inode);
 
 	inode->i_generation = le32_to_cpu(ext4_raw_inode(&iloc)->i_generation);
@@ -2334,7 +2334,7 @@ static void ext4_fc_set_bitmaps_and_counters(struct super_block *sb)
 		}
 		cur = 0;
 		end = EXT_MAX_BLOCKS;
-		if (ext4_test_inode_flag(inode, EXT4_INODE_INLINE_DATA)) {
+		if (!ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) {
 			iput(inode);
 			continue;
 		}
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 9cae52471dee9..8dac2c1cea78a 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -5660,6 +5660,7 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
 	 * The jbd2_journal_load will have done any necessary log recovery,
 	 * so we can safely mount the rest of the filesystem now.
 	 */
+	ext4_fc_replay_cleanup(sb);
 
 	root = ext4_iget(sb, EXT4_ROOT_INO, EXT4_IGET_SPECIAL);
 	if (IS_ERR(root)) {
@@ -5699,8 +5700,6 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
 			goto failed_mount4a;
 		}
 	}
-	ext4_fc_replay_cleanup(sb);
-
 	ext4_ext_init(sb);
 
 	/*
-- 
2.47.3


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH v3] ext4: validate extent root during fast commit replay
  2026-11-09 22:12 [PATCH v3] ext4: validate extent root during fast commit replay Jérémy Jean
@ 2026-11-09 22:32 ` sashiko-bot
  0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-11-09 22:32 UTC (permalink / raw)
  To: Jérémy Jean; +Cc: linux-ext4, tytso

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] ext4: ignored extent check errors in ext4_fc_replay_inode()
- [Medium] ext4: missing EXT4_INODE_EXTENTS check in fast commit range
  replay
--

commit c7e3408ccbd89c7e858695dd9961091a529765cf
Author: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>

ext4: validate extent root during fast commit replay

This commit validates the root extent header in ext4_find_extent() during
fast commit replay, skips extent replay helpers when EXT4_INODE_EXTENTS is
not set, and clears EXT4_FC_REPLAY before loading the root inode.

> diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
> index 0cac890cf3702..b883ce015c303 100644
> --- a/fs/ext4/fast_commit.c
> +++ b/fs/ext4/fast_commit.c
> @@ -2002,7 +2002,7 @@ static int ext4_fc_replay_inode(struct super_block *sb,
>  	 * crashing. This should be fixed but until then, we calculate
>  	 * the number of blocks the inode.
>  	 */
> -	if (!ext4_test_inode_flag(inode, EXT4_INODE_INLINE_DATA))
> +	if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))
>  		ext4_ext_replay_set_iblocks(inode);
>  
>  	inode->i_generation = le32_to_cpu(ext4_raw_inode(&iloc)->i_generation);

[Severity: Medium]
Should ext4_fc_replay_inode() check the return values of
ext4_ext_clear_bb() and ext4_ext_replay_set_iblocks()?

When the new ext4_ext_check() in ext4_find_extent() rejects a corrupt root
extent header with valid eh_magic (such as eh_entries = 4 and eh_max = 5),
both helpers return -EFSCORRUPTED, but ext4_fc_replay_inode() ignores the
error, computes a valid checksum over the corrupt i_block via
ext4_inode_csum_set(), and writes the inode to disk.

> @@ -2334,7 +2334,7 @@ static void ext4_fc_set_bitmaps_and_counters(struct super_block *sb)
>  		}
>  		cur = 0;
>  		end = EXT_MAX_BLOCKS;
> -		if (ext4_test_inode_flag(inode, EXT4_INODE_INLINE_DATA)) {
> +		if (!ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) {
>  			iput(inode);
>  			continue;
>  		}

[Severity: Medium]
Do ext4_fc_replay_add_range() and ext4_fc_replay_del_range() also need to
verify EXT4_INODE_EXTENTS before replaying range tags?

If an EXT4_FC_TAG_ADD_RANGE or EXT4_FC_TAG_DEL_RANGE tag targets an inode
without EXT4_INODE_EXTENTS set, ext4_map_blocks() dispatches to
ext4_ind_map_blocks() while the subsequent calls (ext4_find_extent(),
ext4_ext_insert_extent(), ext4_ext_replay_update_ex(),
ext4_ext_remove_space(), and ext4_ext_replay_shrink_inode()) treat i_data
as an extent tree.

In ext4_fc_replay_del_range(), any blocks reported mapped by
ext4_ind_map_blocks() are cleared in the block bitmap via
ext4_mb_mark_bb() and are no longer restored by
ext4_fc_set_bitmaps_and_counters() now that it skips non-extent inodes.
In ext4_fc_replay_add_range(), if ext4_ind_map_blocks() reports a hole for
a logical block that is already present in an extent header in i_data,
ext4_ext_insert_extent() hits BUG_ON(newext->ee_block == nearex->ee_block).

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109221211.1793790-2-Jeremy.Jean@oss.cyber.gouv.fr?part=1

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-11-09 22:32 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-09 22:12 [PATCH v3] ext4: validate extent root during fast commit replay Jérémy Jean
2026-11-09 22:32 ` sashiko-bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox