CVE-2026-45920
Last modified
CVE-2026-45920 is a high-severity vulnerability rated 7.8/10 on the CVSS scale. 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. EPSS estimates a 0.15% chance of exploitation in the next 30 days.
Description
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.
Metrics
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weakness Enumeration
Affected Software
| Vendor | Product | Versions |
|---|---|---|
| Linux | Linux Kernel | >= 2.6.29, < 5.10.253 |
| Linux | Linux Kernel | >= 5.11, < 5.15.203 |
| Linux | Linux Kernel | >= 5.16, < 6.1.167 |
| Linux | Linux Kernel | >= 6.2, < 6.6.130 |
| Linux | Linux Kernel | >= 6.7, < 6.12.75 |
| Linux | Linux Kernel | >= 6.13, < 6.18.14 |
| Linux | Linux Kernel | >= 6.19, < 6.19.4 |
References
Timeline
- Published
- Last Modified
- Status
- Undergoing Analysis
Frequently Asked Questions
What is CVE-2026-45920?
How severe is CVE-2026-45920?
How do I fix CVE-2026-45920?
Are you affected by CVE-2026-45920?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
