CVE-2026-68445 in Linux
Summary
by MITRE • 08/12/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: Prevent shader BO mappings from becoming writable
vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect().
Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator.
Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/12/2026
The vulnerability in question affects the linux kernel's vc4 graphics driver component and represents a critical privilege escalation vector through improper memory mapping controls. This issue specifically targets the drm/vc4 subsystem where shader buffer objects are managed, creating a scenario where userspace applications can potentially bypass security mechanisms designed to protect GPU shader code integrity. The flaw stems from how the vc4_gem_object_mmap() function handles memory mappings for validated shader buffer objects, leaving certain virtual memory flags in an inconsistent state that allows for privilege escalation.
The technical implementation of this vulnerability occurs at the kernel level within the graphics driver's memory management subsystem where the vc4_gem_object_mmap() function correctly identifies and rejects writable mappings for validated shader buffer objects. However, the function fails to properly clear the VM_MAYWRITE flag when establishing read-only mappings, creating a persistent vulnerability that allows userspace to upgrade memory mappings from read-only to writable states using standard system calls like mprotect(). This inconsistency between the validation mechanism and memory protection flags creates an exploitable gap where malicious code can modify GPU shader instructions after they have been validated. The validator performs initial instruction checks and establishes trust in the GPU for subsequent execution, but this trust relationship becomes compromised when userspace can modify the underlying code.
The operational impact of this vulnerability extends beyond simple privilege escalation to encompass potential system compromise through GPU-based code injection attacks. Attackers can leverage this flaw to execute arbitrary code within the GPU context, potentially leading to complete system compromise or data exfiltration from graphics processing operations. The vulnerability affects systems running linux kernels with vc4 graphics drivers, particularly those utilizing broadcom video core iv hardware architectures where this specific driver implementation is active. This represents a significant concern for embedded systems, mobile devices, and servers that rely on gpu acceleration where userspace applications might attempt to exploit such memory mapping inconsistencies.
Security mitigations for this vulnerability involve modifying the vc4_gem_object_mmap() function to consistently clear the VM_MAYWRITE flag when establishing read-only mappings for validated shader buffer objects, aligning with existing practices implemented in the i915 graphics driver subsystem. The solution requires ensuring that once a buffer object has been validated as a shader, all memory mappings maintain read-only characteristics throughout their lifetime, preventing any subsequent modifications regardless of userspace actions. This approach directly addresses the root cause by eliminating the possibility of mapping upgrades and maintains consistency with established kernel security patterns where read-only objects are protected from write operations through proper virtual memory management flags.
This vulnerability maps to CWE-1234 which specifically addresses improper restriction of operations within a blacklisted or white-listed file or buffer, and aligns with ATT&CK technique T1068 which covers privilege escalation through exploitation of kernel vulnerabilities. The remediation approach follows industry best practices for kernel memory management security where proper flag handling prevents unintended access patterns and maintains the integrity of validated code sections. The fix ensures that once shader validation occurs, the GPU can trust that the instructions remain unchanged during execution, preventing potential attacks that rely on code modification after validation has occurred.