From: sashiko-bot@kernel.org
To: "Jérémy Jean" <Jeremy.Jean@oss.cyber.gouv.fr>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH] ext4: fix OOB write in fast-commit replay
Date: Sun, 08 Nov 2026 20:56:20 +0000 [thread overview]
Message-ID: <sashiko-outbox-204031@kernel.org> (raw)
In-Reply-To: <20261108204345.1423203-2-Jeremy.Jean@oss.cyber.gouv.fr>
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
next prev parent reply other threads:[~2026-11-08 20:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-08 20:43 [PATCH] ext4: fix OOB write in fast-commit replay Jérémy Jean
2026-11-08 20:56 ` sashiko-bot [this message]
2026-11-09 13:19 ` Jan Kara
2026-11-09 20:47 ` Jérémy Jean
2026-11-10 12:13 ` Jan Kara
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=sashiko-outbox-204031@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Jeremy.Jean@oss.cyber.gouv.fr \
--cc=linux-ext4@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tytso@mit.edu \
/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.