CVE-2026-45858
MediumCVSS 5.5Exploitation Probability (EPSS)
Low risk5th percentile - higher than 5% of all known CVEs
Summary
In the Linux kernel, a vulnerability in the ext4 filesystem was found related to incorrect zeroing of allocation ranges when splitting a large unwritten extent. Under certain conditions, when the extent splitting operation fails due to lack of space, stale data may remain in the written range, compromising data integrity.
Risk Assessment
The vulnerability could lead to reading stale or corrupted data by users or processes, posing a risk to the confidentiality and integrity of data stored on ext4 filesystems.
Recommendation
It is recommended to immediately update the Linux kernel to a version containing the fix (commit with the solution). Monitor official security advisories from your Linux distribution for the appropriate patch.
Other vulnerabilities in Linux kernel, ext4 filesystem
See all- CVE-2026-43067Critical
A vulnerability in the Linux kernel related to the ext4 filesystem has been resolved, concerning the handling of wraparound when searching for blocks for indirect mapped files. A code change restricts block allocation to numbers fitting within 32-bit block numbers.
- CVE-2026-45985Medium
A vulnerability has been identified in the ext4 filesystem within the Linux kernel that occurs during block allocation in DIO mode. The issue arises from improper setting of the EXT4_GET_BLOCKS_CONVERT flag, which may lead to stale data problems.
- CVE-2026-45942High
A bitmap inconsistency issue was identified and resolved in the Linux kernel's ext4 filesystem, which occurred during stress tests with large page workloads. This issue was caused by a race condition between page migration and bitmap modification.
- CVE-2026-45920High
A vulnerability has been identified in the Linux kernel related to double decrementing the dirty clusters counter during the ext4 filesystem shutdown. This issue leads to a warning with a value of -1 for the dirty clusters counter, indicating an error in the error handling path.
- CVE-2026-45912Medium
A vulnerability has been identified in the Linux kernel related to the ext4 filesystem, concerning the caching of extents during the splitting process. Caching issues may lead to stale extents remaining in the status tree, resulting in space management errors.
- CVE-2026-45899Medium
In the Linux kernel, a vulnerability in the ext4 filesystem was found where stale extent entries may remain in the extent status tree when splitting an extent fails, leading to data inconsistency.
- CVE-2024-49960High
A vulnerability in the Linux kernel related to the ext4 filesystem has been fixed, concerning use-after-free on failed mount attempts. The issue was that the s_err_report timer remained active, potentially leading to I/O errors.
- CVE-2024-49889High
A vulnerability has been identified in the Linux kernel within the ext4 filesystem that may lead to a use-after-free error in the ext4_ext_show_leaf() function. This issue occurs when the 'path' pointer is used after being freed or reallocated, potentially leading to unpredictable system behavior.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1 When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle. 0 A B N [UUUUUUUUUUUU] U: unwritten extent [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written. 0 A B N [WWWWWWWWWWWW] W: written extent [SSDDDDDDDDZZ] Z: zeroed, S: stale data ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A. 0 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ] Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the second time, allowing it to properly handle the split. If the split is successful, it will keep extent from 0 to A as unwritten.