Cloudanix VulnDB

CVE-2026-68245

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing bug in the AMD graphics driver inside the Linux kernel can let a local user crash the machine or gain higher privileges, so systems need the latest kernel update.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Race condition allowing use-after-unlock of a vm pointer returned by amdgpu_vm_get_vm_from_pasid, enabling dereference of vm->task_info after xa_unlock_irqrestore releases protection.

Why it matters to the business

Kernel instability or memory corruption on AMD GPU systems can lead to crashes, denial of service, or local privilege escalation requiring immediate patching on affected Linux distributions.

How an attack unfolds

An attacker with local access triggers concurrent operations on PASID mappings to race the unlock window, then dereferences the freed or modified vm structure to corrupt kernel state or escalate privileges.

How to fix it

Update the Linux kernel to a version containing the upstream fix that inlines amdgpu_vm_get_vm_from_pasid and holds the lock for the full duration of the vm pointer use; apply distribution backports when available.

How to confirm the fix worked

Confirm the fix by inspecting amdgpu_vm.c for removal of the standalone amdgpu_vm_get_vm_from_pasid function and presence of the inlined lock-protected path; test with concurrent PASID workload stress tools.

Typical attack path

  1. Obtain local unprivileged access on a Linux system with AMD GPU driver loaded
  2. Create multiple threads that concurrently call amdgpu_vm_get_task_info_pasid and related PASID operations
  3. Time the calls to hit the window between xa_unlock_irqrestore and the subsequent vm->task_info dereference
  4. Trigger kernel oops, memory corruption, or controlled write to escalate privileges or crash the system

How to detect it

Review kernel logs for oops or warnings referencing amdgpu_vm_get_task_info_pasid or amdgpu_vm_get_vm_from_pasid around the time of crashes; correlate with unusual PASID allocation patterns in dmesg or ftrace.

What your security team should do

  • Prioritize kernel updates on all AMD GPU hosts within the next maintenance window
  • Monitor vendor advisories for backported fixes in LTS kernels
  • Restrict unprivileged local access on high-value systems until patched
  • Add kernel oops and use-after-free monitoring to existing telemetry

The record

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm->task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities