CVE-2026-63879

What it actually does

This is a local Linux kernel race condition in the AMDGPU Direct Rendering Manager driver, specifically in handling HMM memory ranges in amdgpu_hmm_range_get_pages. The vulnerable code could read a notifier sequence more than once and then continue operating on invalid or stale page state. A local user with access to the affected GPU driver interface may be able to trigger memory corruption or invalid page handling in kernel context, potentially leading to privilege escalation, information disclosure, or system crash. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems running affected Linux kernels with AMDGPU support may be exposed to local privilege escalation or denial-of-service risk. In practical terms, an attacker who already has a low-privileged account, container escape opportunity, or code execution path on a vulnerable host could potentially gain deeper control of the system or disrupt workloads. This is especially relevant for Linux workstations, GPU-enabled compute nodes, VDI platforms, rendering systems, AI/ML infrastructure, and shared multi-user environments that expose AMD GPU functionality. The vulnerability is not currently listed in CISA KEV, has no known public exploit maturity in the supplied data, and has a low EPSS score, so prioritization should be highest where untrusted local users or multi-tenant GPU workloads are present.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged user on a Linux system using the affected AMDGPU kernel driver. They then interact with GPU memory-management paths that exercise HMM range handling, attempting to win the race around notifier sequence handling so the kernel works with invalid page references. If the race is triggered reliably, the attacker may cause a kernel fault, corrupt memory, disclose sensitive kernel or process memory, or manipulate execution state to elevate privileges. Because exploitation occurs through a local kernel attack surface, the vulnerability is most useful after initial access, in shared systems where low-privileged users can access GPU devices, or as part of a larger chain that turns limited code execution into full host compromise.

How to fix it

Update to a Linux kernel version or vendor-supplied kernel package that includes the upstream fix for the AMDGPU HMM notifier sequence handling issue, associated with upstream commit c08972f555945cda57b0adb72272a37910153390 or its backports. Because no exact affected products or fixed package versions were supplied, use the relevant distribution or appliance vendor advisory to identify the corrected kernel build. After patching, reboot systems into the fixed kernel and verify the vulnerable kernel is no longer running. Where immediate patching is not possible, reduce exposure by restricting local shell access, limiting access to GPU device nodes to trusted users only, disabling or unloading the AMDGPU driver where operationally acceptable, isolating GPU workloads, and avoiding shared untrusted multi-user GPU environments until patched.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the AMDGPU HMM fix or a vendor backport of commit c08972f555945cda57b0adb72272a37910153390. Validate the running kernel version after reboot with standard host inventory or package-management tooling, and compare it against the vendor's fixed kernel release. Confirm that affected systems are actually using the amdgpu driver by checking loaded kernel modules and DRM device presence. Validate mitigation by ensuring untrusted users cannot access AMD GPU device nodes if patching is delayed. Review kernel logs after patching for continued amdgpu, HMM, page-fault, Oops, BUG, or general protection fault messages that may indicate instability or incomplete remediation.

Typical attack path

1. Gain local low-privileged code execution on a Linux system using the affected AMDGPU driver.
2. Confirm access to AMD GPU device interfaces, such as DRM render or card devices.
3. Run code that repeatedly exercises AMDGPU HMM memory-range operations and attempts to trigger the notifier sequence race.
4. Cause the kernel to operate on invalid or stale pages during amdgpu_hmm_range_get_pages handling.
5. Use the resulting memory corruption or invalid memory access condition to crash the system, disclose sensitive data, or attempt privilege escalation.
6. If privilege escalation succeeds, establish persistence, access sensitive data, or pivot to other systems.

How to detect it

Evidence of exploitation is likely to be indirect because this is a local kernel race condition and may not leave a clean application-level audit trail. Review kernel logs, system journals, crash dumps, and endpoint telemetry for amdgpu-related kernel faults, GPU memory-management errors, repeated local process crashes followed by privilege changes, unexpected creation or use of privileged shells, and suspicious access to DRM GPU device nodes. Useful log sources include journald, dmesg output, /var/log/kern.log, /var/log/messages, kernel crash dumps from kdump or apport-like collectors, auditd records for access to /dev/dri devices, EDR process lineage, and sudo/authentication logs around the time of kernel instability. Focus on repeated amdgpu_hmm_range_get_pages, HMM, invalid page, page fault, Oops, BUG, general protection fault, or GPU reset messages, especially when correlated with untrusted local user activity or unexplained privilege escalation. Absence of these artifacts does not prove non-exploitation, because a successful local kernel exploit may avoid obvious logs or may only appear as a generic crash.

• amdgpu_hmm_range_get_pages
• drm/amdgpu
• amdgpu
• hmm_range
• HMM
• BUG: kernel
• Oops:
• general protection fault
• kernel NULL pointer dereference
• unable to handle page fault
• invalid page
• GPU reset
• /dev/dri/card0
• /dev/dri/renderD128
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Prioritize patching Linux systems that expose AMD GPU functionality to untrusted or semi-trusted local users, including shared workstations, GPU compute clusters, VDI hosts, CI runners, and multi-user research or AI/ML platforms.
• Inventory systems with the amdgpu kernel module loaded and correlate them with current running kernel versions and vendor fixed releases.
• Apply the vendor-fixed kernel package and reboot; verify the host is running the fixed kernel, not merely that the package is installed.
• Until patching is complete, restrict access to /dev/dri/card* and /dev/dri/renderD* devices to trusted users and workloads only.
• Monitor kernel logs for amdgpu-related crashes, kernel Oops events, BUG messages, general protection faults, page faults, and suspicious repeated GPU memory-management failures.
• Treat any unexplained local kernel crash on shared AMDGPU systems as potentially security-relevant and preserve logs, crash dumps, and workload context for investigation.
• Because there is no supplied evidence of public exploitation, KEV listing, or ransomware use, handle this as a targeted local privilege-escalation risk rather than an internet-scale emergency, while still patching promptly in high-risk local-access environments.