Skip to main content

Linux Kernel vc4 CVE-2026-68445

| EUVDEUVD-2026-57020 HIGH
2026-08-12 Linux GHSA-rw5p-xff5-86qj
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.8 HIGH

AV:L and PR:L confirmed by DRM device node access requirement; no scope change as impact is contained to the local system; C/I/A:H reflects GPU shader code execution bypass enabling arbitrary code execution in GPU context.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Aug 14, 2026 - 01:56 vuln.today
CVSS changed
Aug 13, 2026 - 23:37 NVD
7.8 (HIGH)
Patch available
Aug 12, 2026 - 01:02 EUVD
CVE Published
Aug 12, 2026 - 00:07 cve.org
UNKNOWN (no severity yet)
CVE Published
Aug 12, 2026 - 00:07 cve.org
HIGH 7.8

DescriptionCVE.org

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.

AnalysisAI

GPU shader validation bypass in the Linux kernel's drm/vc4 driver allows local low-privileged users to rewrite validated shader bytecode after it has been approved by the GPU security validator. Specifically, vc4_gem_object_mmap() rejects writable mappings of validated shader buffer objects (BOs) but neglects to clear VM_MAYWRITE, enabling a two-step attack: map the BO read-only, then invoke mprotect() to silently upgrade the mapping to PROT_WRITE, bypassing the one-time validation check the GPU trusts unconditionally. No public exploit has been identified and no CISA KEV listing exists, but an EPSS of 17% is elevated for a local-only kernel driver issue, warranting prompt patching on affected Raspberry Pi and BCM283x-based platforms.

Technical ContextAI

The drm/vc4 driver supports Broadcom VideoCore IV GPUs, used primarily in Raspberry Pi 1-3 and BCM2835/BCM2711 SoC-based embedded systems. The vc4 security model relies on a one-shot shader validator: GPU shader instructions in a buffer object (BO) are checked once before execution, after which the GPU implicitly trusts them. The vulnerability resides in vc4_gem_object_mmap(): while it correctly refuses an initial PROT_WRITE mmap() on a validated shader BO, it leaves the VMA flag VM_MAYWRITE set. The Linux kernel's mprotect() syscall uses VM_MAYWRITE to gate whether a mapping's protections can be upgraded; with VM_MAYWRITE still present, any subsequent mprotect(PROT_READ|PROT_WRITE) call on the read-only mapping succeeds. The fix clears VM_MAYWRITE on the read-only path, mirroring a pattern already established in the i915 driver for its read-only GEM objects. The root cause class is an incomplete enforcement of immutability post-validation - the initial guard is present but the VM permission flag is not properly locked down, creating a TOCTOU-adjacent permission escalation. CPE: cpe:2.3:a:linux:linux:*.

RemediationAI

Upgrade to a patched Linux kernel release: 6.6.148, 6.12.101, 6.18.42, 7.1.6, or 7.2-rc5, applying the corresponding stable commit for the running kernel series from https://git.kernel.org/stable/. Distribution maintainers for Raspberry Pi OS, Ubuntu, Debian, and other VC4-targeting distributions should be monitored for downstream kernel updates incorporating these patches. For systems that cannot be immediately updated, restrict access to DRM device nodes (/dev/dri/card* and /dev/dri/renderD*) using filesystem permissions (e.g., chmod 660 with a restricted group) or udev rules so only trusted, explicitly authorized users can open GPU device files - this eliminates the local access prerequisite entirely. Trade-off: restricting /dev/dri access will break GPU-accelerated applications (display compositors, multimedia pipelines) for affected user accounts, requiring group membership management. As a secondary measure, consider kernel module unloading (rmmod vc4) on headless systems that do not require GPU access, though this may affect display output.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

CVE-2026-68445 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy