CVE-2026-89593: hugetlb: only adjust reservation during unmapping if mapcount is 0
In the Linux kernel, the following vulnerability has been resolved:
hugetlb: only adjust reservation during unmapping if mapcount is 0
Since df7a6d1f6405, unmaphugepagerange can adjust reservations. In the case of folio mapped in both a parent and a child, if the parent unmaps the range first, the reservation adjustment will result in an underflow of the reserved count. Once the child unmaps the range, the count is restored. Change unmaphugepagerange() to check the mapcount before adjusting the reservation.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the Linux kernel hugetlb logic so that __unmap_hugepage_range adjusts the reservation only during unmapping when mapcount is 0 (i.e., check mapcount before adjusting the reservation to avoid reserved-count underflow).
Linux kernel hugetlb __unmap_hugepage_range reservation adjustment condition = only adjust reservation during unmapping if mapcount is 0
Event History
Frequently Asked Questions
What conditions are required to trigger the reservation-count underflow?
A huge-page folio must be mapped by both a parent and child, and the parent must unmap the range before the child. In that order, reservation adjustment during the parent's unmap can underflow the reserved count until the child later unmaps.
How can I tell whether a kernel is affected?
The issue is associated with kernels containing commit df7a6d1f6405 and lacking the change that makes __unmap_hugepage_range() check mapcount before adjusting reservations. The provided stable-kernel references identify commits containing the resolution.