CVE-2026-45920

What it actually does

This is a local Linux kernel ext4 filesystem flaw in the block allocation error path. During filesystem shutdown or injected I/O/error conditions, ext4 can decrement the dirty cluster reservation counter twice after a failed metadata update, causing the counter to become inconsistent, including negative values. The observed failure path triggers kernel warnings in ext4_put_super() and may lead to filesystem/accounting inconsistency, denial of service, or broader integrity impacts associated with ext4 state corruption. Exploitation requires local privileges sufficient to perform filesystem activity on an affected ext4 filesystem and to induce or race error/shutdown conditions; it is not a remotely reachable network vulnerability.

Why it matters to the business

Systems using affected Linux kernels with ext4 filesystems may experience kernel warnings, filesystem shutdown issues, service disruption, possible data integrity risk, or forced recovery workflows. Because the flaw is local and currently has low EPSS, no known public exploit maturity, and is not listed in CISA KEV, broad internet-scale exploitation is unlikely; however, multi-user Linux servers, container hosts, build systems, shared compute platforms, and storage-intensive workloads should still prioritize kernel updates because local filesystem bugs can cause outages and complicate incident response.

How an attack unfolds

An attacker who already has local access or code execution on a Linux system using an affected kernel exercises ext4 filesystem operations that allocate blocks while the filesystem is under stress or entering shutdown/error handling. By repeatedly creating, modifying, truncating, or deleting files while inducing conditions that cause ext4_handle_dirty_metadata() to fail, the attacker can drive ext4_mb_mark_diskspace_used() and ext4_mb_new_blocks() through the vulnerable error path. In that path, ext4 releases dirty cluster accounting once in the lower-level function and again in the caller, producing an inconsistent dirty cluster count. The practical result is not a clean privilege-escalation primitive based on the available description, but it can produce kernel warnings, filesystem accounting corruption, and potential denial-of-service or integrity impact on affected systems.

How to fix it

Apply a Linux kernel update from the relevant distribution or kernel vendor that includes the ext4 fix for the dirtyclusters double-decrement error path. No exact fixed package versions were provided in the input, so remediation should be based on vendor advisories, kernel changelogs, and distribution security errata that reference this issue or the ext4 change that centralizes dirty cluster reservation release in ext4_mb_new_blocks(). Where immediate patching is not possible, reduce exposure by limiting local shell/container access, restricting untrusted users from writing to ext4-backed shared filesystems, avoiding deliberate filesystem shutdown/error-injection operations on production systems, and ensuring backups and filesystem recovery procedures are current. Mitigation is not a substitute for patching because the vulnerable logic is in kernel filesystem code.

How to confirm the fix worked

Confirm that systems have booted into a kernel build containing the ext4 dirtyclusters double-decrement fix, not merely installed the package. Validate through the running kernel version, distribution security advisory mapping, kernel package changelog, or source-level confirmation that the error path no longer decrements dirty cluster counters in both ext4_mb_mark_diskspace_used() and ext4_mb_new_blocks(). For engineering validation, run ext4 stress and shutdown/error-path regression testing such as fstests generic/388 or comparable fsstress workloads on non-production systems and confirm that kernel logs do not show ext4_put_super() dirty cluster warnings or negative dirty cluster counter behavior. Also verify that monitoring captures kernel warnings from journald, dmesg, syslog, and crash reporting pipelines.

Typical attack path

1. Obtain local authenticated access or local code execution on a Linux system using an affected kernel and ext4 filesystem.
2. Identify a writable ext4-backed filesystem or workload area where intensive file operations can be performed.
3. Generate filesystem allocation activity, such as repeated file creation, writes, truncation, deletion, or fsstress-style workloads.
4. Trigger or race filesystem shutdown, remount, error injection, or metadata write failure conditions so ext4_handle_dirty_metadata() returns an error.
5. Drive ext4 through the vulnerable ext4_mb_mark_diskspace_used() to ext4_mb_new_blocks() error path where dirty cluster counters are decremented twice.
6. Cause inconsistent ext4 dirty cluster accounting, potentially resulting in kernel warnings, filesystem shutdown problems, service disruption, or integrity-related recovery activity.

How to detect it

There are no public exploit-specific indicators available from the provided information, and exploitation would resemble local filesystem stress or failure activity rather than a distinctive network pattern. To assess possible prior exploitation or triggering, review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, and filesystem monitoring for ext4 warnings involving ext4_put_super(), dirtyclusters, dirty cluster counter underflow, journal aborts, filesystem shutdown, remount-read-only events, or unexpected fsck/recovery activity. Correlate those events with local user sessions, container activity, batch jobs, CI workloads, file stress tools, abnormal write/delete bursts, forced unmounts, storage errors, or administrative shutdown/remount operations. Because these artifacts can also occur during benign stress testing or hardware/storage failures, treat them as investigation leads rather than proof of malicious exploitation.

• ext4_put_super+0x
• WARNING: CPU:
• s_dirtyclusters_counter value of -1
• dirtyclusters
• dirty clusters count
• ext4_mb_mark_diskspace_used
• ext4_mb_new_blocks
• ext4_handle_dirty_metadata
• ext4_mb_mark_context
• ext4_claim_free_clusters
• EXT4-fs error
• EXT4-fs warning
• Aborting journal
• Remounting filesystem read-only
• generic/388
• fsstress

What your security team should do

• Inventory Linux systems using ext4 filesystems and identify those running kernel versions prior to the vendor fix.
• Prioritize patching on shared compute, container hosts, CI/build infrastructure, storage-heavy servers, and systems where untrusted or semi-trusted users can perform local file operations.
• Track vendor advisories and distribution errata because exact fixed versions were not provided; ensure systems are rebooted into the corrected kernel after package installation.
• Review kernel logs for ext4 dirty cluster warnings, ext4_put_super() warnings, filesystem remounts, journal aborts, or unexplained ext4 recovery activity since the publication date.
• Restrict local access and untrusted write access to ext4-backed filesystems until patching is complete, especially on multi-tenant or shared Linux platforms.
• Maintain verified backups and test filesystem recovery procedures for systems hosting important data on ext4.
• Because this issue is not KEV-listed, not known to be ransomware-used, and has low EPSS at the time of assessment, treat it as important for reliability and local hardening rather than an emergency internet-facing exposure.