* [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