Cloudanix VulnDB

CVE-2026-93047

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A graphics driver bug could let one task read information another task is still changing, leading to wrong or corrupted results until the software is updated.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in job submission allows a consuming job (RENDER or CSD) to be dispatched with bo_count==0, bypassing implicit synchronization so it can access a BO while another context is writing it.

Why it matters to the business

Graphics workloads may produce corrupted output or incorrect results; in shared environments this can affect multiple users or processes and requires kernel updates to restore safe operation.

How an attack unfolds

An attacker submits a chain of v3d jobs that includes a trailing CACHE_CLEAN job; the BO list is attached only to the last job, so the earlier consuming job runs without dependencies and races with another context's write.

How to fix it

Update to a kernel containing the referenced fix that attaches BO references to every consuming job and adds the has_implicit_dep flag; rebuild and reboot systems using the v3d driver.

How to confirm the fix worked

Confirm the kernel source contains the v3d_job_reference_bos change and the per-job has_implicit_dep flag; test with concurrent v3d submissions that previously triggered the race.

Typical attack path

  1. Create a submission that expands into multiple jobs ending in CACHE_CLEAN
  2. Trigger concurrent submissions from different contexts that share BOs
  3. Rely on the kernel dispatching the consuming job without acquiring implicit dependencies
  4. Read or render from the BO while the other context is still writing

How to detect it

Review kernel logs for v3d submission anomalies and audit graphics process interactions; no public exploitation artifacts are known.

What your security team should do

  • Prioritize kernel updates on systems exposing the v3d DRM driver
  • Monitor graphics-related workloads for unexpected corruption until patched
  • Apply the fix to all distributions shipping the affected v3d code

The record

In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Associate BOs with every job that accesses them A submission can expand into a chain of jobs (e.g. bin + render + cache clean). Implicit synchronization in v3d_submit_lock_reservations() is gated on each job's bo[], but the BO list was only ever attached to the last job of the chain. When that last job is a trailing CACHE_CLEAN job, the job that actually consumes the BOs (that is, a RENDER or CSD job) was left with bo_count == 0 and picked up no implicit dependencies. It could therefore be dispatched to the hardware and read a BO while another context was still writing it, leading to data corruption. Attach the BOs to the job that consumes them, so (1) it acquires the correct implicit dependencies during reservation locking and (2) they are kept mapped until the end of the submission. Give it references to all consuming job's BOs through v3d_job_reference_bos() instead of looking the handles up a second time; that avoids a redundant lookup and guarantees both jobs reference the exact same objects. As the CACHE_CLEAN job now carries a BO array as well, add a per-job `has_implicit_dep` flag so that only the consuming jobs take implicit dependencies. The CACHE_CLEAN job (a global flush) and the BIN job (binning waiting on another context is not a realistic scenario) are excluded.

Affected packages

Ecosystem Package Introduced Fixed