CVE-2026-99095 in Linux
Summary
by MITRE • 10/26/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: drain the hangcheck timer and works on V3D unbind
Nothing stops the hangcheck timer that submitted jobs arm, or the job_done_work that the render-done interrupt queues, at teardown: vc4_irq_disable() cancels only overflow_mem_work, and vc4_gem_destroy() runs from the drm-managed release, after vc4_v3d_unbind() has already uninstalled the V3D interrupt and cleared vc4->v3d. A timer still armed by then reads V3D registers through the NULL vc4->v3d pointer, and the late callbacks run on the vc4_dev embedding them after it has been freed.
Drain them in vc4_v3d_unbind(): shut the timer down and cancel reset_work before the interrupt is taken down, because its vc4_irq_reset() re-enables it, then flush job_done_work so that completions queued at teardown still release their jobs.
This issue was found by an in-house static analysis tool.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/26/2026
The identified vulnerability resides within the Linux kernel's DRM VC4 driver, specifically affecting the V3D graphics hardware subsystem on Broadcom BCM2711 and similar SoCs used in Raspberry Pi devices. The core technical flaw is a race condition involving resource lifecycle management during device unbinding. When the system initiates the teardown process for the V3D component via vc4_v3d_unbind, it proceeds to uninstall interrupts and clear critical driver state pointers without adequately synchronizing with asynchronous hardware events or kernel workqueues. Specifically, the hangcheck timer, which is responsible for detecting GPU hangs by monitoring job progress, remains armed even after the interrupt handler has been disabled. Furthermore, the job_done_work structure, which processes completion signals from render-done interrupts queued in software, continues to operate on stale data structures.
The operational impact of this flaw stems directly from a use-after-free scenario triggered by asynchronous execution paths that outlive their associated resources. During unbinding, vc4_irq_disable only cancels overflow_mem_work but fails to stop the hangcheck timer or cancel reset_work. Consequently, if the V3D interrupt fires just before or during the teardown sequence, it may queue job_done_work items. Simultaneously, the already-armed hangcheck timer attempts to access hardware registers through a pointer that has been set to NULL because vc4->v3d was cleared prior to these asynchronous callbacks completing. This results in kernel panics due to null pointer dereferences or memory corruption if the late-running work items attempt to free jobs associated with a device structure that has already been deallocated by drm-managed release functions running after unbind completes.
From a classification perspective, this vulnerability aligns closely with CWE-416: Use After Free and CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition). The failure to properly synchronize the cessation of asynchronous tasks with the deallocation of shared resources creates an unstable state where kernel memory is accessed after it has been returned to the system allocator. In terms of adversarial tactics, this could be leveraged in a denial-of-service attack vector within the ATT&CK framework under T1499: Endpoint Denial of Service, as triggering the race condition leads directly to system instability or crash without requiring privilege escalation beyond standard kernel execution context.
To mitigate this vulnerability, the driver implementation must enforce strict ordering during device teardown. The fix involves draining all pending asynchronous operations before releasing hardware resources. Specifically, vc4_v3d_unbind must explicitly shut down the hangcheck timer and cancel reset_work to prevent further re-arming of timers that rely on valid hardware state. Additionally, job_done_work must be flushed to ensure that any completions queued during the teardown process are processed safely, allowing them to release their associated jobs without accessing freed memory. This ensures that all asynchronous callbacks complete or are discarded before the vc4_dev structure is destroyed, thereby eliminating the race window and preventing null pointer dereferences or use-after-free errors.