CVE-2026-45985
MediumCVSS 5.5Exploitation Probability (EPSS)
Low risk7th percentile - higher than 7% of all known CVEs
Summary
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.
Risk Assessment
Organizations may face data integrity issues, potentially resulting in data loss or corruption in the event of a write failure.
Recommendation
It is recommended to update the Linux kernel to remove the passing of the EXT4_GET_BLOCKS_CONVERT flag when splitting an unwritten extent before submitting I/O and ensure that the entire extent range is zeroed out.
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-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-2026-45858Medium
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.
- 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 set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues. Assume we have an unwritten extent, and then DIO writes the second half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set. Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree. [0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone. Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.