CVE-2026-45942

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix e4b bitmap inconsistency reports<br /> <br /> A bitmap inconsistency issue was observed during stress tests under<br /> mixed huge-page workloads. Ext4 reported multiple e4b bitmap check<br /> failures like:<br /> <br /> ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as<br /> per group info. But got 8192 blocks<br /> <br /> Analysis and experimentation confirmed that the issue is caused by a<br /> race condition between page migration and bitmap modification. Although<br /> this timing window is extremely narrow, it is still hit in practice:<br /> <br /> folio_lock ext4_mb_load_buddy<br /> __migrate_folio<br /> check ref count<br /> folio_mc_copy __filemap_get_folio<br /> folio_try_get(folio)<br /> ......<br /> mb_mark_used<br /> ext4_mb_unload_buddy<br /> __folio_migrate_mapping<br /> folio_ref_freeze<br /> folio_unlock<br /> <br /> The root cause of this issue is that the fast path of load_buddy only<br /> increments the folio&amp;#39;s reference count, which is insufficient to prevent<br /> concurrent folio migration. We observed that the folio migration process<br /> acquires the folio lock. Therefore, we can determine whether to take the<br /> fast path in load_buddy by checking the lock status. If the folio is<br /> locked, we opt for the slow path (which acquires the lock) to close this<br /> concurrency window.<br /> <br /> Additionally, this change addresses the following issues:<br /> <br /> When the DOUBLE_CHECK macro is enabled to inspect bitmap-related<br /> issues, the following error may be triggered:<br /> <br /> corruption in group 324 at byte 784(6272): f in copy != ff on<br /> disk/prealloc<br /> <br /> Analysis reveals that this is a false positive. There is a specific race<br /> window where the bitmap and the group descriptor become momentarily<br /> inconsistent, leading to this error report:<br /> <br /> ext4_mb_load_buddy ext4_mb_load_buddy<br /> __filemap_get_folio(create|lock)<br /> folio_lock<br /> ext4_mb_init_cache<br /> folio_mark_uptodate<br /> __filemap_get_folio(no lock)<br /> ......<br /> mb_mark_used<br /> mb_mark_used_double<br /> mb_cmp_bitmaps<br /> mb_set_bits(e4b-&gt;bd_bitmap)<br /> folio_unlock<br /> <br /> The original logic assumed that since mb_cmp_bitmaps is called when the<br /> bitmap is newly loaded from disk, the folio lock would be sufficient to<br /> prevent concurrent access. However, this overlooks a specific race<br /> condition: if another process attempts to load buddy and finds the folio<br /> is already in an uptodate state, it will immediately begin using it without<br /> holding folio lock.