CVE-2026-64099: drm/v3d: Fix use-after-free of CPU job query arrays on error path
In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Fix use-after-free of CPU job query arrays on error path
The CPU job ioctl's fail label calls kvfree() on cpujob's timestamp and performance query arrays after v3djobcleanup(), which drops the job's last reference and frees cpujob. Reading cpujob at that point is a use-after-free. Also, on the early v3djobinit() failure path, it is a NULL dereference, since v3djobdeallocate() zeroes the local pointer.
In the success path, the arrays are released from the scheduler's .freejob callback, but on the error path, they are freed manually, as the job was never pushed to the scheduler. While the success path deals with this correctly, the fail path doesn't.
On top of that, the manual kvfree() calls only free the array storage; they don't drmsyncobjput() the per-query syncobjs that v3dtimestampqueryinfofree() and v3dperformancequeryinfofree() release on the success path. So the same fail path that triggers the use-after-free also leaks one syncobj reference per query.
Unify the CPU job teardown into the CPU job's kref destructor, mirroring v3drenderjobfree(). The scheduler's .freejob slot reverts to the generic v3dschedjobfree() and the fail label drops the manual kvfree() calls, leaving a single teardown path that is reached from both the scheduler and the ioctl error path. That removes the use-after-free, the NULL dereference, and the syncobj leak by construction.
Affected Software
Remediation
Event History
Frequently Asked Questions
What access does an attacker need to exploit this issue?
The CVSS vector indicates local access and low privileges are required. No user interaction is required.
Which systems are exposed?
Systems running the Linux kernel with the affected V3D DRM CPU job ioctl path are relevant. The provided data does not identify affected kernel versions or whether the V3D driver is enabled by default.
What happens when the vulnerable error path is reached?
The error path can access a CPU job after its final reference has been dropped and it has been freed, causing a use-after-free. An earlier initialization failure can instead cause a NULL dereference, and the path can leak one syncobj reference for each query.
Is a fix available?
Yes. A patch is available; the listed stable kernel references provide the associated fixes.