CVE-2026-45942: Linux Kernel Race Condition Vulnerability

CVE-2026-45942 Overview

CVE-2026-45942 is a race condition vulnerability in the Linux kernel's ext4 filesystem implementation. The flaw involves a narrow timing window between page migration and bitmap modification in the ext4_mb_load_buddy function. Under mixed huge-page workloads, the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. The result is bitmap inconsistency reports such as ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks. The issue also produces false-positive corruption reports when the DOUBLE_CHECK macro is enabled.

Critical Impact
Concurrent execution of folio migration and ext4 multi-block allocator operations can corrupt in-memory buddy bitmap state, leading to filesystem consistency check failures and potential allocator misbehavior on systems under mixed huge-page workloads.

Affected Products

Linux kernel ext4 filesystem subsystem
Systems running mixed huge-page workloads on ext4 volumes
Multiple stable kernel branches receiving the fix (see external references)

Discovery Timeline

2026-05-27 - CVE-2026-45942 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-45942

Vulnerability Analysis

The vulnerability is a [Race Condition] in the ext4 multi-block allocator (mballoc) interacting with the kernel's folio migration subsystem. When ext4_mb_load_buddy takes its fast path, it calls folio_try_get to increment the folio reference count without acquiring the folio lock. A concurrent __migrate_folio operation acquires the folio lock, validates reference counts, performs folio_mc_copy, and then calls __folio_migrate_mapping with folio_ref_freeze. Because the allocator only holds a reference and not the lock, mb_mark_used can modify bitmap state on a folio that is simultaneously being migrated, producing inconsistent in-memory bitmaps.

A second related defect arises with DOUBLE_CHECK enabled. The function mb_cmp_bitmaps assumed that holding the folio lock during initial bitmap load from disk was sufficient to serialize access. However, a concurrent ext4_mb_load_buddy caller that observes the folio in an uptodate state skips locking entirely, calls mb_mark_used, and modifies e4b->bd_bitmap while mb_cmp_bitmaps is still comparing it, producing false positive reports such as corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc.

Root Cause

The root cause is insufficient synchronization in the fast path of ext4_mb_load_buddy. Reference counting alone does not prevent folio migration, which requires the folio lock. The fix introduces a check on folio lock status: if the folio is locked, the allocator opts for the slow path that acquires the lock, closing the concurrency window.

Attack Vector

The defect is triggered by legitimate concurrent workloads rather than crafted input. Stress tests under mixed huge-page workloads reproduced the condition. Triggering requires local filesystem activity that exercises both the ext4 allocator and page migration simultaneously, making remote exploitation impractical. The observable impact is filesystem state inconsistency and kernel warnings rather than direct code execution.

The vulnerability manifests in fs/ext4/mballoc.c within the buddy allocator load path. See the upstream commits referenced below for the precise locking logic introduced to resolve the race.

Detection Methods for CVE-2026-45942

Indicators of Compromise

Kernel log entries matching ext4_mb_complex_scan_group: followed by a mismatch between free clusters reported by group info and actual block counts.
DOUBLE_CHECK corruption messages of the form corruption in group <N> at byte <offset>: <X> in copy != <Y> on disk/prealloc.
Sporadic ext4 allocator warnings on hosts running mixed huge-page workloads or memory compaction.

Detection Strategies

Monitor dmesg and /var/log/messages for ext4 mballoc warnings tied to bitmap consistency.
Correlate ext4 warnings with concurrent memory migration or compaction activity reported by /proc/vmstat counters such as pgmigrate_success and compact_migrate_scanned.
Audit kernel build versions against the patched commits listed in Kernel Commit 29a07d6 and related stable backports.

Monitoring Recommendations

Forward kernel logs to a centralized logging or SIEM platform and create alerts for ext4 mballoc warning signatures.
Track kernel version inventory across Linux fleets to identify hosts that have not received stable updates containing this fix.
Establish baseline metrics for ext4 allocator warnings so that recurrence after patching can be investigated as a regression.

How to Mitigate CVE-2026-45942

Immediate Actions Required

Apply the latest stable Linux kernel update for your distribution that contains the upstream ext4 mballoc race fix.
Identify hosts running mixed huge-page workloads on ext4 and prioritize them for kernel patching.
Validate kernel commit inclusion using git log or the distribution's changelog against the upstream commit hashes.

Patch Information

The fix is distributed across multiple upstream commits and stable backports. Relevant commits include Kernel Commit 29a07d6, Kernel Commit 57e83bf, Kernel Commit bdc56a9, Kernel Commit c05033c, and Kernel Commit f29709a. The change modifies ext4_mb_load_buddy to check folio lock status and to take the slow path when the folio is locked, closing the race with __migrate_folio.

Workarounds

Disable the DOUBLE_CHECK debug macro in production builds to suppress false positive corruption reports until the patch is applied.
Reduce exposure to the race by minimizing concurrent huge-page migration activity on ext4-heavy workloads where feasible.
Schedule reboots to load the patched kernel; live patching support depends on the distribution and the size of the change set.

bash

# Verify kernel includes the ext4 mballoc race fix
uname -r
zcat /proc/config.gz | grep CONFIG_EXT4
dmesg | grep -E "ext4_mb_complex_scan_group|corruption in group"