CVE-2026-45912
MediumCVSS 5.5Exploitation Probability (EPSS)
Low risk7th percentile - higher than 7% of all known CVEs
Summary
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.
Risk Assessment
Organizations may encounter data integrity issues and errors in space accounting, potentially leading to data loss or improper resource management.
Recommendation
It is recommended to avoid caching extents that are being split and to monitor the filesystem for anomalies in space management.
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-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 cache extent during splitting extent Caching extents during the splitting process is risky, as it may result in stale extents remaining in the status tree. Moreover, in most cases, the corresponding extent block entries are likely already cached before the split happens, making caching here not particularly useful. Assume we have an unwritten extent, and then DIO writes the first half. [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range First, when ext4_split_extent_at() splits this extent, it truncates the existing extent and then inserts a new one. During this process, this extent status entry may be shrunk, and calls to ext4_find_extent() and ext4_cache_extents() may occur, which could potentially insert the truncated range as a hole into the extent status tree. After the split is completed, this hole is not replaced with the correct status. [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent [UUUUUUU|HHHHHHHH] extent status tree H: hole Then, the outer calling functions will not correct this remaining hole extent either. Finally, if we perform a delayed buffer write on this latter part, it will re-insert the delayed extent and cause an error in space accounting. In adition, if the unwritten extent cache is not shrunk during the splitting, ext4_cache_extents() also conflicts with existing extents when caching extents. In the future, we will add checks when caching extents, which will trigger a warning. Therefore, Do not cache extents that are being split.