arm64: tlb: Flush walk cache when unsharing PMD tables
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
In the Linux kernel, the following vulnerability has been resolved: arm64: tlb: Flush walk cache when unsharing PMD tables 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 |
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From 6495204f8219a57859669d618b25d06176d5a872 · fixed in dced308d7d6a0de1c09d2058f38f1aaaf5cbb914; From ce4cf24761467756462c0e1dbe4a5e9c9eb520fc · fixed in 47490bbb05c8c0e09cc3cfd237d8934ffc340583; From daa6707b71a2da23a82979fa21f788aeb706f1a2 · fixed in 0199c9d57861f17b556b6cba1f765c7cce79745b; From ff37dd18ce7739a26aab0cc2d31006a45e6bde63 · fixed in d766a49d9b55705c4737cd8bb5d3faa2d31330fd; From da06bb0ca45b1ca6f1ab55023e34e61a520337f3 · fixed in 8ca7284da0e67b3e71d90ec17f08286774245ad9; From 9b671f6f432be07c0ddd66e437d6d0e0db684f83 · fixed in fe93e907b1af03cc229a80aa64a570a103d2b279; From 8ce720d5bd91e9dc16db3604aa4b1bf76770a9a1 · fixed in 48125cd9c55cbe297b59fd1f9bda48b0960bd181; From 8ce720d5bd91e9dc16db3604aa4b1bf76770a9a1 · fixed in c2ff4764e03e7a8d758352f4aceb8fe1be6ac971; From 5.10.253 · fixed in 5.10.259; From 5.15.203 · fixed in 5.15.210; From 6.1.167 · fixed in 6.1.176; From 6.6.127 · fixed in 6.6.143; From 6.12.74 · fixed in 6.12.93; From 6.18.13 · fixed in 6.18.35
- Linux Linux
6.19
- KernelLinux
fixed in 5.10.259; From 5.11.0 · fixed in 5.15.210; From 5.16.0 · fixed in 6.1.176; From 6.2.0 · fixed in 6.6.143; From 6.7.0 · fixed in 6.12.93; From 6.13.0 · fixed in 6.18.35; From 6.19.0 · fixed in 7.0.12
References 8
git.kernel.org
- stable/c/dced308d7d6a0de1c09d2058f38f1aaaf5cbb914
- stable/c/47490bbb05c8c0e09cc3cfd237d8934ffc340583
- stable/c/0199c9d57861f17b556b6cba1f765c7cce79745b
- stable/c/d766a49d9b55705c4737cd8bb5d3faa2d31330fd
- stable/c/8ca7284da0e67b3e71d90ec17f08286774245ad9
- stable/c/fe93e907b1af03cc229a80aa64a570a103d2b279
- stable/c/48125cd9c55cbe297b59fd1f9bda48b0960bd181
- stable/c/c2ff4764e03e7a8d758352f4aceb8fe1be6ac971