CVE-2025-38515: drm/sched: Increment job count before swapping tail spsc queue
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Increment job count before swapping tail spsc queue
A small race exists between spsc_queue_push and the run-job worker, in
which spsc_queue_push may return not-first while the run-job worker has
already idled due to the job count being zero. If this race occurs, job
scheduling stops, leading to hangs while waiting on the job’s DMA
fences.
Seal this race by incrementing the job count before appending to the
SPSC queue.
This race was observed on a drm-tip 6.16-rc1 build with the Xe driver in
an SVM test case.
Security readout for executives and security teams
Plain-English summary
CVE-2025-38515 is a Linux kernel DRM scheduler race condition. Under specific GPU scheduling timing, jobs can stop being scheduled and systems or workloads may hang while waiting for DMA fences. The public record describes an availability problem, not data theft, remote code execution, or privilege escalation.
Executive priority
Treat this as a targeted availability risk for Linux GPU workloads, not an emergency internet-wide compromise. Patch through normal kernel maintenance, faster for systems where GPU hangs affect production, research, AI, graphics, or shared compute services.
Technical view
The race is between spsc_queue_push and the run-job worker. A push can report not-first after the worker has gone idle because job count is zero. The fix increments the job count before appending to the SPSC queue. It was observed on drm-tip 6.16-rc1 with the Xe driver in an SVM test case.
Likely exposure
Exposure appears limited to Linux systems using affected kernel versions and DRM scheduler paths, especially GPU workloads involving the Xe driver or similar DRM scheduling behavior. The source bundle does not prove broad real-world exposure across all Linux deployments.
Exploitation context
CISA KEV is false, and the provided sources do not report active exploitation. The described impact is hangs from a scheduler race, likely requiring the affected kernel code path and timing conditions rather than a straightforward remote attack.
Researcher notes
The evidence identifies a concurrency bug and stable-kernel fixes, but lacks CVSS, CWE, exploitability analysis, and detailed affected range clarity. Avoid assuming privilege escalation or remote reachability. Reproduce and validate only in controlled kernel test environments using vendor-safe procedures.
Mitigation direction
Apply vendor kernel updates containing the referenced stable fixes.
Check Linux distribution advisories, including Debian LTS notices, for packaged kernel updates.
Prioritize systems running affected kernels with GPU, DRM, or Xe driver workloads.
If patches are unavailable, monitor vendor guidance for supported mitigations or backports.
Validation and detection
Inventory Linux kernel versions on systems using DRM or GPU workloads.
Confirm whether vendor kernels include one of the referenced stable commits.
Review logs and workload reports for GPU hangs or DMA fence waits.
Track Debian LTS or distribution advisories for deployed package status.
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-38515 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.
0CVSS vectors
3Timeline events
1ADP providers
11Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Aug 16, 2025, 10:55 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.