CVE-2026-68445: Linux Kernel Privilege Escalation Flaw

CVE-2026-68445 Overview

CVE-2026-68445 is a Linux kernel vulnerability in the VideoCore IV (vc4) Direct Rendering Manager (DRM) driver. The vc4_gem_object_mmap() function rejects writable mappings of validated shader buffer objects (BOs) but fails to clear the VM_MAYWRITE flag. Userspace can map the shader BO read-only, then invoke mprotect() to promote the mapping to writable. This bypasses the shader validator, which inspects instructions only once before the GPU executes them.

Critical Impact
Local userspace can rewrite validated GPU shader instructions after validation, bypassing the vc4 shader validator and executing unvalidated code on the GPU.

Affected Products

Linux kernel drm/vc4 driver (VideoCore IV GPU driver, used on Raspberry Pi platforms)
Kernel branches prior to the fix commits referenced in stable trees
Distributions shipping the affected drm/vc4 driver code

Discovery Timeline

2026-08-12 - CVE-2026-68445 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-68445

Vulnerability Analysis

The vc4 DRM driver supports user-submitted GPU shader programs. Because the GPU cannot enforce memory protection on its own instruction stream, the kernel runs a shader validator that inspects each instruction before allowing execution. After validation, the GPU trusts the shader BO contents without further checks.

The vc4_gem_object_mmap() handler blocks direct writable mappings of validated shader BOs. However, it does not clear the VM_MAYWRITE flag on the resulting virtual memory area (VMA). The VM_MAYWRITE flag governs whether a mapping may later be upgraded to writable through mprotect(). Leaving it set permits a userspace process to map the BO read-only, pass validation, then transition the same mapping to read-write and overwrite the validated instructions in place.

Root Cause

The root cause is incomplete enforcement of read-only semantics on a VMA. Rejecting the initial writable mapping is insufficient; the kernel must also clear VM_MAYWRITE to prevent later privilege promotion via mprotect(). The i915 driver already applies this pattern for its read-only objects, and the fix aligns vc4 with that behavior.

Attack Vector

A local unprivileged user with access to the vc4 DRM device node can allocate a shader BO, submit it for validation, and obtain a read-only mmap. The attacker then calls mprotect() with PROT_WRITE to upgrade the mapping. Because VM_MAYWRITE is still set, the kernel permits the transition. The attacker rewrites the shader instructions before or during GPU execution, effectively bypassing validator constraints and running arbitrary GPU code with the trust level of a validated shader.

The vulnerability requires local access to the DRM device and does not offer a network-based exploitation path. See the kernel commit fix for the corrective patch.

Detection Methods for CVE-2026-68445

Indicators of Compromise

Unexpected mprotect() calls transitioning DRM-backed mappings from PROT_READ to PROT_READ|PROT_WRITE on processes holding /dev/dri/card* handles.
Anomalous GPU workloads or crashes on Raspberry Pi and other VideoCore IV systems following userspace GPU submissions.
Unprivileged processes performing repeated vc4 GEM ioctls followed by memory protection changes on the returned mappings.

Detection Strategies

Audit kernel version and drm/vc4 driver revision against the fixed stable commits listed in the vendor references.
Monitor mprotect() syscalls via auditd or eBPF for VMAs backed by DRM char devices.
Correlate DRM ioctl activity with subsequent memory protection changes in the same process to flag the exploitation pattern.

Monitoring Recommendations

Deploy eBPF probes on security_file_mprotect to log protection upgrades on file-backed mappings originating from /dev/dri/*.
Track kernel logs for vc4 validator warnings and unexpected GPU faults on affected platforms.
Maintain an inventory of Raspberry Pi and VideoCore IV endpoints running kernels predating the fix.

How to Mitigate CVE-2026-68445

Immediate Actions Required

Upgrade the Linux kernel to a stable release that includes the vc4 VM_MAYWRITE clearing fix referenced in the kernel.org commits.
Restrict access to /dev/dri/card* device nodes to trusted users through group permissions and udev rules.
Inventory Raspberry Pi and other VideoCore IV deployments and prioritize patching systems that permit untrusted local users.

Patch Information

The fix clears VM_MAYWRITE on the read-only mapping path in vc4_gem_object_mmap(), preventing later mprotect() upgrades. Patches are available in the stable kernel trees. See the referenced commits: 019e6ad2, 0c9e6367, 6deaa317, 9f0ee411, and fe168ef1.

Workarounds

Remove or restrict access to the vc4 DRM device where GPU acceleration is not required, particularly on multi-user systems.
Disable or unload the vc4 kernel module on systems that do not need VideoCore IV GPU functionality.
Apply mandatory access control policies (SELinux, AppArmor) to constrain which processes may open /dev/dri/card* and invoke mprotect() on returned mappings.

bash

# Restrict DRM device access to the video group only
sudo chown root:video /dev/dri/card0
sudo chmod 0660 /dev/dri/card0

# Optionally blacklist the vc4 module where not required
echo "blacklist vc4" | sudo tee /etc/modprobe.d/blacklist-vc4.conf
sudo update-initramfs -u