Look up another CVE · open CVE-2026-63875 in the interactive tracker
CVE-2026-63875
arm64: tlb: Flush walk cache when unsharing PMD tables
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem arch/arm64. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-63875 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.176-1 | Update the kernel and reboot. Fixed in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
When huge_pmd_unshare() is called to unshare a PMD table, the tlb_unshare_pmd_ptdesc() function sets tlb->unshared_tables=true but the aarch64 tlb_flush() only checked tlb->freed_tables to determine whether to use TLBF_NONE (vae1is, invalidates walk cache) or TLBF_NOWALKCACHE (vale1is, leaf-only). This caused the stale PMD page table entry to remain in the walk cache after unshare, potentially leading to incorrect page table walks. Fix by including unshared_tables in the check, so that when unsharing tables, TLBF_NONE is used and the walk cache is properly invalidated. Here is the detailed distinction between vae1is and vale1is: | Instruction Combination | Actual Invalidation Scope | | ------------------------ | --------------------------------------------------| | `VAE1IS` + TTL=`0` | All entries at all levels (full invalidation) | | `VAE1IS` + TTL=`2` (L2) | Non-leaf at Level 0/1 + leaf at Level 2 | | `VALE1IS` + TTL=`0` | Leaf entries at all levels (non-leaf not cleared) | | `VALE1IS` + TTL=`2` (L2) | Leaf entry at Level 2 only |
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
arch/arm64/include/asm/tlb.h
- What this is
- MMU GATHER AND TLB INVALIDATIONMAINTAINERS section matched on arch/*/include/asm/tlb.h · linux-arch@vger.kernel.org · Maintained
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- arch/arm64
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.10.253 | 5.10.259 | dced308d7d6a |
| 5.15.203 | 5.15.210 | 47490bbb05c8 |
| 6.1.167 | 6.1.176 | 0199c9d57861 |
| 6.6.127 | 6.6.143 | d766a49d9b55 |
| 6.12.74 | 6.12.93 | 8ca7284da0e6 |
| 6.18.13 | 6.18.35 | fe93e907b1af |
| 6.19 | 7.0.12 | 48125cd9c55c |
| 6.19 | 7.1 | c2ff4764e03e |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerable `tlb_flush()` path is only reached through local memory-management syscalls (mmap/munmap/mprotect/mremap/fork) operating on hugetlb VMAs, not through any network-facing kernel service.
- AC:LAttack complexity, low
- An attacker fully controls the trigger sequence—creating shared hugetlbfs mappings (≥1GB PUD-aligned), forking to establish shared PMD tables, and concurrently unmapping/mprotecting/mremapping to force `huge_pmd_unshare()`—with no conditions outside their control.
- PR:LPrivileges required, low
- Exploitation requires only an unprivileged local user capable of mapping shared hugetlb pages via hugetlbfs or SHM_HUGETLB, which is commonly available on arm64 database and container hosts with pre-reserved huge pages.
- UI:NUser interaction, none
- No victim interaction is required; the attacker sets up and triggers the stale walk-cache condition entirely within processes they control.
- S:UScope, unchanged
- Impact is confined to kernel memory-management within the same security authority (incorrect page-table walks and cross-mapping leakage within the kernel), not a VM escape or cross-authority boundary break.
- C:HConfidentiality impact, high
- Stale non-leaf walk-cache entries after `pud_clear()` can cause incorrect page-table walks, enabling reads of memory that should be unmapped or mapped to different physical pages, constituting an arbitrary memory read primitive.
- I:HIntegrity impact, high
- Incorrect translations from stale PMD walk-cache entries can direct stores to unintended physical pages, and freed/reused page-table pages reached via stale cache entries provide a write/corruption primitive exploitable for control-flow hijacking.
- A:HAvailability impact, high
- Stale walk-cache pointers to cleared or freed page-table structures can cause kernel faults, oops, or panics during page walks or concurrent GUP-fast access on the affected address space.