CVE-2026-45920

What it is

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.

At a glance

Exploitability

Can be exploited locally on the machine with a low-privilege account. High risk of data exposure, data tampering, service disruption.

Exploit odds

0.1% chance of exploitation in the next 30 days (EPSS).

Fix

A patch, advisory or fixed version is referenced. Upgrade or apply it.

Timeline

1. 2026-05-27 14:17 UTC PublishedDisclosed publicly on CVE.org and NVD
2. 2026-11-06 16:18 UTC Last updatedMost recent change to the record

Why it ranks here

• Exploited in the wild: no, CISA does not list it.
• Exploit odds: 0.1% in the next 30 days (EPSS).
• Severity: 7.8 HIGH (CVSS).
• Fix: a patch or advisory is linked.

Details

Published

2026-05-27 14:17 UTC

Last modified

2026-11-06 16:18 UTC

Exploit probability

0.1% · EPSS, next 30 days

Weakness

CWE-415

Record status

Undergoing Analysis

Affected

• Linux Kernel < 5.10.253
• Linux Kernel < 5.15.203
• Linux Kernel < 6.1.167
• Linux Kernel < 6.6.130
• Linux Kernel < 6.12.75
• Linux Kernel < 6.18.14
• Linux Kernel < 6.19.4

Attack profile CVSS 3.1 · 7.8

Attack vector

Local

Complexity

Low

Privileges needed

Low

User interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Is it in your code?

Hand this to your coding agent. It searches your project for the affected products and checks versions. Nothing leaves your machine.

Read https://cve-list.com/agent/cve/CVE-2026-45920.md and follow it. Check whether this project is affected by CVE-2026-45920. Read only. Don't change anything and don't upload my code. Tell me yes, no or not sure, with the file as proof.

Copy as ticket · More options · Status badge