CVE-2026-46199

What it actually does

This vulnerability is an out-of-bounds read in the Linux kernel AMDGPU driver, specifically in the VCN4 video decode message parsing path. A local user with access to the affected graphics/video decode interface may be able to cause the kernel driver to read beyond the bounds of a buffer object while processing crafted decode messages. The likely technical consequences are kernel memory disclosure and system instability, including GPU driver faults, kernel oops conditions, or denial of service. Because exploitation is local and requires low privileges, this is most relevant on workstations, GPU-enabled servers, virtual desktop infrastructure, media-processing systems, and shared compute platforms using affected AMDGPU hardware and drivers.

Why it matters to the business

Successful exploitation could allow a local user or compromised low-privilege process to expose sensitive kernel memory or crash systems that rely on AMD GPU acceleration. For organizations using Linux endpoints, GPU-backed workloads, media transcoding, AI/ML workstations, or shared compute environments, this can result in service disruption, reduced tenant isolation, investigation costs, and potential exposure of sensitive data resident in kernel memory. The issue is not currently listed in CISA KEV, has low EPSS, and has no known public exploit maturity, so urgency is lower than internet-facing remote code execution flaws, but affected systems should still be patched through normal kernel update cycles, with higher priority for multi-user or untrusted workload environments.

How an attack unfolds

An attacker first needs local code execution or an existing low-privilege account on a Linux system using an affected AMDGPU driver path. The attacker then interacts with the GPU/video decode interface in a way that submits a crafted VCN4 decode message backed by a malformed or undersized buffer object. When the kernel driver parses that message, vulnerable versions fail to consistently validate each access against the end of the buffer object. This can cause the driver to read memory outside the intended buffer. Depending on memory layout and kernel behavior, the attacker may use the condition to disclose kernel memory, trigger driver errors, or crash the system. There is no indication from the provided intelligence that this vulnerability is being exploited in the wild or associated with named threat actors or ransomware campaigns.

How to fix it

Update the Linux kernel to a version that includes the upstream AMDGPU VCN4 bounds-checking fix for decode message parsing. Because no exact fixed package versions were provided, use the kernel packages supplied by the relevant Linux distribution or vendor advisory and verify that the patch described as preventing out-of-bounds reads when parsing AMDGPU VCN4 decode messages is included. Where immediate patching is not possible, reduce exposure by restricting local access to GPU/DRM device nodes, limiting untrusted users and workloads on AMDGPU-enabled systems, disabling GPU video decode acceleration where operationally feasible, and prioritizing isolation for shared GPU systems. Reboot into the patched kernel after installation; merely installing kernel packages is insufficient if the system continues running the vulnerable kernel.

How to confirm the fix worked

Confirm exposure by checking whether affected systems are running Linux with the AMDGPU driver loaded and AMD hardware capable of using the VCN4 decode path. Validate remediation by confirming the active booted kernel version is the patched vendor kernel, not just that an updated package is installed. Review distribution changelogs or kernel commit history for the AMDGPU VCN4 decode message bounds-checking fix. After reboot, verify with tools such as uname, package manager queries, and kernel module information that the intended fixed kernel is active. For high-assurance environments, test that normal GPU video decode workloads continue to function and monitor kernel logs for absence of AMDGPU VCN/DRM oops, GPU reset, or fault messages under representative workload.

Typical attack path

1. Gain local execution on an affected Linux system, such as through a shell, user session, container escape prerequisite, compromised desktop process, or untrusted workload.
2. Confirm the system uses the AMDGPU kernel driver and hardware/driver path that exercises VCN4 video decode handling.
3. Open or interact with the relevant DRM/AMDGPU device interface available to the local user.
4. Submit a crafted video decode message or buffer object designed so that parser reads occur past the valid buffer boundary.
5. Trigger the vulnerable parsing path in the kernel AMDGPU VCN4 code.
6. Attempt to recover leaked kernel memory contents or repeatedly trigger the condition to cause GPU driver instability or a kernel crash.

How to detect it

Detection should focus on evidence of local attempts to exercise the AMDGPU VCN4 video decode path followed by abnormal kernel or GPU driver behavior. Useful log sources include the kernel ring buffer, system journal, syslog, audit logs for access to DRM device nodes, endpoint telemetry showing GPU/video workloads, crash dump infrastructure, and package/kernel update records. Look for kernel oops messages, general protection faults, page faults, GPU resets, AMDGPU ring timeouts, VCN decode errors, and repeated process crashes correlated with access to /dev/dri/card* or /dev/dri/renderD*. Because this is a memory-safety bug in kernel driver parsing, there may be no clean application-layer IOC and exploitation may only appear as instability or crash artifacts. If suspicious events are found, preserve dmesg/journal logs, vmcore or kdump output, process ancestry, user session information, command history where available, and records of which processes had DRM device access before the crash.

• amdgpu
• drm
• vcn
• vcn4
• VCN
• decode
• dec msg
• GPU reset
• GPU reset begin
• ring vcn
• ring vcn_dec
• ring gfx timeout
• amdgpu: GPU fault detected
• amdgpu: ring
• amdgpu: failed
• amdgpu: VM fault
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• kernel BUG
• Oops:
• Call Trace:
• /dev/dri/card0
• /dev/dri/renderD128

What your security team should do

• Inventory Linux systems using AMDGPU, especially workstations, GPU-enabled servers, VDI platforms, shared compute clusters, and media-processing hosts.
• Prioritize patching multi-user systems and systems that run untrusted or semi-trusted workloads, because exploitation requires local access.
• Apply vendor kernel updates that include the AMDGPU VCN4 bounds-checking fix and reboot systems into the updated kernel.
• Temporarily restrict access to /dev/dri devices for users or workloads that do not require GPU acceleration.
• Review whether containers, batch jobs, desktop applications, or remote user sessions are granted unnecessary GPU device access.
• Monitor kernel and system logs for AMDGPU, DRM, VCN, GPU reset, kernel oops, or general protection fault events that may indicate attempted triggering or instability.
• Treat repeated AMDGPU VCN-related crashes from low-privilege user activity as suspicious and preserve logs, crash dumps, and process execution history for investigation.
• Track distribution advisories for exact fixed kernel package versions and ensure vulnerability scanners validate the running kernel, not only installed packages.