CVE-2026-43105

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel vc4 DRM graphics driver. When the driver saves GPU hang state, it allocates a buffer-object array with kzalloc(), but the cleanup path failed to free that array in vc4_free_hang_state(). Repeated triggering of vc4 GPU hang-state capture can leak kernel memory over time. Because the flaw is local, low-privileged access is required, and the primary impact is availability degradation or system instability due to memory exhaustion; it does not directly provide confidentiality or integrity impact.

Why it matters to the business

Systems using the affected Linux kernel vc4 graphics driver may become unstable, slow, or unavailable if a local user or compromised process can repeatedly trigger the leak. The risk is most relevant to devices using Broadcom VC4 graphics, such as certain ARM-based Linux systems and embedded platforms. The public exploitation likelihood appears low based on the low EPSS score, flat EPSS trend, no known exploited status, and no reported exploit maturity, but availability-sensitive systems should still patch during normal kernel maintenance cycles.

How an attack unfolds

An attacker first needs local code execution or access to run a process on a system using the vulnerable vc4 DRM driver. The attacker then exercises graphics/GPU functionality in a way that causes vc4 hang-state collection to occur repeatedly. Each hang-state save allocates a BO array that is not released on cleanup, causing unreclaimed kernel memory to accumulate. Over repeated iterations, available memory can be depleted, leading to degraded performance, kernel memory pressure, application failures, or a crash/reboot depending on system configuration and workload. There is no indication from the supplied data that this vulnerability is being exploited in the wild or used by ransomware campaigns.

How to fix it

Apply a Linux kernel update that includes the upstream vc4 DRM fix adding the missing kfree() for the hang-state BO array in vc4_free_hang_state(). Because no exact fixed package versions were provided, use the relevant distribution vendor advisory and upgrade to the first kernel package version that includes the fix for CVE-2026-43105. Reboot into the patched kernel after installation. Where immediate patching is not possible, reduce exposure by limiting local shell/container access to affected systems, restricting untrusted graphics workloads, disabling or blacklisting the vc4 driver only if graphics functionality is not required, and prioritizing patching for shared, multi-user, kiosk, lab, CI, desktop, and embedded devices where local untrusted code may run.

How to confirm the fix worked

Confirm the system is running a kernel build that includes the vc4 DRM memory-leak fix from the distribution or upstream stable kernel. Validate by checking the active kernel version after reboot with uname -r and comparing it against the vendor-fixed version. On source-based or custom kernels, confirm vc4_free_hang_state() frees the hang-state BO array before freeing the hang-state structure. Verify whether the vc4 module is present or loaded using lsmod, modinfo, or /sys/module checks. For exposure validation, identify systems with vc4 DRM hardware/driver usage and review kernel logs for repeated vc4 GPU hangs or memory-pressure symptoms before and after patching.

Typical attack path

1. Gain local access to a Linux system that loads and uses the vc4 DRM graphics driver.
2. Run or trigger workloads that repeatedly cause vc4 GPU hangs or hang-state capture.
3. Force the vulnerable allocation and cleanup path to execute many times.
4. Accumulate unreleased kernel memory from the BO array leak.
5. Cause memory pressure, service disruption, system instability, or denial of service.

How to detect it

To assess possible prior exploitation or triggering, review local system telemetry rather than network logs, because exploitation requires local access and targets kernel graphics-driver behavior. Relevant sources include kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, OOM-killer records, crash dumps, and endpoint telemetry showing suspicious local processes generating repeated GPU activity. Look for repeated vc4 or DRM GPU hang messages followed by increasing memory pressure, OOM-killer events, service failures, or unexpected reboots. Because this is a memory leak, evidence may be circumstantial: repeated hang-state capture activity on vc4 systems, unexplained kernel memory growth, and availability failures without a corresponding workload justification. No public threat actors, ransomware use, or known in-the-wild exploitation were provided.

• vc4
• drm/vc4
• vc4_save_hang_state
• vc4_free_hang_state
• GPU hang
• hang state
• Out of memory
• oom-killer
• Killed process
• Memory allocation failure
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /dev/dri/card0
• /dev/dri/renderD128

What your security team should do

• Inventory Linux systems that use the vc4 DRM driver, especially ARM-based, embedded, desktop, kiosk, or multi-user systems.
• Patch affected kernels through the operating system vendor and reboot into the fixed kernel during the next maintenance window, prioritizing availability-sensitive and shared systems.
• Restrict local access and untrusted workload execution on affected systems until patched.
• Monitor kernel logs for repeated vc4 GPU hang messages, out-of-memory activity, or unexplained reboots on systems using vc4 graphics.
• For custom kernels, backport the upstream fix and confirm the BO array is freed in vc4_free_hang_state().
• Do not treat this as an active internet-scale exploitation issue based on current inputs; EPSS is low, trend is flat, KEV is false, and no exploit maturity is reported.