Answer in brief
CVE-2026-63875 records a Unknown severity vulnerability in arm64: tlb: Flush walk cache when unsharing PMD tables. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-63875 records a Unknown severity vulnerability in arm64: tlb: Flush walk cache when unsharing PMD tables. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=6495204f8219a57859669d618b25d06176d5a872 <dced308d7d6a0de1c09d2058f38f1aaaf5cbb914 || >=ce4cf24761467756462c0e1dbe4a5e9c9eb520fc <47490bbb05c8c0e09cc3cfd237d8934ffc340583 || >=daa6707b71a2da23a82979fa21f788aeb706f1a2 <0199c9d57861f17b556b6cba1f765c7cce79745b || >=ff37dd18ce7739a26aab0cc2d31006a45e6bde63 <d766a49d9b55705c4737cd8bb5d3faa2d31330fd || >=da06bb0ca45b1ca6f1ab55023e34e61a520337f3 <8ca7284da0e67b3e71d90ec17f08286774245ad9 || >=9b671f6f432be07c0ddd66e437d6d0e0db684f83 <fe93e907b1af03cc229a80aa64a570a103d2b279 || >=8ce720d5bd91e9dc16db3604aa4b1bf76770a9a1 <48125cd9c55cbe297b59fd1f9bda48b0960bd181 || >=8ce720d5bd91e9dc16db3604aa4b1bf76770a9a1 <c2ff4764e03e7a8d758352f4aceb8fe1be6ac971 || >=5.10.253 <5.10.259 || >=5.15.203 <5.15.210 || >=6.1.167 <6.1.176 || >=6.6.127 <6.6.143 || >=6.12.74 <6.12.93 || >=6.18.13 <6.18.35 | dced308d7d6a0de1c09d2058f38f1aaaf5cbb914, 47490bbb05c8c0e09cc3cfd237d8934ffc340583, 0199c9d57861f17b556b6cba1f765c7cce79745b, d766a49d9b55705c4737cd8bb5d3faa2d31330fd, 8ca7284da0e67b3e71d90ec17f08286774245ad9, fe93e907b1af03cc229a80aa64a570a103d2b279, 48125cd9c55cbe297b59fd1f9bda48b0960bd181, c2ff4764e03e7a8d758352f4aceb8fe1be6ac971, 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 6.18.35 |
| Linux/Linuxgeneric | 6.19 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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 |
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=6495204f8219a57859669d618b25d06176d5a872 <dced308d7d6a0de1c09d2058f38f1aaaf5cbb914 || >=ce4cf24761467756462c0e1dbe4a5e9c9eb520fc <47490bbb05c8c0e09cc3cfd237d8934ffc340583 || >=daa6707b71a2da23a82979fa21f788aeb706f1a2 <0199c9d57861f17b556b6cba1f765c7cce79745b || >=ff37dd18ce7739a26aab0cc2d31006a45e6bde63 <d766a49d9b55705c4737cd8bb5d3faa2d31330fd || >=da06bb0ca45b1ca6f1ab55023e34e61a520337f3 <8ca7284da0e67b3e71d90ec17f08286774245ad9 || >=9b671f6f432be07c0ddd66e437d6d0e0db684f83 <fe93e907b1af03cc229a80aa64a570a103d2b279 || >=8ce720d5bd91e9dc16db3604aa4b1bf76770a9a1 <48125cd9c55cbe297b59fd1f9bda48b0960bd181 || >=8ce720d5bd91e9dc16db3604aa4b1bf76770a9a1 <c2ff4764e03e7a8d758352f4aceb8fe1be6ac971 || >=5.10.253 <5.10.259 || >=5.15.203 <5.15.210 || >=6.1.167 <6.1.176 || >=6.6.127 <6.6.143 || >=6.12.74 <6.12.93 || >=6.18.13 <6.18.35 | dced308d7d6a0de1c09d2058f38f1aaaf5cbb914, 47490bbb05c8c0e09cc3cfd237d8934ffc340583, 0199c9d57861f17b556b6cba1f765c7cce79745b, d766a49d9b55705c4737cd8bb5d3faa2d31330fd, 8ca7284da0e67b3e71d90ec17f08286774245ad9, fe93e907b1af03cc229a80aa64a570a103d2b279, 48125cd9c55cbe297b59fd1f9bda48b0960bd181, c2ff4764e03e7a8d758352f4aceb8fe1be6ac971, 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 6.18.35 |
| Linux/Linuxgeneric | 6.19 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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 |
Quoted source text, attributed separately from HOL analysis.