[PATCH] ext4: fix OOB write in fast-commit replay

[PATCH] ext4: fix OOB write in fast-commit replay

[Jérémy Jean]

Fast-commit recovery checks record bounds and lengths during scan.
Replay reads the records again without these checks. A corrupt filesystem
can make an earlier replay operation overwrite a later record. Its new
length can make ext4_fc_replay_inode() copy past the end of an inode buffer.
The OOB write can trigger KASAN, which reports it as a UAF:

  BUG: KASAN: slab-use-after-free in ext4_fc_replay+0x1725/0x2de0
  Write of size 200 at addr ffff888008598f64 by task busybox/62
  Call Trace:
   __asan_memcpy+0x3c/0x60
   ext4_fc_replay+0x1725/0x2de0
   do_one_pass+0x113c/0x2370
   jbd2_journal_recover+0x528/0x7e0
   jbd2_journal_load+0x7c/0x810
   ext4_fill_super+0xaa54/0xc270

Check record bounds and lengths again before replaying each record.

Fixes: 8016e29f4362 ("ext4: fast commit recovery path")
Cc: stable@vger.kernel.org
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
---
 fs/ext4/fast_commit.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
index 0cac890..9edd26a 100644
--- a/fs/ext4/fast_commit.c
+++ b/fs/ext4/fast_commit.c
@@ -2613,6 +2613,11 @@ static int ext4_fc_replay(journal_t *journal, struct buffer_head *bh,
 			ext4_fc_set_bitmaps_and_counters(sb);
 			break;
 		}
+		if (tl.fc_len > end - val ||
+		    !ext4_fc_value_len_isvalid(sbi, tl.fc_tag, tl.fc_len)) {
+			ret = -EFSCORRUPTED;
+			break;
+		}
 
 		ext4_debug("Replay phase, tag:%s\n", tag2str(tl.fc_tag));
 		state->fc_replay_num_tags--;
-- 
2.47.3

Re: [PATCH] ext4: fix OOB write in fast-commit replay

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Critical] ext4: missing block bitmap updates in ext4_fc_replay() [1]
--

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

ext4: fix OOB write in fast-commit replay

This commit re-validates fast-commit record bounds and value lengths
during the replay phase to prevent out-of-bounds writes if an earlier
replay operation overwrites a later record.

> diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
> index 0cac890cf3702..9edd26a18b92e 100644
> --- a/fs/ext4/fast_commit.c
> +++ b/fs/ext4/fast_commit.c
> @@ -2613,6 +2613,11 @@ static int ext4_fc_replay(journal_t *journal, struct buffer_head *bh,
>  			ext4_fc_set_bitmaps_and_counters(sb);
>  			break;
>  		}
> +		if (tl.fc_len > end - val ||
> +		    !ext4_fc_value_len_isvalid(sbi, tl.fc_tag, tl.fc_len)) {
> +			ret = -EFSCORRUPTED;
> +			break;
> +		}
>  
>  		ext4_debug("Replay phase, tag:%s\n", tag2str(tl.fc_tag));
>  		state->fc_replay_num_tags--;

[Severity: Critical]
This problem wasn't introduced by this patch, but can ext4_fc_replay()
skip ext4_fc_set_bitmaps_and_counters() [1] when the last valid
EXT4_FC_TAG_TAIL record is in the final block of the fast-commit area?

Because EXT4_FC_TAG_TAIL pads its payload to the block boundary, the loop
increment advances cur to end right after state->fc_replay_num_tags is
decremented to 0.  The loop condition cur <= end - EXT4_FC_TAG_BASE_LEN
then exits the loop before the state->fc_replay_num_tags == 0 check at the
top can run.  When that block is also journal->j_fc_last, fc_do_one_pass()
finishes without calling ext4_fc_replay() again, leaving blocks allocated
before the crash unmarked in the block bitmaps and subject to reallocation.

[1] https://sashiko.dev/#/bug/linux-07caeb0c-7490-4ef6-a809-3f819db1b121

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

Re: [PATCH] ext4: fix OOB write in fast-commit replay

[Jan Kara]

On Sun 08-11-26 20:43:46, Jérémy Jean wrote:
> Fast-commit recovery checks record bounds and lengths during scan.
> Replay reads the records again without these checks. A corrupt filesystem
> can make an earlier replay operation overwrite a later record. Its new

This fact looks like the real problem. I think we should validate the
replay does not corrupt the journal. How does this happen? Otherwise we
have to fully redo the validation of each record done in
ext4_fc_replay_scan().

								Honza

> length can make ext4_fc_replay_inode() copy past the end of an inode buffer.
> The OOB write can trigger KASAN, which reports it as a UAF:
> 
>   BUG: KASAN: slab-use-after-free in ext4_fc_replay+0x1725/0x2de0
>   Write of size 200 at addr ffff888008598f64 by task busybox/62
>   Call Trace:
>    __asan_memcpy+0x3c/0x60
>    ext4_fc_replay+0x1725/0x2de0
>    do_one_pass+0x113c/0x2370
>    jbd2_journal_recover+0x528/0x7e0
>    jbd2_journal_load+0x7c/0x810
>    ext4_fill_super+0xaa54/0xc270
> 
> Check record bounds and lengths again before replaying each record.
> 
> Fixes: 8016e29f4362 ("ext4: fast commit recovery path")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
> ---
>  fs/ext4/fast_commit.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
> index 0cac890..9edd26a 100644
> --- a/fs/ext4/fast_commit.c
> +++ b/fs/ext4/fast_commit.c
> @@ -2613,6 +2613,11 @@ static int ext4_fc_replay(journal_t *journal, struct buffer_head *bh,
>  			ext4_fc_set_bitmaps_and_counters(sb);
>  			break;
>  		}
> +		if (tl.fc_len > end - val ||
> +		    !ext4_fc_value_len_isvalid(sbi, tl.fc_tag, tl.fc_len)) {
> +			ret = -EFSCORRUPTED;
> +			break;
> +		}
>  
>  		ext4_debug("Replay phase, tag:%s\n", tag2str(tl.fc_tag));
>  		state->fc_replay_num_tags--;
> -- 
> 2.47.3
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] ext4: fix OOB write in fast-commit replay

[Jérémy Jean]

On 2026-11-09 14:19, Jan Kara wrote:
> On Sun 08-11-26 20:43:46, Jérémy Jean wrote:
>> Fast-commit recovery checks record bounds and lengths during scan.
>> Replay reads the records again without these checks. A corrupt 
>> filesystem
>> can make an earlier replay operation overwrite a later record. Its new
> 
> This fact looks like the real problem. I think we should validate the
> replay does not corrupt the journal. How does this happen? Otherwise we
> have to fully redo the validation of each record done in
> ext4_fc_replay_scan().

The replay can corrupt the journal because a corrupted image can make
metadata blocks used during replay overlap with fast-commit blocks. I
agree that making sure that replay does not corrupt the journal would
be a stronger fix, but I'm not sure I see a simple way to fix this
properly. Rechecking bounds as I proposed fixes a memory issue but it
indeed does not address the root cause.

Regards,
Jérémy

Re: [PATCH] ext4: fix OOB write in fast-commit replay

[Jan Kara]

On Mon 09-11-26 21:47:51, Jérémy Jean wrote:
> On 2026-11-09 14:19, Jan Kara wrote:
> > On Sun 08-11-26 20:43:46, Jérémy Jean wrote:
> > > Fast-commit recovery checks record bounds and lengths during scan.
> > > Replay reads the records again without these checks. A corrupt
> > > filesystem
> > > can make an earlier replay operation overwrite a later record. Its new
> > 
> > This fact looks like the real problem. I think we should validate the
> > replay does not corrupt the journal. How does this happen? Otherwise we
> > have to fully redo the validation of each record done in
> > ext4_fc_replay_scan().
> 
> The replay can corrupt the journal because a corrupted image can make
> metadata blocks used during replay overlap with fast-commit blocks. I
> agree that making sure that replay does not corrupt the journal would
> be a stronger fix, but I'm not sure I see a simple way to fix this
> properly. Rechecking bounds as I proposed fixes a memory issue but it
> indeed does not address the root cause.

OK, I suspected that. So it would mean making sure jbd2 does not corrupt
the journal under itself. In ext4 we have "system blocks" infrastructure
for things like that - see ext4_setup_system_zone(). In jbd2 I guess we
could create something similar just for the time of replay - during the
scan pass we'd build a list of blocks belonging to the journal (just a
simple rb-tree with extents should be enough, under normal circumstances
there shouldn't be more than one or two extents there). During the replay
pass we'd verify the target locations of metadata blocks are not in the
journal. This would actually cover a larger class of journal replay attacks
than this particular one...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR