Skip to main content

Linux Kernel EUVDEUVD-2026-28556

| CVE-2026-43286 MEDIUM
Memory Leak (CWE-401)
2026-05-08 Linux GHSA-ghpp-gwgc-8pq9
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
MEDIUM
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

4
Analysis Generated
May 15, 2026 - 17:08 vuln.today
CVSS changed
May 15, 2026 - 17:07 NVD
5.5 (MEDIUM)
Patch available
May 08, 2026 - 14:02 EUVD
CVE Published
May 08, 2026 - 13:11 nvd
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb: restore failed global reservations to subpool

Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") fixed an underflow error for hstate->resv_huge_pages caused by incorrectly attributing globally requested pages to the subpool's reservation.

Unfortunately, this fix also introduced the opposite problem, which would leave spool->used_hpages elevated if the globally requested pages could not be acquired. This is because while a subpool's reserve pages only accounts for what is requested and allocated from the subpool, its "used" counter keeps track of what is consumed in total, both from the subpool and globally. Thus, we need to adjust spool->used_hpages in the other direction, and make sure that globally requested pages are uncharged from the subpool's used counter.

Each failed allocation attempt increments the used_hpages counter by how many pages were requested from the global pool. Ultimately, this renders the subpool unusable, as used_hpages approaches the max limit.

The issue can be reproduced as follows:

  1. Allocate 4 hugetlb pages
  2. Create a hugetlb mount with max=4, min=2
  3. Consume 2 pages globally
  4. Request 3 pages from the subpool (2 from subpool + 1 from global)

4.1 hugepage_subpool_get_pages(spool, 3) succeeds. used_hpages += 3 4.2 hugetlb_acct_memory(h, 1) fails: no global pages left used_hpages -= 2

  1. Subpool now has used_hpages = 1, despite not being able to

successfully allocate any hugepages. It believes it can now only allocate 3 more hugepages, not 4.

With each failed allocation attempt incrementing the used counter, the subpool eventually reaches a point where its used counter equals its max counter. At that point, any future allocations that try to allocate hugeTLB pages from the subpool will fail, despite the subpool not having any of its hugeTLB pages consumed by any user.

Once this happens, there is no way to make the subpool usable again, since there is no way to decrement the used counter as no process is really consuming the hugeTLB pages.

The underflow issue that the original commit fixes still remains fixed as well.

Without this fix, used_hpages would keep on leaking if hugetlb_acct_memory() fails.

AnalysisAI

Memory accounting errors in Linux kernel hugetlb subsystem cause subpool reservation counters to incorrectly increment on failed global allocations, eventually rendering hugetlb subpools permanently unusable. The vulnerability affects Linux kernels from 6.15 onward where commit a833a693a490 introduced the flaw. When a process requests hugepages that require both subpool and global pool resources, failed global allocations leave the subpool's used_hpages counter elevated despite no actual page consumption, progressively exhausting the subpool's apparent capacity until all future allocations fail. Patches available for kernels 6.18.16, 6.19.6, and 7.0. EPSS score of 0.02% and lack of KEV listing indicate low exploitation probability, though local authenticated attackers can trigger the condition to cause denial of service against hugetlb-dependent workloads.

Technical ContextAI

Hugetlb is the Linux kernel's mechanism for managing huge pages (typically 2MB or 1GB) to reduce TLB pressure for memory-intensive applications. Subpools provide per-mount or per-process reservation tracking separate from the global hugetlb pool. The vulnerability stems from CWE-401 (Missing Release of Memory after Effective Lifetime) in the reservation accounting logic at mm/hugetlb.c. When hugepage_subpool_get_pages() succeeds but subsequent hugetlb_acct_memory() fails due to global pool exhaustion, the code incorrectly decrements only the reserved pages (by 2 in the reproduction case) but leaves the total used_hpages counter elevated (by 1). The affected CPE cpe:2.3:a:linux:linux indicates this impacts the core kernel memory management subsystem. Each failed allocation attempt compounds the accounting error, creating a resource leak where the subpool believes it has allocated pages that were never actually acquired.

RemediationAI

Upgrade to patched kernel versions: 6.18.16 or later for the 6.18 LTS series, 6.19.6 or later for 6.19 stable, or 7.0 final release. Patches are available from kernel.org stable trees at the git commit URLs provided in references. For systems unable to immediately upgrade, implement compensating controls: restrict hugetlb mount creation to trusted administrative users via mount namespace isolation or AppArmor/SELinux policies blocking unconfined users from mounting hugetlbfs. Monitor subpool usage with /proc/meminfo HugePages metrics and /sys/kernel/mm/hugepages statistics, alerting on used_hpages increases without corresponding allocation success. Temporarily disable hugetlb subpool features by using only global pool allocations (removing min/max mount options) if workload permits, though this sacrifices reservation guarantees. Note that mount option changes require remounting filesystems. For containerized workloads, pin to patched host kernels rather than attempting in-container mitigations. Backport commit 1d3f9bb4c8af if running custom kernel builds. No runtime workaround exists to reset corrupted subpool counters short of unmounting and remounting hugetlbfs, which requires terminating all processes using those hugepages.

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

EUVD-2026-28556 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy