CVE-2026-45942

What it actually does

This is a local Linux kernel race condition in ext4 buddy bitmap handling. Under a narrow timing window involving folio/page migration and ext4 bitmap modification, the kernel can use an ext4 buddy bitmap folio after only incrementing its reference count rather than synchronizing with the folio lock. A local user able to create heavy filesystem allocation activity on an affected ext4 filesystem may be able to trigger inconsistent block bitmap state, incorrect ext4 free-space accounting, filesystem corruption reports, denial of service, or potentially broader compromise of confidentiality, integrity, and availability as reflected by the high-impact CVSS vector. The issue is local-only, requires an authenticated low-privileged user, requires no user interaction, and is not known to be exploited in the wild based on the provided KEV and exploit maturity data.

Why it matters to the business

Successful exploitation could disrupt Linux hosts that rely on ext4 filesystems by causing filesystem inconsistency, data corruption risk, service crashes, forced read-only remounts, or system downtime. The practical exploitation likelihood appears low at present because exploitation requires local access, there is no known public exploit maturity, EPSS is very low, and the issue is not listed in CISA KEV; however, kernel flaws with high confidentiality, integrity, and availability impact should still be prioritized on multi-user servers, shared compute platforms, CI/build systems, container hosts, and environments where untrusted users can run local workloads.

How an attack unfolds

An attacker first obtains local code execution as a low-privileged user on a Linux system using an affected kernel and an ext4 filesystem. They then generate a workload that repeatedly allocates and frees filesystem blocks while also inducing memory pressure, huge-page activity, or page migration behavior. The goal is to win the race between ext4 loading or using the buddy bitmap and kernel folio migration. If the timing is hit, ext4 may operate on bitmap state that is not properly protected by the folio lock, leading to inconsistent free-space metadata and bitmap checks. Depending on kernel behavior, mount options, workload, and surrounding conditions, the result may be ext4 error messages, filesystem inconsistency, denial of service, data integrity impact, or potentially a kernel-level security impact. No known threat actors, ransomware use, or CISA KEV exploitation are indicated in the supplied data.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the ext4 fix for this race condition. Because no exact fixed package versions were provided, use the relevant distribution security advisory or upstream stable kernel changelog to identify the corrected kernel package for each Linux distribution in use. After upgrading, reboot into the fixed kernel; merely installing the package is not sufficient if the host continues running the vulnerable kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, isolating multi-user systems, limiting access to writable ext4-backed filesystems, applying resource controls to prevent aggressive filesystem and memory-pressure stress workloads, and monitoring ext4 error output closely. Consider migrating critical workloads away from affected kernels until patched if filesystem integrity is business-critical.

How to confirm the fix worked

Confirm the running kernel version, not only the installed package version, and verify it matches a distribution release that contains the ext4 race-condition fix. On Linux, compare `uname -r` with the fixed version listed by the OS vendor advisory. Review package manager output, such as `rpm -q kernel`, `dpkg -l 'linux-image*'`, or equivalent platform inventory, to ensure the fixed kernel is installed. Reboot systems after patching and re-check the active kernel. Validate filesystem health by reviewing kernel logs for ext4 bitmap inconsistency messages and, where operationally safe, running offline filesystem checks according to vendor guidance. For container or virtualized environments, validate the host kernel because containers share the host kernel.

Typical attack path

1. Gain local authenticated access to a Linux system running an affected kernel with an ext4 filesystem.
2. Identify writable ext4-backed storage where intensive allocation and deallocation can be performed.
3. Run a stress workload that combines filesystem block allocation activity with memory pressure, huge pages, or page migration activity.
4. Attempt to trigger the race between ext4 buddy bitmap loading/modification and folio migration.
5. Cause ext4 bitmap inconsistency, filesystem error reporting, metadata corruption symptoms, service instability, or host denial of service.
6. If additional primitives are achievable, attempt to escalate impact from filesystem corruption or kernel memory/state inconsistency.

How to detect it

Look for evidence of prior exploitation or triggering in kernel logs, system journals, and filesystem health records. Primary sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dumps, ext4 error reports, monitoring alerts for filesystem remounts, and service outage timelines. Search for ext4 bitmap inconsistency messages such as `ext4_mb_complex_scan_group`, `e4b bitmap`, `mb_cmp_bitmaps`, `mb_mark_used_double`, and `corruption in group`. Also look for secondary symptoms including ext4 errors followed by remounting filesystems read-only, kernel warnings, hung tasks, I/O errors, unexpected reboots, or filesystem check failures. Correlate any such messages with local user activity, batch jobs, build jobs, container workloads, memory pressure, huge-page activity, stress-testing tools, or repeated creation/deletion of large numbers of files. Because the described bug can also be triggered by stress conditions and may not leave attacker-specific artifacts, absence of these messages does not prove non-exploitation, and presence of them should be triaged as a potential integrity incident until benign stress testing or hardware/storage faults are ruled out.

• ext4_mb_complex_scan_group
• e4b bitmap
• bitmap inconsistency
• free clusters as per group info. But got
• corruption in group
• in copy != ff on disk/prealloc
• mb_cmp_bitmaps
• mb_mark_used_double
• ext4_mb_load_buddy
• ext4_mb_init_cache
• EXT4-fs error
• EXT4-fs warning
• Remounting filesystem read-only

What your security team should do

• Prioritize patching on multi-user Linux systems, shared compute platforms, container hosts, build servers, research clusters, and any systems where low-privileged users can run arbitrary local workloads.
• Inventory Linux hosts using ext4 and identify systems running kernel versions predating the vendor fix.
• Upgrade to a vendor-supported fixed kernel and reboot to activate it.
• Until patched, restrict local interactive access and untrusted job execution on affected systems.
• Monitor kernel logs for ext4 bitmap inconsistency, buddy bitmap, or filesystem corruption messages.
• Investigate any affected host that reports ext4 bitmap inconsistency messages, especially if accompanied by unusual local stress workloads or unexplained service instability.
• Treat repeated ext4 metadata inconsistency messages as potential integrity events and preserve logs before remediation.
• For critical systems, perform filesystem integrity validation during a maintenance window after patching.