Executive brief
The Linux kernel's hugetlb memory management system has a flaw in how it tracks reserved memory when unmapping pages. When a memory region is mapped by both a parent and child process, the parent's unmapping can cause an incorrect reduction in the reservation count, potentially corrupting memory accounting. This could lead to kernel crashes, denial of service, or memory exhaustion attacks on systems using huge pages.
Technical details
The vulnerability exists in the __unmap_hugepage_range() function in mm/hugetlb.c. Since commit df7a6d1f6405, the function attempts to restore memory reservations during unmapping of huge pages. The flaw occurs when a huge page is mapped in both a parent and child process: if the parent unmaps the range first, the reservation count is decremented despite the page still being mapped by the child, causing an integer underflow in the reserved page counter. When the child later unmaps the page, the count is restored, but the intermediate underflow can corrupt memory accounting. The fix adds a mapcount check (!folio_mapped()) before adjusting the reservation, ensuring restoration only occurs on the final unmap. A local attacker with the ability to use huge pages can exploit this through fork/mmap operations.
Affected products
- Linux Linux kernel Multiple versions from 2.6.11 through 7.2 (introduced in df7a6d1f6405, patched in 5120b1e048d48596ffaec1a8412012a91adba73b)
Timeline
- 2026-09-11: disclosed: CVE published on NVD
- 2026-08-24: patched: Fix merged upstream as commit 5120b1e048d48596ffaec1a8412012a91adba73b
- 2026-07-28: other: Fix authored by Guillaume Morin