CVE-2026-43286

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: restore failed global reservations to subpool<br /> <br /> Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool")<br /> fixed an underflow error for hstate-&gt;resv_huge_pages caused by incorrectly<br /> attributing globally requested pages to the subpool&amp;#39;s reservation.<br /> <br /> Unfortunately, this fix also introduced the opposite problem, which would<br /> leave spool-&gt;used_hpages elevated if the globally requested pages could<br /> not be acquired. This is because while a subpool&amp;#39;s reserve pages only<br /> accounts for what is requested and allocated from the subpool, its "used"<br /> counter keeps track of what is consumed in total, both from the subpool<br /> and globally. Thus, we need to adjust spool-&gt;used_hpages in the other<br /> direction, and make sure that globally requested pages are uncharged from<br /> the subpool&amp;#39;s used counter.<br /> <br /> Each failed allocation attempt increments the used_hpages counter by how<br /> many pages were requested from the global pool. Ultimately, this renders<br /> the subpool unusable, as used_hpages approaches the max limit.<br /> <br /> The issue can be reproduced as follows:<br /> 1. Allocate 4 hugetlb pages<br /> 2. Create a hugetlb mount with max=4, min=2<br /> 3. Consume 2 pages globally<br /> 4. Request 3 pages from the subpool (2 from subpool + 1 from global)<br /> 4.1 hugepage_subpool_get_pages(spool, 3) succeeds.<br /> used_hpages += 3<br /> 4.2 hugetlb_acct_memory(h, 1) fails: no global pages left<br /> used_hpages -= 2<br /> 5. Subpool now has used_hpages = 1, despite not being able to<br /> successfully allocate any hugepages. It believes it can now only<br /> allocate 3 more hugepages, not 4.<br /> <br /> With each failed allocation attempt incrementing the used counter, the<br /> subpool eventually reaches a point where its used counter equals its<br /> max counter. At that point, any future allocations that try to<br /> allocate hugeTLB pages from the subpool will fail, despite the subpool<br /> not having any of its hugeTLB pages consumed by any user.<br /> <br /> Once this happens, there is no way to make the subpool usable again,<br /> since there is no way to decrement the used counter as no process is<br /> really consuming the hugeTLB pages.<br /> <br /> The underflow issue that the original commit fixes still remains fixed<br /> as well.<br /> <br /> Without this fix, used_hpages would keep on leaking if<br /> hugetlb_acct_memory() fails.