Live › vulnerability › CVE-2026-98506
Go to dashboardIn the Linux kernel's hugetlb memory code, dissolving a free gigantic page does not check whether runtime support exists, so the page can be freed while still on the free list. On a vmemmap restore failure, the rollback then corrupts the free list, which can crash the kernel.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with hugetlb gigantic pages in use, where runtime gigantic page support is absent and memory is freed or dissolved at runtime. The sources do not describe a specific configuration, so the exact exposure is unknown. Hosts that never allocate hugetlb gigantic pages are probably less exposed, but the sources do not confirm this.
No product ranges from the sources yet.
uname -r to see the running kernel versionEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: do not dissolve gigantic pages without runtime support
dissolve_free_hugetlb_folio() doesn't check hstate_is_gigantic_no_runtime(h) though remove_hugetlb_folio()/ update_and_free_hugetlb_folio() silently bail for such folios, so it frees a still-listed folio and, on vmemmap restore failure, the add_hugetlb_folio() rollback corrupts the free list.
This page as .md · .json · in your agent: get_signal("CVE-2026-98506")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.