CVE-2026-43286: Linux Kernel DOS Vulnerability

CVE-2026-43286 Overview

CVE-2026-43286 is a memory accounting flaw in the Linux kernel's hugetlb subsystem. The vulnerability resides in mm/hugetlb subpool reservation handling. Failed global page reservations are not properly restored to the subpool's used_hpages counter. Each failed allocation attempt incrementally leaks accounting, eventually rendering the subpool unusable for hugeTLB page allocations. The flaw was introduced by commit a833a693a490 which fixed an earlier underflow but created an inverse leak. This vulnerability affects Linux kernel versions 6.15 and the 7.0 release candidate series. It is classified under [CWE-401] Missing Release of Memory after Effective Lifetime.

Critical Impact

A local user can trigger repeated failed hugeTLB allocations to permanently exhaust subpool accounting, causing denial of service for applications that depend on hugepages.

Affected Products

• Linux kernel 6.15
• Linux kernel 7.0 release candidates (rc1 through rc7)
• Distributions shipping kernels with commit a833a693a490 applied

Discovery Timeline

• 2026-05-08 - CVE-2026-43286 published to NVD
• 2026-05-15 - Last updated in NVD database

Technical Details for CVE-2026-43286

Vulnerability Analysis

The vulnerability lives in the Linux kernel hugetlb subpool accounting logic. A hugetlb subpool tracks two counters: resv_huge_pages for reservations made from the subpool, and used_hpages for total pages consumed both from the subpool and globally. When a process requests more pages than the subpool can satisfy, the kernel attempts to allocate additional pages from the global pool through hugetlb_acct_memory().

The earlier fix in commit a833a693a490 corrected an underflow in hstate->resv_huge_pages but did not adjust spool->used_hpages symmetrically. When the global allocation fails, the previously incremented used_hpages counter is never decremented for the failed portion. This produces a one-way counter leak per failed request.

Root Cause

The root cause is asymmetric counter maintenance during failure paths in hugepage_subpool_get_pages(). The function increments used_hpages by the full request size before calling hugetlb_acct_memory(). On failure, only the subpool reservation is rolled back. Globally requested pages remain charged to used_hpages despite no actual allocation occurring, violating the invariant that used_hpages reflects pages currently held by users.

Attack Vector

Exploitation requires local access with the ability to mount or use a hugetlb filesystem. The reproduction sequence is: allocate 4 hugetlb pages, create a hugetlb mount with max=4, min=2, consume 2 pages globally, then request 3 pages from the subpool. The subpool request succeeds in incrementing used_hpages by 3, but hugetlb_acct_memory(h, 1) fails because no global pages remain. Only 2 are returned, leaving used_hpages = 1 with zero actual consumption. Repeating this pattern drives used_hpages toward the maximum, after which all legitimate allocations fail. Recovery requires unmounting and remounting the hugetlb filesystem because no process holds the leaked accounting.

Detection Methods for CVE-2026-43286

Indicators of Compromise

• Hugetlb allocation failures (ENOSPC or ENOMEM) on a subpool whose visible page consumption is significantly lower than its configured maximum.
• Discrepancy between /sys/kernel/mm/hugepages/ global counters and per-mount hugetlb usage statistics.
• Applications using MAP_HUGETLB or hugetlbfs mounts reporting persistent allocation failures that resolve only after remount.

Detection Strategies

• Audit kernel versions across the fleet for builds containing commit a833a693a490 without the corrective patches listed in the vendor advisory.
• Monitor system logs and application telemetry for repeated hugetlb_acct_memory failures correlated with the same hugetlb mount.
• Compare reported subpool used_hpages against the actual count of pages mapped by user processes to detect drift.

Monitoring Recommendations

• Track hugepage allocation failure rates per cgroup and per hugetlb mountpoint as a baseline metric.
• Alert on hugetlb mounts whose used counter grows without a corresponding increase in mapped processes.
• Forward kernel dmesg and audit events for hugetlb-related warnings to centralized logging for correlation.

How to Mitigate CVE-2026-43286

Immediate Actions Required

• Apply the upstream kernel patches referenced in Kernel Git Commit 1d3f9bb, Kernel Git Commit 5eac132, and Kernel Git Commit f055897.
• Restrict access to hugetlbfs mount creation to trusted system roles where feasible.
• Reboot or remount affected hugetlb mounts that have entered the leaked-accounting state to restore service.

Patch Information

The fix restores failed global reservations to the subpool's used_hpages counter, ensuring symmetric accounting on the failure path. Distribution maintainers should backport the referenced commits to stable kernel branches affected by commit a833a693a490. Verify the patch is present by inspecting mm/hugetlb.c for the corrective decrement logic in hugepage_subpool_get_pages().

Workarounds

• Avoid configuring hugetlb subpools where the maximum exceeds available global pages, reducing the likelihood of triggering the failure path.
• Provision sufficient global hugepages so that hugetlb_acct_memory() does not need to fail under normal workload conditions.
• Schedule periodic remounts of long-lived hugetlb filesystems as a stopgap until the patched kernel can be deployed.

# Verify running kernel version and hugepage configuration
uname -r
cat /proc/meminfo | grep -i huge
cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages