CVE-2026-68272
NoneCVSS
—
EPSS
0.2%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
A missing check in the graphics driver lets certain local users send bad data that crashes the whole system.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Improper Input Validation
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
Missing minimum length validation on AMDGPU_CHUNK_ID_CP_GFX_SHADOW allows a zero-length chunk to pass IS_ERR checks, resulting in ZERO_SIZE_PTR dereference and NULL pointer dereference in amdgpu_cs_p2_shadow when reading struct drm_amdgpu_cs_chunk_cp_gfx_shadow.
Why it matters to the business
Unprivileged users with access to the render group can trigger kernel crashes, causing denial of service on graphics workloads and potential system instability in environments using AMD GPUs.
How an attack unfolds
An attacker in the render group crafts a command submission buffer containing an AMDGPU_CHUNK_ID_CP_GFX_SHADOW entry with length_dw set to zero. The kernel's amdgpu_cs_pass1 accepts the chunk without size validation, vmemdup_array_user returns ZERO_SIZE_PTR, and amdgpu_cs_p2_shadow later dereferences it as a fixed-size struct, faulting the kernel.
How to fix it
Apply the upstream fix that adds an explicit minimum-length check for the CP_GFX_SHADOW chunk type in amdgpu_cs_pass1 and rejects undersized submissions with -EINVAL. Rebuild and deploy the patched kernel.
How to confirm the fix worked
Confirm the presence of the size check for AMDGPU_CHUNK_ID_CP_GFX_SHADOW in amdgpu_cs_pass1 and verify that zero-length submissions now return -EINVAL before reaching pass2.
Typical attack path
- Obtain membership in the render group or equivalent GPU access
- Allocate a command submission structure with AMDGPU_CHUNK_ID_CP_GFX_SHADOW and length_dw == 0
- Submit the structure via the amdgpu ioctl path
- Trigger kernel NULL pointer dereference during CS processing
How to detect it
Search kernel logs for oops or panic messages referencing amdgpu_cs_p2_shadow or drm_amdgpu_cs_chunk_cp_gfx_shadow after unprivileged command submissions; inspect audit logs for unusual amdgpu ioctl calls from non-privileged processes.
What your security team should do
- Prioritize kernel update containing the CP_GFX_SHADOW length validation
- Restrict render-group membership to trusted processes only
- Monitor for unexpected kernel oops or NULL dereference events on AMD GPU systems
The record
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|