CVE-2026-98309 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: Use managed KMS polling to fix UAF on unbind
vc4_kms_load() calls drm_kms_helper_poll_init() but the driver provides no matching drm_kms_helper_poll_fini(). The output poll work stays scheduled after unbind and runs on the freed drm_device:
# modprobe vc4; rmmod vc4; sleep 10 BUG: KASAN: slab-use-after-free in delayed_work_timer_fn BUG: KASAN: slab-use-after-free in drm_client_dev_hotplug [drm]
Workqueue: events output_poll_execute [drm_kms_helper]
Allocated by task 171: __devm_drm_dev_alloc Freed by task 262 (rmmod): drm_dev_put / component_del
Use drmm_kms_helper_poll_init() so polling is finalized with the device, as other drivers do.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in the Linux kernel's DRM VC4 driver represents a critical use-after-free condition arising from improper resource lifecycle management during device unbinding operations. The core technical flaw lies in an asymmetry between initialization and cleanup routines within the vc4_kms_load function, which invokes drm_kms_helper_poll_init to establish output polling mechanisms but fails to provide a corresponding finalization routine such as drm_kms_helper_poll_fini when the driver is unloaded or the device is unbound. This oversight results in the kernel's delayed work queue continuing to schedule and execute poll-related tasks even after the underlying drm_device structure has been deallocated, leading directly to memory corruption and potential system instability.
From a technical perspective, this issue manifests as a slab-use-after-free error detected by Kernel Address Sanitizer (KASAN), specifically occurring within the delayed_work_timer_fn function which is part of the output_poll_execute workqueue execution path. When the vc4 driver module is removed via rmmod, the associated drm_device memory is freed through standard device management routines like devm_drm_dev_alloc and component_del. However, because the polling infrastructure was not tied to this managed lifecycle, it retains stale pointers to the now-freed memory regions. Subsequent timer expirations trigger execution contexts that attempt to access these invalid addresses, resulting in crashes or undefined behavior as indicated by the KASAN reports referencing drm_client_dev_hotplug and output_poll_execute.
The operational impact of this vulnerability is significant for system stability and security integrity. A successful exploitation could allow a local attacker with sufficient privileges to crash the kernel, leading to denial-of-service conditions that disrupt all running services on the affected host. Furthermore, use-after-free vulnerabilities are historically associated with higher severity risks because they can potentially be leveraged to achieve arbitrary code execution if an attacker can carefully control the memory reallocation patterns following the free operation. Although this specific instance primarily demonstrates a crash scenario through KASAN detection, the underlying memory safety violation remains a serious security defect that compromises the reliability of the graphics subsystem and the broader operating system environment.
To mitigate this vulnerability, developers must ensure strict adherence to managed resource allocation principles within kernel drivers. The recommended remediation involves replacing the standard drm_kms_helper_poll_init call with drmm_kms_helper_poll_init in the vc4 driver initialization path. This function integrates the polling cleanup into the device's managed resource framework, ensuring that when the device is unbound and its memory is released, the associated poll work items are automatically cancelled and finalized by the kernel's devm subsystem. This approach aligns with established best practices observed in other DRM drivers where lifecycle management is tightly coupled to prevent dangling references.
This vulnerability maps directly to CWE-416, Use After Free, which describes situations where a program uses memory after it has been freed, leading to unpredictable behavior and potential security breaches. In terms of the MITRE ATT&CK framework for enterprise detection and mitigation, this type of flaw falls under techniques related to privilege escalation or denial-of-service via exploitation of software vulnerabilities, specifically highlighting the importance of robust resource management in kernel-space code. Addressing such issues requires rigorous static analysis tools like KASAN during development cycles and comprehensive testing of driver unload paths to verify that all asynchronous tasks are properly terminated before memory deallocation occurs.