CVE-2026-53213

What it actually does

This is a Linux kernel memory-management flaw in the VC4 DRM graphics driver. The vulnerable code overwrites an existing allocation pointer directly with the return value of krealloc(); if the resize fails and returns NULL, the original allocation remains allocated but is no longer referenced, creating a kernel memory leak. Repeatedly exercising the affected VC4 DRM code path can consume kernel memory over time and may lead to memory pressure, process termination by the OOM killer, graphics subsystem instability, or a system-level denial of service. The issue is not known to provide code execution or privilege escalation by itself.

Why it matters to the business

Systems using the affected Linux kernel VC4 graphics driver can become unstable or unavailable if the vulnerable code path is repeatedly triggered, affecting services that depend on those hosts. The risk is most relevant to Linux systems using Broadcom/VideoCore IV graphics, such as Raspberry Pi-class platforms or embedded devices. Public exploitation is not currently indicated, EPSS is very low, it is not in CISA KEV, and no ransomware use is reported, so urgency is lower than for actively exploited flaws; however, kernel updates should still be applied through normal maintenance because successful denial-of-service conditions can interrupt operations.

How an attack unfolds

An attacker first needs local access to a system where the vulnerable VC4 DRM driver is present and reachable, typically through access to graphics/DRM device nodes such as /dev/dri/*. The attacker then repeatedly invokes graphics operations that drive the affected allocation-resize path. Under memory pressure or when krealloc() fails, the driver loses the reference to the previously allocated buffer, leaking kernel memory. By repeating the sequence, the attacker can gradually consume memory and force the host into degraded performance, OOM-killer activity, graphics failure, or a crash/reboot. Exploitation is expected to be local and reliability depends on whether the VC4 driver is loaded, accessible, and the vulnerable path can be reached often enough to create meaningful memory exhaustion.

How to fix it

Apply a Linux kernel update that includes the upstream VC4 DRM fix replacing unsafe direct krealloc() assignment with checked temporary assignment and krealloc_array(). Because no product-specific fixed versions were provided, use the fixed kernel package supplied by the operating system or device vendor and prioritize systems where the vc4 driver is enabled or where untrusted users can access /dev/dri devices. If immediate patching is not possible, reduce exposure by restricting local access to DRM device nodes, removing untrusted users from graphics/video/render groups, disabling or blacklisting the vc4 driver where it is not required, and limiting workloads that allow untrusted code to interact with local graphics devices. Mitigations should be treated as temporary because they reduce reachability but do not correct the kernel memory leak.

How to confirm the fix worked

Confirm that the running kernel package contains the vendor backport or upstream fix for the VC4 DRM krealloc memory leak. Check the currently running kernel with uname -a and compare it to the vendor advisory or changelog for the fix. Verify whether the VC4 driver is loaded with lsmod, modinfo vc4, or by checking /sys/module/vc4. Confirm device-node exposure by reviewing permissions on /dev/dri/* and group membership for users that can access those nodes. After remediation, reboot into the fixed kernel and verify the old vulnerable kernel is no longer running. Where feasible, run graphics-driver regression testing and monitor kernel memory, dmesg, and OOM activity to ensure the leak condition no longer occurs under VC4 DRM stress operations.

Typical attack path

1. Identify a Linux host using the VC4 DRM graphics driver.
2. Obtain local execution or access to a process context that can interact with DRM graphics device nodes.
3. Open the relevant /dev/dri device and exercise VC4 DRM operations that trigger the vulnerable reallocation path.
4. Repeat the operation while increasing allocation pressure until krealloc() failures occur.
5. Cause unrecoverable kernel memory leakage through repeated failed reallocations.
6. Drive the system into memory exhaustion, OOM-killer events, graphics subsystem instability, service disruption, or reboot.

How to detect it

To assess possible prior exploitation, focus on Linux hosts where the vc4 driver is loaded and review kernel logs, persistent journal entries, and system monitoring for unexplained memory exhaustion that correlates with VC4/DRM activity. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd logs for /dev/dri access, EDR process telemetry, and resource-monitoring data showing sustained kernel memory growth. Look for repeated access to DRM render/card devices by unexpected users or processes, high-frequency graphics ioctl activity, OOM-killer events, vc4/drm driver warnings, GPU resets, and unexplained reboots. Because this vulnerability is a memory leak rather than a code-execution bug, there may be no durable payload, dropped file, network callback, or unique exploit artifact. Evidence is most likely circumstantial: local processes interacting heavily with /dev/dri combined with kernel memory pressure or OOM events on VC4-enabled systems.

• vc4
• drm/vc4
• /dev/dri/card0
• /dev/dri/renderD128
• Out of memory
• oom-killer
• Killed process
• invoked oom-killer
• Memory allocation failure
• page allocation failure
• kernel: vc4
• kernel: drm
• /sys/module/vc4
• vc4.ko
• modprobe vc4

What your security team should do

• Inventory Linux systems that load the vc4 DRM driver, especially Raspberry Pi, embedded Linux, kiosk, appliance, and edge-device deployments.
• Patch affected systems through the normal kernel update channel and reboot them into the fixed kernel.
• Prioritize patching systems that allow multiple local users, run untrusted code, expose containers with device access, or grant access to /dev/dri devices.
• Restrict /dev/dri permissions and review membership in video, render, or equivalent graphics-access groups until patching is complete.
• Disable or blacklist the vc4 module on systems where VC4 graphics functionality is not required.
• Monitor for repeated kernel memory pressure, OOM-killer events, DRM/VC4 errors, and unexpected reboots on systems where the driver is active.
• Do not treat this as an internet-facing remote-code-execution issue; focus response on local access control, device-node exposure, and timely kernel maintenance.