CVE-2026-45942

ext4: fix e4b bitmap inconsistency reports

Published May 27, 2026 CVSS 3.1 · 7.8 High EPSS < 1% KEV · Not listed
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.

Remediation

No solution or workaround provided in the CVE record

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Ubuntu USN Ubuntu USN USN-8567-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8574-1 Linux kernel (GCP FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8574-2 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8595-1 Linux kernel (Oracle) vulnerabilities
Ubuntu USN Ubuntu USN USN-8596-1 Linux kernel (NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-8595-2 Linux kernel (AWS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8606-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8607-1 Linux kernel (Azure CVM) vulnerabilities
Ubuntu USN Ubuntu USN USN-8608-1 Linux kernel (Azure FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8609-1 Linux kernel (Azure CVM) vulnerabilities
Ubuntu USN Ubuntu USN USN-8574-3 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8595-3 Linux kernel (AWS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8619-1 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-8665-1 Linux kernel (Raspberry Pi) vulnerabilities
History
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Type Values Removed Values Added
Weaknesses CWE-362
Type Values Removed Values Added
Weaknesses CWE-367
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate

Type Values Removed Values Added
Weaknesses CWE-362
Type Values Removed Values Added
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.
Title ext4: fix e4b bitmap inconsistency reports
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References
Weaknesses

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Oct 30, 2026, 12:25 PM
Reserved
May 13, 2026, 3:03 PM
Status
Undergoing Analysis
Published
May 27, 2026, 2:17 PM
Modified
Oct 30, 2026, 1:18 PM
Severity
Moderate
Public date
May 27, 2026, 12:00 AM