CVE-2026-43104

What it actually does

This is a local denial-of-service flaw in the Linux kernel vc4 DRM graphics driver. In an error path inside vc4_save_hang_state(), memory allocated for kernel_state is not freed before returning. A local user who can exercise the VC4 graphics/DRM interface and repeatedly trigger the affected hang-state path may cause incremental kernel memory leakage. Over time, this can exhaust memory or destabilize the system, resulting in degraded performance, process failures, or a system crash. The flaw does not provide direct confidentiality or integrity impact and is not remotely exploitable under the published CVSS vector.

Why it matters to the business

Systems using the affected Linux kernel with the vc4 graphics driver may become unstable or unavailable if a local user or compromised process repeatedly triggers the leak. The primary operational risk is service disruption on devices that depend on VC4 graphics hardware, such as embedded or single-board Linux systems. Public exploitation indicators are currently low: EPSS is very low and flat over 30 days, there is no known CISA KEV listing, no ransomware association, and no reported mature public exploit in the provided data. Remediation should still be planned because kernel availability flaws can be amplified by any attacker who already has local execution.

How an attack unfolds

An attacker first obtains local code execution on a system running an affected Linux kernel with the vc4 DRM driver in use or accessible. The attacker then interacts with the DRM/graphics subsystem in a way that causes VC4 GPU hang-state handling to enter the vulnerable early-return path in vc4_save_hang_state(). Because the function returns without freeing previously allocated kernel memory, each successful trigger leaves memory allocated. By repeating this operation, the attacker gradually consumes kernel memory. Once memory pressure becomes severe, the system may slow down, kill processes, fail allocations, or crash, creating a denial of service. Exploitation requires local privileges but does not require user interaction.

How to fix it

Upgrade to a Linux kernel version that includes the upstream vc4 DRM fix adding the missing kfree() handling in the vc4_save_hang_state() error path. Because no exact fixed package versions were provided, use the fixed kernel builds supplied by the operating system, device vendor, or distribution security advisory for CVE-2026-43104. Where immediate patching is not possible, reduce exposure by disabling or unloading the vc4 driver if it is not required, restricting local shell access, limiting access to DRM device nodes such as /dev/dri/* to trusted users only, and applying least-privilege controls to workloads that can access GPU/render devices. Reboot after kernel updates so the fixed kernel is actually running.

How to confirm the fix worked

Confirm the running kernel has been updated, not just installed, by checking the active kernel version after reboot and comparing it with the vendor advisory or patched build that includes the vc4 DRM memory-leak fix. Verify whether the vc4 driver is loaded using standard module and kernel inspection tools, and confirm whether /dev/dri/* nodes are present and accessible to untrusted users. For source-based validation, confirm the vc4_save_hang_state() error paths free kernel_state before returning. For exposure validation, systems without VC4 hardware, without the vc4 module loaded, or without untrusted local access to DRM device nodes are substantially less exposed, though package remediation is still recommended where applicable.

Typical attack path

1. Gain local access to a Linux system running an affected kernel with the vc4 DRM driver present or active.
2. Confirm the VC4 DRM device or render node is accessible to the attacker-controlled user or process.
3. Trigger VC4 graphics operations that induce GPU hang-state collection and reach the vulnerable early-return path in vc4_save_hang_state().
4. Repeat the trigger to leak kernel memory over time.
5. Cause memory pressure, degraded performance, process termination, or system crash, resulting in denial of service.

How to detect it

Look for evidence of repeated VC4 graphics faults followed by increasing kernel memory pressure or out-of-memory behavior. Relevant sources include kernel logs, system journal entries, dmesg output, audit logs for access to /dev/dri/card* and /dev/dri/renderD*, endpoint process telemetry showing repeated graphics/DRM activity by unusual users, and monitoring data for unexplained slab/kernel memory growth. Investigate clusters of GPU hang messages, vc4 driver errors, memory allocation failures, OOM killer activity, soft lockups, or crashes on systems where local users or untrusted workloads can access DRM devices. Since the vulnerability is a memory leak rather than code execution, there may be no unique exploit artifact; detection should focus on suspicious repetition of VC4 hang-state activity and resource exhaustion patterns.

• vc4_save_hang_state
• drm/vc4
• vc4
• /dev/dri/card0
• /dev/dri/renderD128
• Out of memory
• oom-killer
• Memory allocation failure
• kernel_state
• GPU hang

What your security team should do

• Inventory Linux systems that use the vc4 DRM driver, especially embedded, appliance, kiosk, Raspberry Pi-class, or other Broadcom VC4-based deployments.
• Prioritize kernel updates for systems where untrusted users, containers, applications, or services can access local DRM/render devices.
• Apply the vendor-provided fixed kernel package and reboot to activate the patched kernel.
• If patching is delayed, restrict permissions on /dev/dri/*, remove unnecessary users from graphics/render groups, and disable or blacklist the vc4 driver where graphics acceleration is not required.
• Monitor affected systems for unexplained kernel memory growth, repeated GPU hang messages, out-of-memory events, and system instability.
• Because EPSS is low, flat, not KEV-listed, and no mature exploit is reported, handle this as a normal-priority local DoS issue unless the affected systems are multi-user, exposed to untrusted workloads, or operationally critical.