CVE-2026-63875

What it actually does

This is an arm64 Linux kernel memory-management flaw in TLB invalidation during PMD table unsharing. When huge_pmd_unshare() unshares a PMD table, the kernel records that page-table structures were unshared, but the arm64 TLB flush path did not treat that condition like a page-table-structure invalidation. As a result, the CPU walk cache could retain stale non-leaf PMD page-table information and later perform incorrect page-table walks. In practical terms, a local authenticated user or process may be able to trigger inconsistent virtual-to-physical memory mappings, potentially causing memory corruption, privilege escalation, information disclosure, or kernel crashes on affected arm64 systems.

Why it matters to the business

Successful exploitation could allow a local user, compromised application, container workload, or sandboxed process to gain elevated privileges or disrupt an affected arm64 Linux host. The main operational risks are host compromise, data exposure across privilege boundaries, instability, and denial of service. The issue is not listed in CISA KEV, has no reported mature public exploit in the provided data, and has a low EPSS score, so broad automated exploitation is not currently indicated; however, kernel privilege-escalation flaws should still be prioritized on shared, multi-user, containerized, or internet-facing application platforms where local code execution is plausible.

How an attack unfolds

An attacker first needs local code execution with low privileges on an affected arm64 Linux system. They then run code that exercises memory-management paths involving huge PMD sharing and unsharing, causing huge_pmd_unshare() to unshare a PMD table. Because the vulnerable arm64 TLB flush path fails to invalidate the walk cache for unshared page-table structures, stale PMD metadata may remain usable by the processor. The attacker attempts to shape memory layout and timing so subsequent page-table walks use stale information, producing incorrect mappings or memory corruption. If exploitation is reliable, this condition may be leveraged to read or modify memory outside the attacker's intended privilege boundary, escalate to kernel/root privileges, or crash the system.

How to fix it

Upgrade the Linux kernel to a version that includes the arm64 fix to flush the walk cache when unsharing PMD tables. Because no affected product list or exact fixed package versions were provided, use the fixed kernel builds supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform maintainer. Prioritize arm64 systems and any workloads using huge pages, shared memory, containers, virtualization, or untrusted local code execution. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, hardening container isolation, disabling or limiting features that allow untrusted users to create large/huge memory mappings where operationally feasible, applying least-privilege controls, and increasing monitoring for kernel crashes or suspicious local privilege-escalation behavior. A reboot is typically required for kernel updates to take effect unless a validated live-patching mechanism is used.

How to confirm the fix worked

Confirm the running kernel includes the vendor patch for the arm64 TLB walk-cache invalidation change related to PMD table unsharing. Validate both installed and running kernel versions, because installing a kernel package is insufficient until the system boots into the fixed kernel or applies an approved live patch. On Linux systems, compare `uname -a` and distribution package metadata against the vendor advisory for this issue. For source-based kernels, verify that the arm64 TLB flush logic considers unshared page-table structures when deciding to use a full invalidation that clears the walk cache. After remediation, reboot or confirm live-patch activation, then re-run vulnerability scanning or configuration management checks. Also monitor for absence of recurring kernel oops, panic, page-table corruption, or unexplained crashes under memory-management stress tests.

Typical attack path

1. Gain local execution on an affected arm64 Linux host as an unprivileged user, compromised service account, container process, or sandboxed workload.
2. Run code that repeatedly triggers huge-page PMD sharing and unsharing behavior in the kernel memory-management subsystem.
3. Induce the vulnerable TLB flush path so stale PMD page-table information remains in the CPU walk cache.
4. Manipulate memory allocation, mapping, and timing to cause incorrect page-table walks using stale walk-cache entries.
5. Use the resulting memory corruption or mapping confusion to attempt privilege escalation, sensitive memory disclosure, or denial of service.
6. If privilege escalation succeeds, establish persistence or access protected data and workloads on the host.

How to detect it

There are no specific public exploit indicators in the provided data. Detection should focus on evidence of attempted or successful local privilege escalation and kernel memory-management instability. Review kernel logs from journald, syslog, dmesg, crash dumps, and centralized EDR telemetry for kernel oops, panic, page-table, TLB, translation fault, or memory-corruption messages occurring before suspicious privilege changes. Correlate these events with local user activity, container workloads, newly executed binaries from temporary directories, unexpected root shells, creation or modification of setuid-root files, changes to sudoers or PAM configuration, unexpected kernel module loads, and anomalous process lineage where a low-privileged process spawns privileged shells or administrative tools. In containerized environments, review runtime and audit logs for workloads performing unusual memory-mapping activity, privilege probing, namespace escapes, or attempts to access host resources. Because exploitation would be local and kernel-level, absence of network indicators does not rule out compromise; prioritize host telemetry, auditd/EDR events, kernel crash artifacts, and timeline analysis around crashes or privilege transitions.

What your security team should do

• Inventory arm64 Linux systems and prioritize those running multi-user workloads, containers, CI/CD runners, hosting platforms, edge devices, or services where attackers may obtain local code execution.
• Track vendor advisories and upgrade to the first fixed kernel package or later for each distribution, appliance, and cloud image in use.
• Confirm systems are actually running the fixed kernel after patching by checking the active kernel version, not only installed packages.
• Apply compensating controls on systems that cannot be patched immediately: restrict local access, reduce untrusted workload placement, enforce container hardening, and limit privilege escalation paths such as unnecessary sudo rights or powerful Linux capabilities.
• Increase monitoring for kernel instability and local privilege-escalation activity on affected arm64 hosts, especially abnormal crashes, new root-owned files, unexpected setuid binaries, suspicious kernel-module activity, or unexplained privilege changes.
• For high-risk shared compute environments, consider workload migration or temporary isolation of untrusted tenants until fixed kernels are deployed.
• Because no KEV listing, ransomware association, or mature exploit is indicated in the provided data, treat this as important but prioritize based on arm64 exposure and local-code-execution likelihood rather than emergency internet-scale exploitation.