{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2026-43286 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-43286 is a medium-severity denial of service vulnerability in Linux kernel, published on 8 May 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-43286 and fix it if it is affected.\n\nWhat it is: CVE-2026-43286 is a medium-severity denial of service vulnerability in Linux kernel, published on 8 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-43286 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-43286/ (Markdown: https://insights.sbomify.com/CVE-2026-43286/index.md)","id":"CVE-2026-43286","markdown":"https://insights.sbomify.com/CVE-2026-43286/index.md","name":"CVE-2026-43286","record":{"aliases":["BELL-CVE-2026-43286","DEBIAN-CVE-2026-43286","GHSA-ghpp-gwgc-8pq9","UBUNTU-CVE-2026-43286"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A logic error in Linux kernel hugetlb subpool accounting causes resource exhaustion, preventing future hugepage allocations and leading to denial of service.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":5.5,"severity":"medium","source":"nvd","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"cwes":[{"id":"CWE-401","name":"Missing Release of Memory after Effective Lifetime"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: restore failed global reservations to subpool\n\nCommit a833a693a490 (\"mm: hugetlb: fix incorrect fallback for subpool\")\nfixed an underflow error for hstate-\u003eresv_huge_pages caused by incorrectly\nattributing globally requested pages to the subpool's reservation.\n\nUnfortunately, this fix also introduced the opposite problem, which would\nleave spool-\u003eused_hpages elevated if the globally requested pages could\nnot be acquired.  This is because while a subpool's reserve pages only\naccounts for what is requested and allocated from the subpool, its \"used\"\ncounter keeps track of what is consumed in total, both from the subpool\nand globally.  Thus, we need to adjust spool-\u003eused_hpages in the other\ndirection, and make sure that globally requested pages are uncharged from\nthe subpool's used counter.\n\nEach failed allocation attempt increments the used_hpages counter by how\nmany pages were requested from the global pool.  Ultimately, this renders\nthe subpool unusable, as used_hpages approaches the max limit.\n\nThe issue can be reproduced as follows:\n1. Allocate 4 hugetlb pages\n2. Create a hugetlb mount with max=4, min=2\n3. Consume 2 pages globally\n4. Request 3 pages from the subpool (2 from subpool + 1 from global)\n\t4.1 hugepage_subpool_get_pages(spool, 3) succeeds.\n\t\tused_hpages += 3\n\t4.2 hugetlb_acct_memory(h, 1) fails: no global pages left\n\t\tused_hpages -= 2\n5. Subpool now has used_hpages = 1, despite not being able to\n   successfully allocate any hugepages. It believes it can now only\n   allocate 3 more hugepages, not 4.\n\nWith each failed allocation attempt incrementing the used counter, the\nsubpool eventually reaches a point where its used counter equals its\nmax counter.  At that point, any future allocations that try to\nallocate hugeTLB pages from the subpool will fail, despite the subpool\nnot having any of its hugeTLB pages consumed by any user.\n\nOnce this happens, there is no way to make the subpool usable again,\nsince there is no way to decrement the used counter as no process is\nreally consuming the hugeTLB pages.\n\nThe underflow issue that the original commit fixes still remains fixed\nas well.\n\nWithout this fix, used_hpages would keep on leaking if\nhugetlb_acct_memory() fails.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"mm/hugetlb: restore failed global reservations to subpool","id":"CVE-2026-43286","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"denial_of_service","year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"drm: Account property blob allocations to memcg","id":"CVE-2026-43287"},"packages":[],"prev":{"headline":"mm/slab: do not access current-\u003emems_allowed_seq if !allow_spin","id":"CVE-2026-43285"},"products":["Linux"],"published":"2026-05-08","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-05-23","vendors":["Linux"]},"summary":"A logic error in Linux kernel hugetlb subpool accounting causes resource exhaustion, preventing future hugepage allocations and leading to denial of service.","url":"https://insights.sbomify.com/CVE-2026-43286/"}