Bug 2502318 (CVE-2026-63875)

Summary: CVE-2026-63875 kernel: arm64: tlb: Flush walk cache when unsharing PMD tables
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel, specifically within the arm64 architecture's Translation Lookaside Buffer (TLB) management. When a Page Middle Directory (PMD) table was unshared, the TLB flush operation did not correctly invalidate entries in the walk cache. This oversight could leave stale PMD page table entries, potentially leading to incorrect page table walks. Such an issue can enable an attacker to access unauthorized memory regions, potentially resulting in information disclosure or privilege escalation.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-07-19 16:01:37 UTC
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                        |

Comment 5 Jon Orris 2026-09-28 11:13:13 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2026:72467 https://access.redhat.com/errata/RHSA-2026:72467

Comment 6 Jon Orris 2026-09-28 12:03:30 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2026:72468 https://access.redhat.com/errata/RHSA-2026:72468

Comment 7 Jon Orris 2026-09-28 18:43:46 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2026:72623 https://access.redhat.com/errata/RHSA-2026:72623

Comment 10 Jon Orris 2026-11-02 23:13:03 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.4 Update Services for SAP Solutions

Via RHSA-2026:94109 https://access.redhat.com/errata/RHSA-2026:94109