CVE-2026-98309

What it actually does

Use-after-free in the Linux kernel DRM subsystem: vc4_kms_load calls drm_kms_helper_poll_init without a matching fini, leaving the output_poll_execute work scheduled after module unbind so it executes on the already-freed drm_device.

Why it matters to the business

Systems using the vc4 DRM driver can experience kernel crashes or potential code execution when the module is unloaded, leading to denial of service or full host compromise on affected embedded or graphics hardware.

How an attack unfolds

An attacker with local access loads the vc4 module, triggers unbind or rmmod, and relies on the still-queued delayed work to dereference the freed drm_device structure, producing a slab-use-after-free that can be turned into arbitrary kernel memory access.

How to fix it

Update the Linux kernel to a version containing the commit that replaces drm_kms_helper_poll_init with drmm_kms_helper_poll_init in vc4; rebuild and reboot with the patched kernel. No configuration workaround exists.

How to confirm the fix worked

Verify the running kernel contains the managed-poll change in drm/vc4; confirm absence of the KASAN slab-use-after-free stack trace when performing modprobe/rmmod cycles on vc4.

Typical attack path

1. Obtain local code execution on a Linux system that loads the vc4 DRM driver
2. Load the vc4 module (modprobe vc4)
3. Unload the module (rmmod vc4) to trigger unbind without canceling the poll work
4. Wait for the events workqueue to run output_poll_execute on the freed object
5. Leverage the resulting UAF for privilege escalation or kernel code execution

How to detect it

Search kernel logs and KASAN reports for "slab-use-after-free in delayed_work_timer_fn" or "drm_client_dev_hotplug" originating from the drm_kms_helper workqueue after vc4 module removal.

• BUG: KASAN: slab-use-after-free in delayed_work_timer_fn
• Workqueue: events output_poll_execute [drm_kms_helper]
• BUG: KASAN: slab-use-after-free in drm_client_dev_hotplug [drm]

What your security team should do

• Apply the upstream fix immediately on all systems that may load vc4
• Audit kernel logs for prior KASAN or drm hotplug crashes on vc4 devices
• Restrict local module loading privileges until systems are patched
• Monitor EPSS and exploit maturity; re-evaluate if public PoCs appear