CVE-2026-93047 in Linux
Summary
by MITRE • 09/17/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in the Linux kernel's DRM V3D driver stems from an incorrect association of buffer objects with execution jobs, specifically within the chain of operations submitted to the hardware scheduler. In this subsystem, a single user-space submission can expand into multiple sequential jobs, such as binning, rendering, and cache cleaning phases. The core technical flaw lies in how implicit synchronization dependencies are managed during reservation locking. While the function v3d_submit_lock_reservations is designed to gate access based on buffer object lists associated with each job, the implementation historically attached these buffer objects only to the final job in the submission chain. This architectural oversight creates a critical gap when the trailing job is designated as a cache clean operation rather than a rendering or compute shader dispatch job that actually consumes the data.
When the last job in the chain is a CACHE_CLEAN command, it does not actively read from or write to the buffer objects in the same manner as RENDER or CSD jobs. Consequently, the preceding consuming jobs are left with an empty buffer object count and fail to acquire implicit dependencies on those buffers during the reservation locking phase. This omission means that the hardware may dispatch a job that reads shared memory while another context is still actively writing to it. The lack of proper synchronization primitives results in race conditions where data corruption occurs because the GPU proceeds without waiting for prior write operations from other contexts or even earlier stages within the same submission to complete.
The operational impact of this vulnerability includes severe data integrity issues, potentially leading to visual artifacts, application crashes, or more serious security implications if sensitive memory contents are exposed due to improper isolation between contexts. This scenario aligns with CWE-362, which describes concurrent execution using shared resources with inadequate synchronization. Furthermore, the failure to enforce proper ordering of operations maps closely to ATT&CK technique T1059, specifically regarding command scripting or API abuse where an attacker might exploit race conditions in graphics processing units to manipulate state or exfiltrate data through side channels created by unsynchronized memory access patterns.
The resolution involves restructuring how buffer objects are referenced and synchronized across the job chain. The fix ensures that buffer objects are attached directly to the specific jobs that consume them, thereby guaranteeing that these consuming jobs acquire the correct implicit dependencies during reservation locking. This adjustment also ensures that buffers remain mapped for the duration of the submission, preventing premature unmapping issues. To implement this efficiently and safely, the solution utilizes v3d_job_reference_bos to provide references to all buffer objects required by consuming jobs in a single operation. This approach avoids redundant lookups through handle tables and guarantees that both the binning and rendering stages reference the exact same memory objects, eliminating ambiguity in resource tracking.
Additionally, because cache clean operations now also carry an array of buffer objects for consistency, a per-job flag named has_implicit_dep was introduced to refine dependency management. This flag ensures that only jobs with actual data consumption requirements take on implicit dependencies. Cache clean jobs, which serve as global flushes without specific context-dependent synchronization needs, and binning jobs, where waiting on another context is not a realistic scenario for this hardware architecture, are explicitly excluded from taking these dependencies. This granular control prevents unnecessary serialization overhead while maintaining strict correctness for the operations that truly require it, thereby restoring data integrity and system stability in multi-context environments.