GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel mm/hugetlb: rsvd cgroup charge recorded against the wrong cgroup, causing counter underflow

CVSS 7.1CVE-2026-72213Kernel, userspace & hypervisorcurated

Impact

alloc_hugetlb_folio() reused one h_cg pointer for both the reservation and non-reservation hugetlb cgroup charges, so the folio's rsvd slot stored the non-rsvd cgroup. Freeing the folio then uncharges a cgroup that was never charged, underflowing the page_counter and raising a WARNING in page_counter_cancel(). The practical effect is corrupted hugetlb cgroup accounting: limits stop reflecting reality, which on a GPU node matters because hugepages back pinned host buffers for RDMA and GPU DMA, and per-container hugetlb limits are how operators keep one tenant from starving the others of hugepages. A local user able to allocate hugetlb pages inside a cgroup can drive the mismatch; it is an integrity and availability problem in the accounting path, not a memory-disclosure or privilege-escalation path.

Who can reach it

Local unprivileged user in a cgroup with hugetlb reservations enabled who can map and free hugetlb-backed memory. Authentication to the node (a shell or a pod) is required; not reachable from the network.

What to do

Pick up the stable kernel commits linked in the record (a separate h_cg_rsvd pointer for the reservation path) via your distribution's kernel update. Applying it means booting the patched kernel, so each node must be drained and rebooted. Interim mitigation is to avoid relying on hugetlb cgroup reservation limits for isolation until the patched kernel is in place.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.