Cloudanix VulnDB

CVE-2026-98506

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug in handling very large memory pages can cause crashes or memory problems on affected systems.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Frees a still-listed gigantic hugetlb folio without checking hstate_is_gigantic_no_runtime, allowing update_and_free_hugetlb_folio to bail silently and causing add_hugetlb_folio rollback to corrupt the free list on vmemmap restore failure.

Why it matters to the business

May trigger kernel instability, crashes, or memory corruption on Linux systems configured with gigantic huge pages, leading to unplanned downtime or service disruption.

How an attack unfolds

An attacker with local code execution or the ability to influence hugetlb folio operations triggers dissolve_free_hugetlb_folio on a gigantic page, relying on the missing runtime check to reach the free-list corruption path during vmemmap failure rollback.

How to fix it

Apply the upstream kernel commit that adds the hstate_is_gigantic_no_runtime guard inside dissolve_free_hugetlb_folio; rebuild and deploy the fixed kernel on all affected systems.

How to confirm the fix worked

Inspect the mm/hugetlb.c source for the presence of the hstate_is_gigantic_no_runtime check before the dissolve path and confirm the kernel binary contains the patched function.

Typical attack path

  1. Obtain local execution or trigger memory operations that affect hugetlb gigantic pages
  2. Invoke dissolve_free_hugetlb_folio on a gigantic folio without runtime support
  3. Force a vmemmap restore failure during folio removal
  4. Trigger the erroneous add_hugetlb_folio rollback that corrupts the free list

How to detect it

Search kernel logs and crash dumps for messages referencing hugetlb folio operations, vmemmap restore failures, or corruption in the gigantic page free list.

What your security team should do

  • Prioritize kernel updates for systems that enable gigantic huge pages
  • Review hugetlb configuration and disable gigantic pages where operationally feasible
  • Monitor kernel logs for hugetlb-related panics or free-list warnings

The record

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.

Affected packages

Ecosystem Package Introduced Fixed