CVE-2026-43286
Received Received - Intake
Memory Corruption in Linux Kernel HugeTLB Subsystem

Publication date: 2026-05-08

Last updated on: 2026-05-08

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore failed global reservations to subpool Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") fixed an underflow error for hstate->resv_huge_pages caused by incorrectly attributing globally requested pages to the subpool's reservation. Unfortunately, this fix also introduced the opposite problem, which would leave spool->used_hpages elevated if the globally requested pages could not be acquired. This is because while a subpool's reserve pages only accounts for what is requested and allocated from the subpool, its "used" counter keeps track of what is consumed in total, both from the subpool and globally. Thus, we need to adjust spool->used_hpages in the other direction, and make sure that globally requested pages are uncharged from the subpool's used counter. Each failed allocation attempt increments the used_hpages counter by how many pages were requested from the global pool. Ultimately, this renders the subpool unusable, as used_hpages approaches the max limit. The issue can be reproduced as follows: 1. Allocate 4 hugetlb pages 2. Create a hugetlb mount with max=4, min=2 3. Consume 2 pages globally 4. Request 3 pages from the subpool (2 from subpool + 1 from global) 4.1 hugepage_subpool_get_pages(spool, 3) succeeds. used_hpages += 3 4.2 hugetlb_acct_memory(h, 1) fails: no global pages left used_hpages -= 2 5. Subpool now has used_hpages = 1, despite not being able to successfully allocate any hugepages. It believes it can now only allocate 3 more hugepages, not 4. With each failed allocation attempt incrementing the used counter, the subpool eventually reaches a point where its used counter equals its max counter. At that point, any future allocations that try to allocate hugeTLB pages from the subpool will fail, despite the subpool not having any of its hugeTLB pages consumed by any user. Once this happens, there is no way to make the subpool usable again, since there is no way to decrement the used counter as no process is really consuming the hugeTLB pages. The underflow issue that the original commit fixes still remains fixed as well. Without this fix, used_hpages would keep on leaking if hugetlb_acct_memory() fails.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-08
Last Modified
2026-05-08
Generated
2026-05-09
AI Q&A
2026-05-08
EPSS Evaluated
N/A
NVD
CVE-2026-43286
EUVD
EUVD-2026-28556
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's hugetlb subsystem, specifically related to how huge page allocations are tracked in subpools.

A recent fix intended to correct an underflow error in the accounting of huge pages introduced a new problem where the subpool's used huge pages counter (used_hpages) can become incorrectly elevated when global huge page allocation requests fail.

When a process requests huge pages, the system tries to allocate from both the subpool and the global pool. If the global allocation fails, the used_hpages counter in the subpool is still incremented incorrectly, making the subpool believe it has fewer available pages than it actually does.

Over time, repeated failed allocation attempts cause the subpool's used_hpages counter to reach its maximum limit, preventing any further huge page allocations from the subpool even though no pages are truly in use.

This results in the subpool becoming unusable, as the accounting error prevents it from allocating huge pages despite availability.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel's huge page subpool to become unusable due to incorrect accounting of huge page usage.

If you rely on huge pages for performance optimization or memory management, this issue can lead to allocation failures even when huge pages are available.

Applications or services that depend on huge page allocations may experience failures or degraded performance because the subpool incorrectly believes it has exhausted its huge page quota.

Since the subpool cannot recover from this state without a system restart or patch, it can cause prolonged resource allocation issues.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart