CVE-2026-68163 Overview
CVE-2026-68163 is a Linux kernel vulnerability in the memory management subsystem. The flaw exists in page_vma_mapped_walk() within mm/page_vma_mapped.c, where device-private Page Middle Directory (PMD) entries are handled incorrectly during reverse mapping (rmap) walks. When PVMW_MIGRATION is set, callers assume the returned entry is a migration entry, leading callers to misinterpret device-private entries and corrupt memory. A related race condition can occur when a PMD split completes before the PMD lock is acquired. Local attackers with the ability to trigger rmap walks against device-private mappings can leverage this flaw to corrupt kernel memory.
Critical Impact
Local privileged operations on device-private PMD mappings can trigger kernel memory corruption, threatening confidentiality, integrity, and availability of affected systems.
Affected Products
- Linux kernel versions containing commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support device-private entries")
- Linux kernel versions containing commit 146287290023 ("mm/huge_memory: implement device-private THP splitting")
- Linux distributions shipping kernels with device-private PMD support prior to the fix
Discovery Timeline
- 2026-08-10 - CVE-2026-68163 published to NVD
- 2026-08-13 - Last updated in NVD database
Technical Details for CVE-2026-68163
Vulnerability Analysis
The defect is a kernel memory corruption issue [CWE category: Improper Handling of Exceptional Conditions] in the reverse mapping walk logic. When page_vma_mapped_walk() encounters a device-private PMD entry, the original code path acquired the PMD lock and returned without further validation. Two consequences result. First, check_pmd() was never invoked, so an overlapping Page Frame Number (PFN) range was not validated. Second, when the caller set the PVMW_MIGRATION flag, the returned entry was interpreted as a migration entry even though it was a device-private entry. That misinterpretation corrupts memory the caller subsequently manipulates.
Device-private PMD splitting introduced by commit 146287290023 created an additional race window. A Transparent Huge Page (THP) style split can complete before the walker acquires pmd_lock(), leaving the walker operating on stale state.
Root Cause
The root cause is missing validation in the rmap walk path for device-private PMD entries. The walker did not call check_pmd(), did not reject PVMW_MIGRATION for device-private entries, and did not re-check for a raced PMD split after taking the lock. The fix groups device-private handling with pmd_trans_huge() and pmd_is_migration_entry() handling, invokes check_pmd(), verifies migration flag state, and rechecks for a split after locking.
Attack Vector
Exploitation requires local access with low privileges and the ability to invoke code paths that trigger rmap walks against device-private mappings, typically via GPU or accelerator memory management interfaces. No user interaction is required. Successful exploitation results in kernel memory corruption with potential privilege escalation. Refer to the kernel commit ab6209f4b48a and kernel commit f84ca9b1888d for the corrective patches.
Detection Methods for CVE-2026-68163
Indicators of Compromise
- Kernel panics or BUG: messages referencing page_vma_mapped_walk, check_pmd, or migration entry handling
- Unexpected general protection fault or NULL pointer dereference traces within the mm/ subsystem on hosts running GPU or accelerator workloads
- Kernel logs indicating THP or device-private PMD split races near rmap operations
Detection Strategies
- Inventory running kernel versions and compare against the fixed commits ab6209f4b48a and f84ca9b1888d on stable branches.
- Audit kernel modules that allocate device-private memory (for example, HMM-based GPU drivers) and correlate with kernel oops events.
- Enable kernel address sanitizer (KASAN) in test environments to surface memory corruption originating in rmap walks.
Monitoring Recommendations
- Forward dmesg and /var/log/kern.log to a central log store and alert on stack traces referencing page_vma_mapped_walk or rmap_walk.
- Track process privilege transitions on hosts running GPU workloads to identify anomalous escalation attempts following kernel warnings.
- Monitor for unexpected reboots or kernel crash-dump generation on systems that use device-private memory drivers.
How to Mitigate CVE-2026-68163
Immediate Actions Required
- Apply the upstream fixes referenced by kernel commits ab6209f4b48a and f84ca9b1888d or install a distribution kernel that includes them.
- Reboot affected systems after patch installation to ensure the corrected page_vma_mapped_walk() code path is loaded.
- Restrict local shell access on multi-tenant hosts and hosts running GPU or accelerator workloads until patching completes.
Patch Information
The fix invokes check_pmd() for device-private PMD entries, rejects PVMW_MIGRATION for device-private cases, and rechecks for a raced PMD split after acquiring pmd_lock(). Device-private handling is grouped alongside pmd_trans_huge() and pmd_is_migration_entry(). See the upstream commit ab6209f4b48a and the companion commit f84ca9b1888d for the complete patch set.
Workarounds
- Unload or disable kernel drivers that allocate device-private memory when patching cannot be performed immediately.
- Limit local user accounts on affected hosts and enforce least-privilege policies on GPU and accelerator resource access.
- Disable Transparent Huge Pages for workloads that do not require them to reduce the surface for PMD split races: echo never > /sys/kernel/mm/transparent_hugepage/enabled.
# Verify running kernel and confirm patch presence
uname -r
grep -E 'page_vma_mapped|device.private' /proc/kallsyms | head
# Disable THP as a temporary mitigation
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

