CVE-2026-23100
Unknown Unknown - Not Provided
Incorrect Shared PMD Table Handling in Linux Kernel hugetlb Causes Memory Accounting Errors

Publication date: 2026-02-04

Last updated on: 2026-04-18

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb_pmd_shared() Patch series "mm/hugetlb: fixes for PMD table sharing (incl. using mmu_gather)", v3. One functional fix, one performance regression fix, and two related comment fixes. I cleaned up my prototype I recently shared [1] for the performance fix, deferring most of the cleanups I had in the prototype to a later point. While doing that I identified the other things. The goal of this patch set is to be backported to stable trees "fairly" easily. At least patch #1 and #4. Patch #1 fixes hugetlb_pmd_shared() not detecting any sharing Patch #2 + #3 are simple comment fixes that patch #4 interacts with. Patch #4 is a fix for the reported performance regression due to excessive IPI broadcasts during fork()+exit(). The last patch is all about TLB flushes, IPIs and mmu_gather. Read: complicated There are plenty of cleanups in the future to be had + one reasonable optimization on x86. But that's all out of scope for this series. Runtime tested, with a focus on fixing the performance regression using the original reproducer [2] on x86. This patch (of 4): We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->pt_share_count to identify sharing. We didn't convert hugetlb_pmd_shared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table. Page migration, like mbind() or migrate_pages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as "private" although they are "shared", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the pagemap interface. Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared().
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-04
Last Modified
2026-04-18
Generated
2026-05-27
AI Q&A
2026-02-04
EPSS Evaluated
2026-05-25
NVD
CVE-2026-23100
EUVD
EUVD-2026-5442
Affected Vendors & Products
Showing 15 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.13
linux linux_kernel 6.13
linux linux_kernel 6.13
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 5.10.239 (inc) to 5.11 (exc)
linux linux_kernel From 5.15.186 (inc) to 5.16 (exc)
linux linux_kernel From 6.1.142 (inc) to 6.2 (exc)
linux linux_kernel From 6.12.9 (inc) to 6.12.74 (exc)
linux linux_kernel From 6.13.1 (inc) to 6.18.8 (exc)
linux linux_kernel From 6.6.72 (inc) to 6.6.127 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is in the Linux kernel's memory management subsystem, specifically related to huge page tables (hugetlb). The issue was that the function hugetlb_pmd_shared() did not correctly detect when page middle directory (PMD) tables were shared. This happened because the code was using the page count as a reference count, which became inaccurate after changes that introduced an independent shared count (ptdesc->pt_share_count). As a result, shared PMD tables were never recognized as shared.

This flaw allowed operations like page migration (e.g., mbind() or migrate_pages()) to migrate memory pages that were mapped into these shared PMD tables, even though those pages were not exclusively owned. Additionally, memory accounting tools (like smaps) would incorrectly mark these pages as private instead of shared, and the PM_MMAP_EXCLUSIVE flag was wrongly set in the pagemap interface.

The vulnerability was fixed by updating hugetlb_pmd_shared() to properly use the new shared count mechanism (ptdesc_pmd_is_shared()) to detect shared PMD tables correctly.


How can this vulnerability impact me? :

This vulnerability can impact system stability and memory management correctness. Because shared huge page tables were not properly detected, memory pages could be migrated incorrectly, potentially leading to inconsistent memory states or performance regressions.

Memory accounting tools might report inaccurate information about memory usage, which could affect monitoring, debugging, or resource management decisions.

While the description does not explicitly mention security exploits such as privilege escalation or data leakage, incorrect handling of shared memory mappings could theoretically lead to unexpected behavior in applications relying on huge pages.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

I don't know


What immediate steps should I take to mitigate this vulnerability?

I don't know


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart