CVE-2026-93192

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

The dangling queue->active_job is created in v3d_bin_job_run/v3d_render_job_run/v3d_tfu_job_run/v3d_csd_job_run after DRM_IOCTL_V3D_SUBMIT_CL (v3d_submit_cl_ioctl), DRM_IOCTL_V3D_SUBMIT_TFU, or DRM_IOCTL_V3D_SUBMIT_CSD on /dev/dri/renderD* queues a job through v3d_push_job; the trigger is that local ioctl, not a remote protocol message.

AC:LAttack complexity, low

v3d_fence_create() fails only on kzalloc of struct v3d_fence; the attacker submits the job first so ioctl-time allocations succeed, then applies memory pressure so the scheduler worker hits GFP_KERNEL ENOMEM, and can also drive v3d_overflow_mem_work via a BCL that raises V3D_INT_OUTOMEM, controlling both the failure and the UAF consumer.

PR:LPrivileges required, low

v3d_submit_cl_ioctl/v3d_submit_tfu_ioctl/v3d_submit_csd_ioctl are DRM_RENDER_ALLOW|DRM_AUTH with no capable() check; drm_ioctl_permit() treats render-node clients as authenticated, so an unprivileged Raspberry Pi/video-group user (or GPU-passthrough container) with /dev/dri/renderD* can reach the run_job callbacks.

UI:NUser interaction, none

The attacker opens the render node and issues their own SUBMIT_CL/SUBMIT_TFU/SUBMIT_CSD ioctls plus memory pressure; no other user must mount media, open a file, or otherwise interact.

S:UScope, unchanged

The use-after-free is of a host-kernel v3d_job left in queue->active_job and later used by v3d_overflow_mem_work/v3d_irq_signal_fence, which is local kernel heap corruption/privilege escalation, not a KVM/Xen escape or IOMMU/DMA boundary bypass.

C:HConfidentiality impact, high

After drm_sched_job_done/v3d_sched_job_free kfree's the job, v3d_overflow_mem_work still reads bin_job->render and v3d_irq_signal_fence reads active_job->irq_fence and stats from the freed slab, so heap reuse of the v3d_job yields an arbitrary kernel read.

I:HIntegrity impact, high

v3d_overflow_mem_work does list_add_tail(&bo->unref_head, &bin_job->render->unref_list) through the freed job, so spraying a replacement v3d_bin_job with a chosen render pointer is an arbitrary list-write; v3d_job_update_stats() likewise writes into the freed object.

A:HAvailability impact, high

Dereferencing the dangling queue->active_job in v3d_irq_signal_fence (IRQ context) or v3d_overflow_mem_work after v3d_job_free() oopses or panics the kernel, matching other v3d active-job UAFs that produced fatal exceptions in v3d_irq().