Linux Kernel EUVD-2026-32424

Exploitation requires a local user account with write access to the weighted interleave NUMA policy sysfs interface, typically located under /sys/kernel/mm/mempolicy/weighted_interleave/. By default on many distributions this interface is writable only by root; however, systems that grant broader sysfs write permissions, use user namespaces with elevated privileges, or run containerized workloads where NUMA policy interfaces are exposed may have a wider attack surface. The running kernel must contain commit e341f9c3c8412e57fe0042a33a2640245ecdf619 (which introduced the buggy code path) and must be compiled with NUMA and weighted interleave policy support. The second (more severe) leak requires no special state or timing - the attacker simply writes '1' or 'true' repeatedly. The first leak additionally requires that the current mode already be manual before writing 'false'. Remote exploitation is not possible; AV:L is confirmed by the CVSS vector, and no network-reachable path to this sysfs write handler exists.

CVSS 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) accurately reflects local exploitation requiring only low-privilege sysfs write access, with high availability impact from kernel memory exhaustion. EPSS of 0.02% (4th percentile) signals minimal observed exploitation activity, and this CVE does not appear in CISA KEV, indicating no confirmed active exploitation. No public exploit code has been identified. Despite these low exploitation signals, the second leak path is mechanically trivial - it requires no race condition, timing, or special state - which makes it operationally more dangerous than EPSS alone suggests on multi-user or container-hosting systems. The 'Information Disclosure' tag from EUVD appears to be a tagging artifact inconsistent with CWE-401 and the CVSS C:N vector; actual impact is availability-only (DoS via OOM). Risk is real but scoped: systems where untrusted local users can write to the weighted interleave sysfs interface are meaningfully exposed; single-user or tightly locked-down systems face minimal practical risk.

A local user with write access to the weighted interleave sysfs attribute runs a tight shell loop (while true; do echo 1 > /sys/kernel/mm/mempolicy/weighted_interleave/auto; done), triggering the second memory leak on every iteration. Each write causes rcu_assign_pointer() to silently discard the old wi_state kernel heap allocation without freeing it. After sustained looping, the kernel's slab allocator exhausts available memory, invoking the OOM killer and potentially crashing critical system processes or the kernel itself. No public exploit code has been identified, but the attack requires no sophisticated tooling.