CVE-2026-23100

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().