Cloudanix VulnDB

CVE-2026-93192

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A programming mistake in the graphics driver for certain Broadcom GPUs can let a local user crash the whole system or gain higher privileges if the error-handling path is triggered.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Failure to clear queue->active_job on v3d_fence_create() error in BIN/RENDER/TFU/CSD run_job() paths leaves a dangling pointer that can be dereferenced after the job is freed, enabling a use-after-free in the v3d DRM driver.

Why it matters to the business

Systems using Broadcom V3D GPUs face elevated risk of kernel memory corruption that can lead to crashes, data loss, or local privilege escalation; the low EPSS and absence from KEV indicate limited in-the-wild exploitation so far, but unpatched kernels remain exposed for 37 days since disclosure.

How an attack unfolds

An attacker with local access crafts a sequence of v3d job submissions that cause v3d_fence_create() to fail after the job pointer has already been stored in queue->active_job; the subsequent use of the stale pointer triggers the use-after-free.

How to fix it

Apply the upstream fix that adds an explicit failure path clearing queue->active_job (with the queue_lock held for the BIN path) before returning NULL from each run_job() callback; rebuild and deploy the patched kernel on all affected V3D systems.

How to confirm the fix worked

Confirm the source contains the new failure-path clearing of active_job in v3d_drv.c; verify running kernel version incorporates the change and test that v3d job submission continues to function after forced fence-creation errors.

Typical attack path

  1. Obtain local user privileges on a system with v3d DRM loaded
  2. Submit jobs via the DRM ioctl paths for BIN, RENDER, TFU or CSD queues
  3. Force v3d_fence_create() to fail while active_job still references the job object
  4. Trigger reuse of the freed job structure through concurrent operations or timing
  5. Achieve memory corruption or control-flow hijack within the kernel

How to detect it

Inspect kernel logs for oops/panic messages referencing v3d run_job, v3d_fence_create failures, or use-after-free in drm/v3d; correlate with process activity using the render node and any preceding fence-creation error returns.

What your security team should do

  • Patch all Linux kernels exposing v3d within the next sprint given the 7.8 CVSS and local-attack surface
  • Restrict unprivileged access to the DRM render node until patches are deployed
  • Monitor kernel oops and use-after-free reports involving v3d_fence_create or queue->active_job
  • Reassess after 30-day EPSS trend remains flat at ~0.0018

The record

In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Clear queue->active_job when v3d_fence_create() fails The run_job() callbacks for BIN, RENDER, TFU and CSD assign the incoming job to queue->active_job before calling v3d_fence_create(). If v3d_fence_create() fails, the callback returns NULL without clearing active_job, leaving a dangling pointer. Create a failure path in all run_job() callbacks that clears the active job before returning NULL. The BIN path takes queue->queue_lock around the clear as it races against v3d_overflow_mem_work(); RENDER, TFU and CSD paths have no concurrent reader, so the clear is lock-free.

Affected packages

Ecosystem Package Introduced Fixed