Linux arm64: stale page-table entry left in the walk cache when a hugetlb PMD table is unshared

CVSS 7.8CVE-2026-63875Kernel, userspace & hypervisorcurated

Impact

On arm64, tlb_flush() decided between a full invalidate and a leaf-only invalidate using only tlb->freed_tables, ignoring the unshared_tables flag set when huge_pmd_unshare() tears down a shared PMD table. The non-leaf entry for the unshared table therefore stayed in the walk cache, so the CPU could keep walking through a page table that is no longer the right one - stale translations, with the usual consequences of a page table the hardware and the kernel disagree about. This lands on arm64 server fleets - Grace, Ampere, Graviton-class nodes - specifically where hugetlbfs page-table sharing is in use, which is common for large-page allocations backing accelerator workloads. x86 nodes are not affected by this arch-specific path.

Who can reach it

Local - a process using hugetlbfs with shared PMD tables on an arm64 host. Unprivileged if hugetlbfs is exposed to tenants; no network path.

What to do

Update to a stable kernel that includes unshared_tables in the arm64 tlb_flush() decision. Disabling hugetlbfs PMD sharing avoids the path at a performance cost on large-page workloads. The fix is arch kernel code, so affected arm64 nodes must be drained and rebooted.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-63875 https://git.kernel.org/stable/c/0199c9d57861f17b556b6cba1f765c7cce79745b https://git.kernel.org/stable/c/47490bbb05c8c0e09cc3cfd237d8934ffc340583 https://git.kernel.org/stable/c/48125cd9c55cbe297b59fd1f9bda48b0960bd181

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.