CVE-2026-46204

What it actually does

This is a local Linux kernel vulnerability in the AMDGPU VCN4 command/indirect-buffer parsing path. A low-privileged local user with access to AMD GPU DRM devices can submit a crafted command buffer that causes the kernel driver to read beyond the bounds of the supplied indirect buffer. Because the flaw is an out-of-bounds read in kernel-space driver code, the expected impacts are sensitive memory disclosure and system instability, including GPU hangs, kernel warnings, oopses, or denial of service. The CVSS vector indicates local access, low attack complexity, low privileges, no user interaction, high confidentiality impact, and high availability impact, with no expected integrity impact.

Why it matters to the business

Systems that expose AMDGPU acceleration to local users, desktop sessions, GPU-enabled workloads, or containers may be susceptible to local data exposure or service disruption. In multi-user, VDI, workstation, build, research, rendering, AI/ML, or containerized GPU environments, a low-privileged user or compromised workload could potentially crash GPU-dependent services or expose sensitive kernel memory. The vulnerability is not currently listed in CISA KEV, has low EPSS, and has no known public exploit maturity, so broad internet-scale exploitation is unlikely; however, local privilege boundaries around shared GPU systems should be treated as important.

How an attack unfolds

An attacker first needs local code execution on a system using the vulnerable Linux kernel AMDGPU driver with affected VCN4 hardware enabled and accessible. The attacker opens a DRM device such as a render node under /dev/dri and submits a malformed AMDGPU command submission or indirect buffer targeting the VCN parsing logic. Because the vulnerable parser does not adequately validate bounds while reading values from the indirect buffer, the driver reads past the attacker-controlled buffer boundary. Depending on memory layout and error handling, this can leak kernel memory through observable responses or trigger driver/kernel faults that hang the GPU or crash the system. Exploitation is constrained to local attackers with device access and is most relevant where untrusted users or workloads can access AMD GPU devices.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution or kernel vendor that includes the AMDGPU VCN4 parser fix described as using amdgpu_ib_get_value() for bounds-checked indirect-buffer reads. No exact fixed version was provided in the input, so use vendor advisories, distribution errata, or stable kernel changelogs to identify the first patched build for each maintained kernel branch. Where immediate patching is not possible, reduce exposure by restricting access to /dev/dri/card* and /dev/dri/renderD* to trusted users only, removing unnecessary users from GPU-access groups such as video or render, avoiding GPU device passthrough to untrusted containers, disabling AMDGPU acceleration for untrusted workloads, or temporarily blacklisting/disabling the amdgpu module on systems where GPU functionality is not required. Reboot after kernel update or driver/module replacement to ensure the patched code is running.

How to confirm the fix worked

Confirm the running kernel is a vendor-patched build, not merely that an updated package is installed. Validate with uname -a, package manager metadata, distribution security advisories, and kernel changelogs showing the AMDGPU VCN4 indirect-buffer bounds-check fix. Verify that the amdgpu module currently loaded belongs to the patched kernel build using modinfo amdgpu and lsmod. Check whether untrusted users or containers can access /dev/dri/card* or /dev/dri/renderD* and confirm permissions are intentionally restricted. Review recent kernel logs for AMDGPU VCN errors, GPU resets, ring timeouts, kernel oopses, or crashes before and after remediation. If a trusted regression test or vendor reproducer is available, run it only in an isolated test system and confirm it no longer causes out-of-bounds read symptoms, GPU reset, or kernel fault.

Typical attack path

1. Obtain low-privileged local code execution on a Linux system using an affected AMDGPU kernel driver and VCN4-capable AMD GPU.
2. Confirm access to DRM render or card devices, commonly under /dev/dri/.
3. Use DRM/AMDGPU ioctls to submit a crafted command submission containing a malformed VCN indirect buffer.
4. Trigger the vulnerable VCN4 indirect-buffer parser to read outside the submitted buffer bounds.
5. Use the resulting behavior to attempt kernel memory disclosure, or repeatedly trigger the bug to cause GPU hangs, driver resets, kernel oopses, or denial of service.

How to detect it

Detection should focus on signs of prior local exploitation or attempted triggering because there may be no definitive exploit artifact. Collect and review kernel logs from journalctl, dmesg, syslog, kern.log, crash dumps, and GPU service logs for AMDGPU VCN errors, indirect-buffer parsing failures, GPU resets, ring timeouts, kernel oopses, page faults, or unexplained reboots. Review auditd, EDR, or process accounting data for unusual or untrusted processes opening /dev/dri/card* or /dev/dri/renderD* and issuing heavy DRM/AMDGPU ioctl activity shortly before crashes or GPU resets. In containerized environments, review container runtime configuration and logs for workloads granted access to AMD GPU devices. Correlate GPU resets or kernel faults with user sessions, process launches, container starts, and access to DRM render nodes. Because this vulnerability is a local kernel-driver out-of-bounds read, network telemetry alone is not expected to show exploitation.

• /dev/dri/renderD
• /dev/dri/card
• amdgpu
• AMDGPU
• VCN
• vcn
• IB parse
• indirect buffer
• GPU reset
• amdgpu: GPU reset
• ring timeout
• amdgpu_job_timedout
• drm:amdgpu_job_timedout
• *ERROR* ring
• *ERROR* amdgpu
• kernel BUG
• BUG: unable to handle page fault
• general protection fault
• Oops:
• Call Trace:
• amdgpu_cs_ioctl
• DRM_IOCTL_AMDGPU_CS

What your security team should do

• Prioritize patching Linux systems with AMD GPUs that are shared by multiple users, exposed to untrusted workloads, used for VDI/desktop access, or passed through into containers.
• Inventory systems with the amdgpu kernel module loaded and AMDGPU DRM devices present under /dev/dri/.
• Apply vendor kernel updates that include the AMDGPU VCN4 indirect-buffer parser bounds-check fix, then reboot into the patched kernel.
• Until patched, restrict GPU device access to trusted users and remove unnecessary memberships in render or video groups.
• Review container, VM, batch-processing, and desktop policies to ensure untrusted workloads are not granted direct AMDGPU device access unless required.
• Monitor kernel and system logs for AMDGPU VCN parser errors, GPU resets, ring timeouts, kernel oopses, and unexplained reboots, especially on shared GPU hosts.
• Treat successful local exploitation as a possible kernel memory exposure event and perform incident response if suspicious GPU-triggered crashes or repeated malformed command submissions are observed.