CVE-2026-68445

CVE-2026-68445 is a permission bypass in the vc4 GPU driver's shader object handling. When vc4 validates a shader BO, it correctly rejects writable mmap() requests initially, but it fails to clear the VM_MAYWRITE flag on the resulting vma. This allows an attacker who already holds a validated shader object to call mprotect() and retroactively grant writability to the mapping — the security check is rendered ineffective after the fact. The fix is a single line: clear VM_MAYWRITE when establishing the read-only mapping. What makes this worth your attention is not the individual bug but what it reveals about the kernel's DRM subsystem. The same vulnerability class was already fixed in i915 years ago — the pattern of clearing VM_MAYWRITE for read-only GPU objects was implemented and merged. It simply never propagated to vc4. This is not an isolated mistake; it's evidence of a structural failure to transfer known security patterns across driver subsystems. When a permission model fix ships in one DRM driver, there's no mechanism — no tagging, no cross-reference, no audit trigger — that prompts review of similar code in other drivers. The knowledge exists in the kernel's commit history, but it's encoded as an instance-specific fix rather than a pattern declaration. The EPSS score of 0.00126 reflects low short-term exploitability, which is accurate given the prerequisites (GPU access, object in validated state). But the vulnerability class is persistent: any future DRM driver that implements read-only object mappings with the same gap will face the same issue. The vc4 driver shipped with this sharp edge for approximately eight years before discovery. That window was invisible not because no one was looking, but because the kernel lacks tooling to ask 'what other drivers implement this pattern' after a security fix lands. For defenders, the immediate action is straightforward: verify that any DRM driver handling read-only GPU objects clears VM_MAYWRITE after the security decision and before the mapping is established. Beyond that, recognize that this vulnerability class — the illusion of immutability broken by mprotect() — has recurred across the kernel's history (MAP_DENYWRITE, various mmap denylisting failures, i915, now vc4). Treat this CVE as evidence that the DRM subsystem likely contains similar undiscovered gaps in other drivers. Prioritize auditing other GPU drivers for the same pattern: read-only object mappings where VM_MAYWRITE is not explicitly cleared. The absence of automated checks for this permission model invariant means these gaps will continue to surface reactively rather than being caught at review.

Reviewed through automated stages and approved by a human before publication.