The bug in the Linux kernel’s memory management subsystem arises when dissolve_free_hugetlb_folio() fails to check whether a gigantic page lacks runtime support. This oversight leads the routine to free a folio that remains registered in the free list. If a subsequent vmemmap restore fails, add_hugetlb_folio() rolls back, leaving the free list corrupted. The corrupted state can cause incorrect memory allocation, kernel panics, or arbitrary kernel memory writes, which in turn could compromise system availability and potentially elevate privileges. The weakness is a failure to validate input resources before deallocation, consistent with CWE-754.

Any Linux kernel instance that compiles the default kernel memory management code and has hugetlb support enabled is potentially affected. The vulnerability is present in the Linux kernel tree prior to the commit that added the missing runtime check; specific version ranges are not specified in the data, so all kernels before the fix should be considered at risk. Users who have applied recent kernels that include the commit are not affected.

No CVSS score is provided, and the EPSS score is unavailable, so the quantitative assessment of likelihood is incomplete. The vulnerability is not listed in CISA’s KEV catalog, indicating no known active exploitation. The bug requires the attacker to trigger a membrane‑mapping failure while the kernel is handling hugetlb pages, a scenario that ordinarily demands local or privileged access. However, once the corruption occurs, an attacker could potentially leverage the inconsistent free list to perform arbitrary memory writes, raising the risk of a full privilege escalation. Because the exact exploitation path is not publicly documented, the overall risk is considered uncertain but non‑negligible for systems that rely on gigantic hugetlb pages.