CVE-2026-89593

What it actually does

A local Linux kernel logic error in hugetlb unmapping adjusts huge-page reservations without first checking folio mapcount. When a huge-page folio is still mapped in a child after the parent unmaps the range, the reserved-page counter can underflow and wrap or go inconsistent, corrupting kernel huge-page accounting. That corruption can break intended reservation and subpool limits (integrity) and produce allocation failures, warnings, or host instability (availability). Confidentiality is not impacted.

Why it matters to the business

Any Linux host that lets unprivileged users use huge pages (databases, HPC, VMs, developer workstations, multi-tenant nodes) can suffer host-level memory accounting errors, application or kernel disruption, or further abuse of the huge-page pool by a logged-in user. Blast radius is the whole machine, not a single process. This is not listed in CISA KEV, is not associated with ransomware campaigns, has no reported exploit maturity, and EPSS is low and flat (~0.00125 over 30 days). It was published about 37 days ago. Treat it as a real local kernel integrity/availability issue on shared systems, not as an internet-wide emergency. Downstream product lists and exact fixed package versions were not supplied with this record, so exposure depends on whether the running kernel still contains the buggy unmap path.

How an attack unfolds

An attacker who already has a local unprivileged account on an affected kernel allocates huge pages (hugetlbfs or mmap with MAP_HUGETLB) and forks so the same folio remains mapped in parent and child. The parent unmaps the range first. Because __unmap_hugepage_range adjusted reservations without requiring mapcount == 0, the global or subpool reserved count underflows while the child still holds the mapping. The attacker can then consume huge pages beyond configured reservations or induce kernel accounting failures and denial of service. When the child later unmaps, the counter is adjusted again, which can further scramble accounting rather than cleanly repairing it. No named threat actors or in-the-wild campaigns are reported for this issue.

How to fix it

Install and boot a Linux kernel from your distribution that includes the fix titled 'hugetlb: only adjust reservation during unmapping if mapcount is 0' (reservation adjustment in __unmap_hugepage_range only when mapcount is 0). Exact per-package fixed versions were not provided with this record—use the vendor advisory for CVE-2026-89593 or the corresponding stable-kernel commit. Reboot onto the patched kernel. Until then, limit who can allocate huge pages: restrictive hugetlbfs mounts, cgroup hugetlb limits, tight memlock/rlimit and CAP_IPC_LOCK, and avoid granting untrusted users access to MAP_HUGETLB. Systems that do not need huge pages can leave nr_hugepages at 0 and keep hugetlbfs unmounted.

How to confirm the fix worked

Confirm the running kernel package is at or beyond the patched release in the distro advisory and that uname -r matches the patched build after reboot. Check package changelog or kernel git history for the hugetlb unmap mapcount reservation fix. Identify remaining huge-page users via /proc/meminfo (HugePages_*), /sys/kernel/mm/hugepages/, and 'ht' VmFlags in /proc/*/smaps. There is no reliable remote unauthenticated scanner for this local accounting bug; validation is kernel-version and configuration based.

Typical attack path

1. Obtain local unprivileged code execution on a Linux host that allows huge-page allocation
2. Create a hugetlb-backed mapping so a folio is reserved and mapped
3. Fork so the child inherits the mapping (mapcount > 1)
4. Unmap the range in the parent while the child still holds the folio
5. Abuse the underflowed reservation state to exceed huge-page limits or destabilize the kernel
6. Optionally unmap in the child, further distorting reservation accounting

How to detect it

There is no network indicator. Hunt locally for hugetlb activity around fork plus unmap. Review dmesg and journalctl -k for hugetlb warnings, BUGs, or oopses that reference __unmap_hugepage_range or reservation accounting. Compare HugePages_Total/Free/Rsvd/Surp in /proc/meminfo and /sys/kernel/mm/hugepages/ against vm.nr_hugepages; an underflowed counter that wrapped may show as an implausibly large reserved count. Audit logs for mmap/munmap on hugetlbfs and clone/fork by untrusted users can show the setup pattern but are not proof of exploitation. Because the child unmap can restore the counter, a normal-looking reserved count does not prove the bug was never triggered. No APT or ransomware campaigns are associated.

What your security team should do

• Patch and reboot to a kernel that checks mapcount before hugetlb reservation adjustment; prioritize multi-tenant, CI, and developer hosts where unprivileged users can use huge pages
• Inventory where huge pages are actually in use versus merely compiled in, using /proc/meminfo and hugetlbfs mounts
• Until patched, restrict unprivileged huge-page allocation with mount permissions, cgroups, and memlock limits
• Watch kernel logs and HugePages_Rsvd/Surp for unexplained swings after fork/unmap of hugetlb mappings
• Do not treat this as KEV/ransomware urgency (EPSS ~0.00125, no known exploitation), but do not ignore High local I/A kernel bugs on shared infrastructure
• Track distribution kernel advisories because this record does not list affected products or exact fixed versions