Linux Kernel CVE-2026-45942

Requires local access with the ability to perform filesystem operations on an ext4 mount (PR:L, AV:L, no user interaction), so an attacker must already be a logged-in or workload-tenant user on the host. Triggering the race requires concurrent ext4 multi-block allocator activity and folio migration of the ext4 buddy/bitmap pages - in practice a mixed huge-page / memory-pressure workload that exercises page migration while ext4_mb_load_buddy is hitting its fast path. The bug does not require any non-default ext4 mount option, but the secondary false-positive corruption report only surfaces when the kernel is built with the AGGRESSIVE_CHECK/DOUBLE_CHECK debug macro enabled. Exploitation is bounded by the extremely narrow timing window described by the maintainers, by the local-only attack surface (no network path), and by the fact that the observable outcome is bitmap inconsistency and log noise rather than a direct control-flow primitive.

CVSS 7.8 with vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H reflects a local low-privileged attacker scenario rather than a remote threat - the high triad scores are characteristic of NVD's broad kernel scoring rather than evidence of weaponizable RCE. EPSS is 0.02% (5th percentile), this CVE is not in CISA KEV, and no public exploit has been identified at time of analysis, which is consistent with the bug being a workload-dependent race that surfaces under stress with huge-page activity rather than something an attacker can reliably weaponize. The practical risk is data integrity corruption and spurious filesystem errors on busy ext4 systems, not a path to privilege escalation; however, races on free-cluster accounting could in principle be steered toward use-after-free or out-of-bounds bitmap operations, so kernel maintainers treat it as worth patching. Note the description characterizes the bug as a kernel race producing bitmap inconsistencies, while the reporter-supplied tag 'Information Disclosure' is not strongly supported by the description - treat the impact framing as 'data corruption / instability' until the vendor classifies otherwise.

A local user with normal filesystem write access runs a workload that combines heavy ext4 allocation activity with memory pressure that induces THP/folio migration, repeatedly hitting the narrow race between ext4_mb_load_buddy's fast path and __migrate_folio. The result is inconsistent buddy/bitmap state, kernel error logs such as 'free clusters as per group info. But got 8192 blocks', possible filesystem corruption requiring fsck, and potential downstream allocator misbehavior on a busy server. No public exploit has been identified at time of analysis and reaching code execution from this race would require additional, non-trivial primitives.