The kernel routine dissolve_free_hugetlb_folio() fails to verify that a gigantic hugetlb folio has runtime support before freeing it, leaving a stale folio on the free list. When a vmemmap restore fails, the add_hugetlb_folio() rollback corrupts the free list. This corruption can lead to incorrect memory allocation, kernel panic, or other memory corruption. The flaw is associated with CWE-826. The impact is a loss of system availability due to potential kernel instability.

All Linux kernel builds that compile the default memory‑management code with hugetlb support enabled are potentially vulnerable. The vulnerability exists in kernels before the commit that introduced the missing runtime check; specific version ranges are not listed, so any unpatched kernel should be considered at risk.

The CVSS score of 4.1 indicates moderate severity. The EPSS score of < 1% suggests a low likelihood of exploitation. The vulnerability is not listed in CISA KEV, indicating no documented active attacks. Exploitation would require a vmemmap restore failure during hugetlb page handling, a scenario that typically demands local or privileged access. The impact is limited to system instability and memory corruption, with no evidence of privilege escalation in the available information.