Linux Kernel vc4 EUVD-2026-57020

Exploitation requires a local user account (PR:L) on a system equipped with a Broadcom VideoCore IV GPU - specifically Raspberry Pi models 1, 2, 3, and devices using BCM2835, BCM2836, BCM2837, or BCM2711 SoCs. The attacker must have open access to the DRM device node (/dev/dri/card* or /dev/dri/renderD*), which on default Raspberry Pi OS configurations is accessible to members of the 'video' or 'render' groups. No network access, no special kernel configuration, and no user interaction are required. Systems without VC4 hardware - including all x86, ARM server, and non-Raspberry Pi Linux deployments - are entirely unaffected regardless of kernel version. Limiting factors: AV:L (local access only), PR:L (standard user with GPU group membership), hardware-specific (VC4 GPU must be present and accessible), and no remote exploitation path exists.

The CVSS 7.8 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) accurately characterizes this vulnerability: local, low-complexity, low-privilege access yields full CIA impact. The EPSS of 17% is meaningfully elevated for a kernel driver flaw targeting niche embedded hardware - it suggests a non-trivial community awareness of exploitability, though no KEV listing or public POC has been identified at time of analysis. Real-world risk is sharply bounded by hardware specificity: only systems with VC4 GPUs (Raspberry Pi and BCM283x-based devices) are affected; the vast majority of Linux deployments on x86 servers and cloud infrastructure are entirely unaffected. For operators of VC4-based systems - including IoT deployments, kiosk systems, and educational Raspberry Pi environments - where local, untrusted users have access to the GPU device node, this is a genuine priority given the low attack complexity and high impact. The CVSS and EPSS signals are consistent and not conflicting; the primary limiting factor on population risk is the hardware-specific deployment scope.

A local user on a Raspberry Pi running an unpatched kernel opens the DRM device node (/dev/dri/card0), submits a shader buffer object through the vc4 GEM interface, and triggers the validator to approve it. The attacker then mmap()s the validated BO with PROT_READ to obtain a read-only mapping, and immediately calls mprotect() on that mapping to upgrade it to PROT_READ|PROT_WRITE - this succeeds because VM_MAYWRITE was never cleared. The attacker overwrites the approved shader bytecode in-place with malicious GPU instructions, which the GPU then executes without re-validation, potentially enabling privilege escalation or security sandbox bypass on the affected device. No public POC has been identified, but the technique requires only standard Linux VM and DRM system calls.