GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel hugetlb: reservation counter underflow when a parent unmaps a shared huge page first

UnscoredCVE-2026-89593Kernel, userspace & hypervisorcurated

Impact

Since the change that let __unmap_hugepage_range() adjust reservations, a huge page folio mapped in both a parent and a child underflows the reserved count if the parent unmaps the range first; the count is restored only once the child unmaps. Hugepages are standard on GPU nodes for large-model memory and for VFIO-backed guests, and a transiently wrong reservation count means hugetlb accounting misreports available pages - allocations can be refused or admitted incorrectly during the window. The record describes an accounting bug with a local trigger (fork plus unmap ordering), not memory corruption, and gives no CVSS score or CWE.

Who can reach it

Local unprivileged user on the node who can map a hugetlbfs region and fork; the underflow follows from ordinary unmap ordering between parent and child. No remote path and no privileged access required.

What to do

Patch the host kernel to a stable release that checks mapcount before adjusting the reservation in __unmap_hugepage_range() (commits below), then drain and reboot the node - hugetlb is built into the kernel, so there is no live-patch path in the record. No vendor fixed-version string is given beyond the stable commits.

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.