CVE-2022-50428 in Linux
Summary
by MITRE • 10/01/2025
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/16/2026
The vulnerability identified as CVE-2022-50428 resides within the Linux kernel's ext4 filesystem implementation, specifically affecting the fast-commit block handling mechanism. This issue stems from multiple off-by-one errors that create unusual constraints on how type-length-value (TLV) entries are populated within fast-commit blocks. The flaw manifests as a design inconsistency between the kernel's fast-commit block creation and the replay mechanism, creating a scenario where the system's behavior becomes unpredictable and potentially insecure. These constraints were likely introduced due to a design change that wasn't properly implemented across all code paths, resulting in a complex set of boundary conditions that must be carefully maintained for proper operation.
The technical implementation of this vulnerability involves specific boundary requirements that are inconsistent with standard TLV handling practices. The fast-commit blocks must contain TLV entries that start at least 10 bytes before the block's end, despite TLV entries requiring only 8 bytes minimum length, creating a logical inconsistency in the validation process. Additionally, TLV entries must end at least 1 byte before the block's boundary to prevent the replay code from marking them as invalid. These requirements create a narrow operational window where the system can function correctly, but any deviation results in either ignored TLV entries or invalid block processing. The vulnerability is particularly concerning because it can be triggered by the ext4_fc_reserve_space() function when called with specific length parameters, though current implementations appear to avoid triggering this condition.
The operational impact of CVE-2022-50428 extends beyond simple functional failures to potential security implications within the filesystem's integrity mechanisms. When fast-commit blocks are improperly filled due to these boundary violations, the replay code may ignore valid TLV entries or incorrectly process data, leading to inconsistent filesystem states. The vulnerability also introduces a compatibility issue where newer kernel versions cannot properly replay fast-commit journals created by older kernels, creating a rollback scenario that affects system reliability. This issue is particularly dangerous in production environments where filesystem consistency is paramount, as the off-by-one errors could lead to data corruption or loss during journal replay operations, especially when the filesystem is under heavy I/O load or during system recovery scenarios.
The fix for this vulnerability involves removing the artificial constraints that were imposed on fast-commit block filling, allowing TLV entries to be populated in a natural, standard manner consistent with typical TLV implementations. This approach aligns with established best practices for filesystem design and eliminates the complex boundary conditions that created the vulnerability. From a cybersecurity perspective, this fix addresses potential CWE-129 issues related to insufficient boundary checking and CWE-128 issues involving incorrect bounds checking in array access operations. The remediation also aligns with ATT&CK techniques related to privilege escalation and defense evasion by ensuring proper filesystem operation and preventing potential exploitation through malformed TLV entries. Organizations should implement this patch promptly to avoid potential data integrity issues and ensure compatibility between different kernel versions in environments that utilize ext4 filesystems with fast-commit features, particularly in enterprise systems where filesystem reliability directly impacts overall system stability and data protection mechanisms.