CVE-2026-45920
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk9th percentile - higher than 9% of all known CVEs
Summary
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.
Risk Assessment
This vulnerability may lead to unpredictable filesystem behavior, potentially affecting the stability and integrity of data within the system. If errors occur during filesystem shutdown, it could result in data loss.
Recommendation
It is recommended to update the Linux kernel to the latest version where this vulnerability has been fixed. Regular monitoring and testing of the filesystem will also help identify potential issues.
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-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: fix dirtyclusters double decrement on fs shutdown fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count: WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4] Tracing the failure shows that the warning fires due to an s_dirtyclusters_counter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4_mb_mark_diskspace_used() and the caller ext4_mb_new_blocks(). First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4_handle_dirty_metadata() call(s) made from ext4_mb_mark_context(). The changed value is non-zero at this point, so ext4_mb_mark_diskspace_used() does not exit after the error bubbles up from ext4_mb_mark_context(). Instead, the former decrements both cluster counters and returns the error up to ext4_mb_new_blocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency. To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4_mb_new_blocks() is responsible for acquiring cluster reservation (via ext4_claim_free_clusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure.