https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 04:34:58 +0000 https://vulnerability.circl.lu/vuln/cve-2026-45942 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ext4: fix e4b bitmap inconsistency reports</p> <p>A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like:</p> <p>ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks</p> <p>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:</p> <p>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</p> <p>The root cause of this issue is that the fast path of load_buddy only increments the folio&#39;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.</p> <p>Additionally, this change addresses the following issues:</p> <p>When…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ext4: fix e4b bitmap inconsistency reports</p> <p>A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like:</p> <p>ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks</p> <p>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:</p> <p>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</p> <p>The root cause of this issue is that the fast path of load_buddy only increments the folio&#39;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.</p> <p>Additionally, this change addresses the following issues:</p> <p>When…</p> https://vulnerability.circl.lu/vuln/cve-2026-45942