CVE-2025-68793: drm/amdgpu: fix a job->pasid access race in gpu recovery
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix a job->pasid access race in gpu recovery
Avoid a possible UAF in GPU recovery due to a race between
the sched timeout callback and the tdr work queue.
The gpu recovery function calls drm_sched_stop() and
later drm_sched_start(). drm_sched_start() restarts
the tdr queue which will eventually free the job. If
the tdr queue frees the job before time out callback
completes, the job will be freed and we'll get a UAF
when accessing the pasid. Cache it early to avoid the
UAF.
Example KASAN trace:
[ 493.058141] BUG: KASAN: slab-use-after-free in amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]
[ 493.067530] Read of size 4 at addr ffff88b0ce3f794c by task kworker/u128:1/323
[ 493.074892]
[ 493.076485] CPU: 9 UID: 0 PID: 323 Comm: kworker/u128:1 Tainted: G E 6.16.0-1289896.2.zuul.bf4f11df81c1410bbe901c4373305a31 #1 PREEMPT(voluntary)
[ 493.076493] Tainted: [E]=UNSIGNED_MODULE
[ 493.076495] Hardware name: TYAN B8021G88V2HR-2T/S8021GM2NR-2T, BIOS V1.03.B10 04/01/2019
[ 493.076500] Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched]
[ 493.076512] Call Trace:
[ 493.076515] <TASK>
[ 493.076518] dump_stack_lvl+0x64/0x80
[ 493.076529] print_report+0xce/0x630
[ 493.076536] ? _raw_spin_lock_irqsave+0x86/0xd0
[ 493.076541] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 493.076545] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]
[ 493.077253] kasan_report+0xb8/0xf0
[ 493.077258] ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]
[ 493.077965] amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]
[ 493.078672] ? __pfx_amdgpu_device_gpu_recover+0x10/0x10 [amdgpu]
[ 493.079378] ? amdgpu_coredump+0x1fd/0x4c0 [amdgpu]
[ 493.080111] amdgpu_job_timedout+0x642/0x1400 [amdgpu]
[ 493.080903] ? pick_task_fair+0x24e/0x330
[ 493.080910] ? __pfx_amdgpu_job_timedout+0x10/0x10 [amdgpu]
[ 493.081702] ? _raw_spin_lock+0x75/0xc0
[ 493.081708] ? __pfx__raw_spin_lock+0x10/0x10
[ 493.081712] drm_sched_job_timedout+0x1b0/0x4b0 [gpu_sched]
[ 493.081721] ? __pfx__raw_spin_lock_irq+0x10/0x10
[ 493.081725] process_one_work+0x679/0xff0
[ 493.081732] worker_thread+0x6ce/0xfd0
[ 493.081736] ? __pfx_worker_thread+0x10/0x10
[ 493.081739] kthread+0x376/0x730
[ 493.081744] ? __pfx_kthread+0x10/0x10
[ 493.081748] ? __pfx__raw_spin_lock_irq+0x10/0x10
[ 493.081751] ? __pfx_kthread+0x10/0x10
[ 493.081755] ret_from_fork+0x247/0x330
[ 493.081761] ? __pfx_kthread+0x10/0x10
[ 493.081764] ret_from_fork_asm+0x1a/0x30
[ 493.081771] </TASK>
(cherry picked from commit 20880a3fd5dd7bca1a079534cf6596bda92e107d)
Security readout for executives and security teams
Plain-English summary
A race in the Linux AMDGPU recovery process can access a GPU job after it has been freed. This may crash the system or corrupt kernel memory. The supplied CVSS assessment also allows confidentiality and integrity impact, but the sources provide no demonstrated attack or exploitation evidence.
Executive priority
Prioritize remediation on multi-user systems and GPU compute environments using AMD hardware. Treat as high severity because kernel memory corruption can have broad impact, while recognizing that the supplied evidence does not establish real-world exploitation. Validate vendor backports promptly rather than relying only on kernel version strings.
Technical view
During GPU recovery, drm_sched_start() restarts the timeout queue, which may free a job before the timeout callback finishes reading job->pasid. This creates a slab use-after-free in amdgpu_device_gpu_recover. The fix caches the PASID before the competing operation can free the job.
Likely exposure
Exposure is limited to Linux systems using the AMDGPU driver and affected kernel revisions where GPU recovery and scheduler timeout activity can race. The supplied affected-version data identifies versions including 6.17 through 6.19 but is ambiguously encoded; confirm exact status with the kernel or distribution vendor.
Exploitation context
The supplied CVSS vector describes local, low-privilege exploitation with low complexity and no user interaction. However, the sources show only a KASAN-detected failure, provide no exploit demonstration, and state that the CVE is not in KEV. Active exploitation is therefore not established.
Researcher notes
The documented race is between the scheduler timeout callback and TDR work during stop-and-restart recovery. KASAN observed a four-byte read after free in amdgpu_device_gpu_recover. The fix caches job->pasid early. Exact vulnerable boundaries remain uncertain because the supplied version entries are irregular and should be reconciled against upstream commits.
Mitigation direction
Update to a vendor kernel incorporating the referenced upstream stable fix.
Check Linux distribution advisories for exact affected and fixed package versions.
Prioritize GPU workloads where untrusted local users can access AMDGPU functionality.
If patching is delayed, consult vendor guidance for supported exposure-reduction measures.
Validation and detection
Inventory Linux kernel versions and systems loading the AMDGPU driver.
Compare deployed kernel commits or packages with the referenced stable fixes.
Confirm distribution backport status; version numbers alone may not prove vulnerability.
Review kernel logs for AMDGPU recovery failures or use-after-free diagnostics after authorized testing.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-68793 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
3Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.