CVE-2022-50428

ext4: fix off-by-one errors in fast-commit block filling

published October 1, 2025

CVSS
—
EPSS
0%
Percentile
4.7
In the wild
Unconfirmed
What it is

In the Linux kernel, the following vulnerability has been resolved:

ext4: fix off-by-one errors in fast-commit block filling

Due to several different off-by-one errors, or perhaps due to a late

change in design that wasn't fully reflected in the code that was

actually merged, there are several very strange constraints on how

fast-commit blocks are filled with tlv entries:

- tlvs must start at least 10 bytes before the end of the block, even

though the minimum tlv length is 8. Otherwise, the replay code will

ignore them. (BUG: ext4_fc_reserve_space() could violate this

requirement if called with a len of blocksize - 9 or blocksize - 8.

Fortunately, this doesn't seem to happen currently.)

- tlvs must end at least 1 byte before the end of the block. Otherwise

the replay code will consider them to be invalid. This quirk

contributed to a bug (fixed by an earlier commit) where uninitialized

memory was being leaked to disk in the last byte of blocks.

Also, strangely these constraints don't apply to the replay code in

e2fsprogs, which will accept any tlvs in the blocks (with no bounds

checks at all, but that is a separate issue...).

Given that this all seems to be a bug, let's fix it by just filling

blocks with tlv entries in the natural way.

Note that old kernels will be unable to replay fast-commit journals

created by kernels that have this commit.

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00159 · 4.7th percentile
Published
2025-10-01T11:42Z
EPSS history
Timeline
  • 01 OCT 11:42Z
    ext4: fix off-by-one errors in fast-commit block filling
    cvelistv5