mm/hugetlb: restore failed global reservations to subpool

Summary

CVECVE-2026-43286
StatePUBLISHED
AssignerLinux
Source PriorityCVE Program / NVD first with legacy fallback
Published2026-05-08 14:16:35 UTC
Updated2026-05-12 14:10:27 UTC
DescriptionIn 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.

Risk And Classification

EPSS: 0.000170000 probability, percentile 0.041320000 (date 2026-05-12)

Vendor Declared Affected Products

SourceVendorProductVersionPlatforms
CNA Linux Linux affected a833a693a490ecff8ba377654c6d4d333718b6b1 5eac1322a7b14b8cd05ec896618278b90fba7f39 git Not specified
CNA Linux Linux affected a833a693a490ecff8ba377654c6d4d333718b6b1 f055897c975d079a90af873c791ab58cf0f6f2a5 git Not specified
CNA Linux Linux affected a833a693a490ecff8ba377654c6d4d333718b6b1 1d3f9bb4c8af70304d19c22e30f5d16a2d589bb5 git Not specified
CNA Linux Linux affected adb5c2e55524e3a96b02c3904b0bb6d5a5404d21 git Not specified
CNA Linux Linux affected 6.15 Not specified
CNA Linux Linux unaffected 6.15 semver Not specified
CNA Linux Linux unaffected 6.18.16 6.18.* semver Not specified
CNA Linux Linux unaffected 6.19.6 6.19.* semver Not specified
CNA Linux Linux unaffected 7.0 * original_commit_for_fix Not specified

References

ReferenceSourceLinkTags
git.kernel.org/stable/c/f055897c975d079a90af873c791ab58cf0f6f2a5 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/5eac1322a7b14b8cd05ec896618278b90fba7f39 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/1d3f9bb4c8af70304d19c22e30f5d16a2d589bb5 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
CVE Program record CVE.ORG www.cve.org canonical
NVD vulnerability detail NVD nvd.nist.gov canonical, analysis
© CVE.report 2026 |

Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content. EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site. ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT, INDIRECT or any other kind of loss.

CVE, CWE, and OVAL are registred trademarks of The MITRE Corporation and the authoritative source of CVE content is MITRE's CVE web site. This site includes MITRE data granted under the following license.

Free CVE JSON API cve.report/api

CVE.report and Source URL Uptime Status status.cve.report