CVE-2026-63875

HIGHCVSS 7.8/10EPSS 0.16%

Last modified

CVE-2026-63875 is a high-severity vulnerability rated 7.8/10 on the CVSS scale. 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 |. EPSS estimates a 0.16% chance of exploitation in the next 30 days.

Description

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 |

Metrics

CVSS 3.1
7.8/10

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS Probability
0.16%

6.0th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= 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
LinuxLinux6.19

References

Timeline

Published
Last Modified
Status
Awaiting Analysis

Frequently Asked Questions

What is CVE-2026-63875?
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 |
How severe is CVE-2026-63875?
CVE-2026-63875 has a CVSS score of 7.8/10 (HIGH severity). The EPSS model estimates a 0.16% probability of exploitation in the next 30 days.
How do I fix CVE-2026-63875?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

Are you affected by CVE-2026-63875?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST