CVE-2026-45942
Awaiting Analysis Awaiting Analysis - Queue
Race Condition in Linux Kernel Ext4 Filesystem

Publication date: 2026-05-27

Last updated on: 2026-05-30

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: ext4: fix e4b bitmap inconsistency reports A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like: ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice: folio_lock ext4_mb_load_buddy __migrate_folio check ref count folio_mc_copy __filemap_get_folio folio_try_get(folio) ...... mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock The root cause of this issue is that the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process acquires the folio lock. Therefore, we can determine whether to take the fast path in load_buddy by checking the lock status. If the folio is locked, we opt for the slow path (which acquires the lock) to close this concurrency window. Additionally, this change addresses the following issues: When the DOUBLE_CHECK macro is enabled to inspect bitmap-related issues, the following error may be triggered: corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc Analysis reveals that this is a false positive. There is a specific race window where the bitmap and the group descriptor become momentarily inconsistent, leading to this error report: ext4_mb_load_buddy ext4_mb_load_buddy __filemap_get_folio(create|lock) folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio(no lock) ...... mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits(e4b->bd_bitmap) folio_unlock The original logic assumed that since mb_cmp_bitmaps is called when the bitmap is newly loaded from disk, the folio lock would be sufficient to prevent concurrent access. However, this overlooks a specific race condition: if another process attempts to load buddy and finds the folio is already in an uptodate state, it will immediately begin using it without holding folio lock.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-27
Last Modified
2026-05-30
Generated
2026-06-16
AI Q&A
2026-05-27
EPSS Evaluated
2026-06-15
NVD
CVE-2026-45942
EUVD
EUVD-2026-32226
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability is a race condition in the Linux kernel's ext4 filesystem related to bitmap inconsistency reports. It occurs during stress tests with mixed huge-page workloads, where ext4 reports multiple bitmap check failures due to a timing window between page migration and bitmap modification.

The root cause is that the fast path of the load_buddy function only increments a folio's reference count, which does not prevent concurrent folio migration. The folio migration process acquires a folio lock, so the fix involves checking the folio lock status to decide whether to take the fast or slow path, closing the concurrency window.

Additionally, the fix addresses false positive errors triggered by the DOUBLE_CHECK macro, which inspects bitmap-related issues. These false positives arise from a race window where the bitmap and group descriptor become momentarily inconsistent, causing erroneous corruption reports.

Impact Analysis

This vulnerability can cause ext4 filesystem bitmap inconsistencies, leading to incorrect error reports about free clusters and potential false corruption warnings.

While the timing window is narrow, in practice it can cause stress test failures and potentially affect filesystem reliability or stability under heavy workloads involving huge pages.

However, the description does not indicate direct data loss or security breaches, but the inconsistency reports could lead to confusion or unnecessary troubleshooting.

Detection Guidance

This vulnerability manifests as bitmap inconsistency reports in the ext4 filesystem during stress tests under mixed huge-page workloads.

Typical error messages indicating this issue include lines like:

  • ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks
  • corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc

To detect this vulnerability on your system, monitor system logs (e.g., using dmesg or journalctl) for ext4 bitmap inconsistency errors.

Suggested commands to check for these errors include:

  • dmesg | grep ext4_mb_complex_scan_group
  • journalctl -k | grep ext4_mb_complex_scan_group
  • dmesg | grep corruption
  • journalctl -k | grep corruption
Mitigation Strategies

The root cause of this vulnerability is a race condition in the ext4 filesystem's bitmap handling during page migration.

Immediate mitigation steps include:

  • Update the Linux kernel to a version where this vulnerability has been fixed, as the issue has been resolved by modifying the ext4 bitmap handling logic.
  • Avoid running heavy mixed huge-page workload stress tests on ext4 filesystems until the patch is applied.
  • Monitor system logs for bitmap inconsistency errors to detect if the issue is occurring.

Since this is a kernel-level race condition, applying the vendor-provided kernel patch or upgrading to a fixed kernel release is the most effective mitigation.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-45942. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart