Linux Kernel EUVD-2026-58971

Exploitation requires local access with at least low-privilege credentials (PR:L per CVSS). The vulnerable code path is reached only when all of the following conditions are met: (1) the system runs a Linux kernel in the range 5.7 through the fixed versions; (2) hugetlb pages are in active use (via mmap MAP_HUGETLB, shmget with SHM_HUGETLB, or similar); (3) cgroup v2 hugetlb memory accounting is enabled and the allocating process is under a cgroup with a hugetlb limit configured; and (4) the allocation follows the reserved-charge path, i.e. map_chg is set in alloc_hugetlb_folio(). Limiting factors: remote exploitation is impossible (AV:L); systems not using huge pages are entirely unexposed; bare-metal or VM workloads without cgroup hugetlb controllers (e.g., standalone servers not using systemd slice limits or Kubernetes resource limits on hugepages) are not exposed to the specific charge/commit mismatch.

Real-world risk is moderate-to-low for most deployments. The CVSS 3.1 vector (AV:L/AC:L/PR:L) confirms local access with low privileges is required, meaning remote exploitation is not possible. EPSS at 0.21% (11th percentile) aligns with the local-only, non-weaponizable nature of the flaw. The vulnerability is not listed in CISA KEV and no public proof-of-concept has been identified at time of analysis. Despite the high I and A CVSS sub-scores (both H), the practical impact is corrupted hugetlb cgroup accounting leading to kernel WARNINGs and potential accounting drift or system instability rather than an immediate privilege escalation or remote code execution. The mislabeled 'Information Disclosure' tag in ENISA EUVD data is inconsistent with the CVSS C:N metric and the technical description - no confidentiality impact has been confirmed. The flaw is most relevant to cloud, HPC, and database environments that actively allocate huge pages under cgroup memory controllers. Environments without hugetlb usage or without cgroup v2 memory accounting are not exposed to this specific code path.

A local user with standard process privileges on a host where cgroup v2 hugetlb accounting is enforced (common in container runtimes such as systemd-managed cgroups or Kubernetes node configurations) maps a huge page reservation via mmap() with MAP_HUGETLB, triggering alloc_hugetlb_folio() along the map_chg path. The wrong cgroup pointer is silently stored in the folio's reserved slot. When the mapping is released and free_huge_folio() runs, the mismatched uncharge decrements the page_counter of an unrelated cgroup, corrupting accounting state and generating a kernel WARNING, potentially destabilizing cgroup memory limits for co-resident workloads. No public proof-of-concept has been identified, and the attack is opportunistic given the requirement for local access and specific kernel configuration.