The vulnerability is a race condition between page migration and ext4 bitmap modification. This timing window causes the bitmap state to become momentarily inconsistent, leading the kernel to report errors such as "e4b bitmap check failures". The underlying issue arises from the fast path of load_buddy incrementing a reference count without holding the folio lock, allowing concurrent migration to interfere. The fix implements a lock check so that the load_buddy routine takes the safe, lock‑protecting slow path when a folio is locked. The updated logic also eliminates a false‑positive error that was mistakenly triggered when the bitmap and group descriptor became momentarily misaligned during concurrent access.

All Linux kernel installations that use the ext4 filesystem and have not yet incorporated the described code changes are affected. The CNA vendor list indicates "Linux:Linux", meaning any distribution shipping the upstream kernel before the patch could be vulnerable. No specific kernel version range is supplied, so assessment must be performed against the kernel release in use.

The exploitation window is narrow, occurring only when huge‑page memory migrations meet ext4 bitmap operations. An attacker would require local, privileged access to reproduce the stress conditions that expose the bug. The EPSS score is not available and the vulnerability is not in the CISA KEV catalog, suggesting a low likelihood of widespread exploitation. Nevertheless, the race can produce erroneous error logs and, if the inconsistency leads to genuine metadata corruption, it threatens data integrity. The risk is therefore moderate, with a focus on preventing accidental corruption rather than active remote exploitation.