CVE-2026-46230

What it actually does

This is an out-of-bounds read in the Linux kernel AMDGPU driver, specifically in VCN3 video decode message parsing. A locally authenticated user who can submit crafted decode messages through the AMD GPU driver interface may cause the kernel driver to read beyond the bounds of the backing buffer object. Depending on kernel configuration, memory layout, and driver state, this can result in kernel memory disclosure, driver instability, GPU reset, or a kernel crash. The CVSS vector indicates local access, low attack complexity, low privileges, no user interaction, high confidentiality impact, and high availability impact, with no direct integrity impact.

Why it matters to the business

Systems using affected Linux kernels with AMDGPU VCN3-capable hardware may be exposed to local information disclosure or denial-of-service risk. In shared workstations, GPU-enabled desktop fleets, VDI, build hosts, media-processing systems, or multi-user compute environments, a low-privileged local user or compromised account could potentially crash affected systems or expose sensitive kernel memory. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no known public exploit maturity, so urgency is lower than internet-exposed remote-code-execution issues; however, kernel flaws should still be prioritized where untrusted local users, containers with GPU access, or shared GPU resources are present.

How an attack unfolds

An attacker first obtains local code execution with a low-privileged account on a Linux system using the affected AMDGPU driver path. The attacker then interacts with the GPU device interface, typically through DRM/render-node access, and submits malformed or intentionally truncated VCN3 decode messages backed by a buffer object. When the kernel AMDGPU VCN3 parser processes the crafted message without sufficiently validating each access against the end of the buffer object, it can read memory outside the intended message bounds. The attacker may use repeated attempts to trigger a kernel warning, GPU reset, crash, or potentially recover adjacent kernel memory depending on exposure through the calling path and system hardening. There is currently no indication from the provided data that this vulnerability is being exploited in the wild.

How to fix it

Upgrade to a Linux kernel build that includes the AMDGPU VCN3 bounds-checking fix for decode message parsing. Because no exact fixed package versions were provided, use the fixed kernel releases from the relevant Linux distribution, vendor, or long-term-support kernel branch once available. Prioritize patching systems with AMD GPUs exposed to untrusted users, shared GPU workloads, desktop login environments, VDI, containers with GPU passthrough, media-processing workloads, or multi-tenant compute use. If immediate patching is not possible, reduce exposure by restricting local access to GPU device nodes, limiting membership in GPU-related groups such as video or render where operationally feasible, disabling unneeded GPU acceleration paths, removing GPU access from untrusted containers or sandboxed workloads, and applying standard kernel hardening and crash dump protections.

How to confirm the fix worked

Confirm the running kernel version or vendor package changelog includes the AMDGPU VCN3 fix that checks decode message accesses against the end of the buffer object. Validate that the system has rebooted into the patched kernel, not merely installed it. Review distribution advisories for the affected kernel package and compare against the deployed package version. On systems without AMDGPU hardware or without the amdgpu module loaded, practical exposure is reduced, but the kernel package should still be updated according to normal patch policy. Where GPU access is restricted as a mitigation, verify permissions on DRM device nodes such as /dev/dri/renderD* and /dev/dri/card* and confirm untrusted users or containers cannot access them. After patching, monitor for absence of recurring amdgpu, VCN, GPU reset, kernel oops, or KASAN out-of-bounds-read events under normal workloads.

Typical attack path

1. Gain local execution on a Linux system with an affected kernel and AMDGPU VCN3-capable hardware or GPU device access.
2. Confirm access to the relevant DRM/render device interface, such as access granted through local session permissions, video/render groups, or a GPU-enabled workload.
3. Create crafted VCN3 decode message data in a buffer object with malformed lengths, offsets, or truncated content.
4. Submit the crafted decode operation to the AMDGPU kernel driver.
5. Trigger an out-of-bounds read during decode message parsing.
6. Attempt to observe kernel memory leakage, GPU driver instability, GPU reset, kernel oops, or system crash.

How to detect it

Look for evidence of local attempts to trigger AMDGPU VCN decode parsing failures. Relevant sources include kernel logs, system journal, dmesg output, crash dumps, GPU service logs, endpoint telemetry for repeated GPU device access, audit logs for access to /dev/dri devices, and container runtime logs showing GPU device passthrough. Suspicious patterns include repeated amdgpu VCN decode failures, GPU resets, kernel oops messages, KASAN or UBSAN reports involving amdgpu or VCN parsing, unexplained local crashes after GPU decode operations, and bursts of access to /dev/dri/renderD* by unusual users or short-lived processes. There are no known public exploit-specific artifacts in the provided data, so detection should focus on anomalous local GPU device access combined with kernel memory-safety fault indicators.

• amdgpu
• vcn
• VCN
• /dev/dri/renderD
• /dev/dri/card
• GPU reset
• GPU fault detected
• ring vcn_dec
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: KASAN
• kernel BUG
• Oops:
• general protection fault
• drm/amdgpu
• amdgpu: VCN
• amdgpu_vcn

What your security team should do

• Inventory Linux systems running AMDGPU-capable kernels, especially workstations, VDI, GPU-enabled servers, and systems allowing multiple local users.
• Prioritize remediation for hosts where untrusted users, containers, CI jobs, media workloads, or shared compute workloads have access to /dev/dri devices.
• Apply vendor-provided kernel updates containing the AMDGPU VCN3 bounds-checking fix and reboot into the fixed kernel.
• If patching must be delayed, restrict access to GPU device nodes and remove unnecessary users or workloads from GPU-related permission groups.
• Review container, virtualization, and orchestration configurations to ensure GPU passthrough or device mounts are not granted to untrusted workloads unless required.
• Monitor kernel logs for amdgpu faults, VCN decode errors, KASAN out-of-bounds reads, GPU resets, and kernel oops events that could indicate attempted triggering.
• Treat unexplained kernel crashes or repeated GPU resets on shared systems as potentially security-relevant until ruled out.
• Because EPSS is low, KEV is false, and exploit maturity is listed as none, prioritize based on local exposure and multi-user risk rather than broad emergency response.