CVE-2026-46218

What it actually does

This is a local Linux kernel vulnerability in the AMDGPU DRM driver. The vulnerable UVD/VCE/VCN video command-processing paths read from or write to indirect buffers at predefined offsets without first confirming that the buffer is large enough. A local user with access to GPU/video acceleration interfaces could submit malformed GPU work that causes out-of-bounds access in kernel driver context. The likely impact is kernel memory disclosure and/or system instability, including GPU hangs, kernel faults, 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.

Why it matters to the business

Systems using affected Linux kernels with AMD GPU functionality enabled may be exposed to local privilege-boundary risk: a low-privileged user or compromised workload could potentially crash affected hosts or expose sensitive kernel memory. This is most relevant for Linux desktops, GPU-enabled workstations, VDI, rendering nodes, media-processing systems, and shared compute environments where untrusted or semi-trusted users can access GPU acceleration. EPSS is currently low and there is no known KEV listing or public exploit maturity reported, so urgency is moderate, but kernel driver flaws should still be prioritized on multi-user or GPU-sharing systems because exploitation occurs below application-level controls.

How an attack unfolds

An attacker first obtains local, low-privileged execution on a Linux system that loads the AMDGPU driver and exposes GPU/video acceleration interfaces. The attacker then submits crafted GPU command buffers targeting the affected UVD, VCE, or VCN paths. Because the vulnerable code assumes certain indirect-buffer offsets are valid, the malformed buffer can cause the driver to access memory outside the intended buffer bounds. Depending on kernel version, hardware state, memory layout, and driver error handling, this may result in kernel memory exposure, a GPU fault, a driver reset, or a broader system crash. There is no indication from the provided intelligence that this vulnerability is being exploited in the wild or used in ransomware campaigns.

How to fix it

Apply a Linux kernel update that includes the AMDGPU fix adding bounds checking to ib_get_value and ib_set_value and using a fixed-width unsigned index to avoid overflow-related bypasses. Because no exact fixed package versions were provided, obtain the corrected kernel from the relevant Linux distribution, vendor kernel channel, or upstream stable kernel branch, and reboot into the updated kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting access to DRM render devices such as /dev/dri/renderD*, disabling or unloading the amdgpu module where AMD GPU functionality is not required, disabling GPU passthrough or shared GPU access for untrusted workloads, and isolating GPU-capable workloads to trusted users only. Mitigations that remove GPU access may affect graphics, video acceleration, rendering, or compute workloads and should be tested before broad deployment.

How to confirm the fix worked

Confirm the running kernel contains the AMDGPU bounds-checking fix, not merely that an updated package is installed. Validate with `uname -r`, distribution package metadata, and vendor advisories for the active booted kernel. On source-based or custom kernels, verify that the AMDGPU driver includes bounds checks in ib_get_value and ib_set_value for indirect-buffer index access. Confirm whether the AMDGPU driver is loaded with `lsmod | grep amdgpu` and whether render devices are exposed under `/dev/dri/`. After remediation, reboot and confirm the host is running the fixed kernel. For mitigation validation, verify that untrusted users cannot access GPU render nodes through file permissions, udev rules, container device mappings, or virtualization passthrough configuration.

Typical attack path

1. Gain local low-privileged execution on a Linux host with the AMDGPU kernel driver loaded.
2. Confirm access to GPU/video acceleration interfaces, such as DRM render nodes or video decode/encode paths.
3. Submit malformed GPU indirect buffers that are smaller than the offsets assumed by the vulnerable UVD/VCE/VCN code.
4. Trigger out-of-bounds access in the AMDGPU driver during command parsing or value retrieval/update.
5. Observe resulting effects such as kernel memory disclosure, GPU reset, process termination, kernel fault, or denial of service.

How to detect it

Detection is primarily forensic and behavioral because no public exploit-specific indicators were provided. Review kernel logs, journald, syslog, audit logs, and endpoint telemetry for unusual AMDGPU faults, GPU resets, kernel oops messages, or repeated crashes shortly after local users or workloads access `/dev/dri/` devices. Useful log sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, auditd records for `/dev/dri/card*` and `/dev/dri/renderD*`, EDR process telemetry, container runtime device-mapping logs, and hypervisor/GPU passthrough logs. Look for low-privileged processes opening DRM render nodes immediately before AMDGPU errors, GPU ring timeouts, VCN/UVD/VCE failures, or kernel panic events. Because normal driver instability can produce similar logs, correlate events with user sessions, recently executed binaries, container starts, GPU workloads, and repeated reproduction patterns across the same host or user. Absence of these artifacts does not prove non-exploitation, especially if logs rotated or the host crashed before persistence of logs.

• amdgpu: GPU fault detected
• amdgpu_job_timedout
• GPU reset begin
• GPU reset succeeded
• ring gfx timeout
• ring vcn timeout
• ring uvd timeout
• ring vce timeout
• *ERROR* amdgpu
• /dev/dri/renderD
• /dev/dri/card
• kernel BUG at drivers/gpu/drm/amd
• BUG: kernel NULL pointer dereference
• general protection fault
• Oops:
• Kernel panic - not syncing

What your security team should do

• Prioritize patching Linux systems with AMD GPUs that are multi-user, internet-facing through remote desktop, used for VDI, used for shared compute, or allow untrusted containers/workloads to access GPU devices.
• Update to a vendor-supported kernel containing the AMDGPU ib_get_value/ib_set_value bounds-checking fix and reboot into the fixed kernel.
• Inventory systems with the amdgpu module loaded and `/dev/dri/renderD*` exposed to non-root or broad user groups.
• Temporarily restrict access to GPU render/video devices for untrusted users until patched.
• Review kernel, audit, and system logs for historical GPU faults, AMDGPU resets, kernel oopses, or suspicious local processes interacting heavily with `/dev/dri/`.
• Monitor vendor advisories and distribution backports because fixed version numbers may vary by distribution and kernel branch.
• Treat unexplained repeated GPU resets or kernel crashes on shared AMD GPU systems as potentially security-relevant until patched and investigated.