CVE-2026-43398

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel AMDGPU DRM driver. The affected wait ioctl path, amdgpu_userq_wait_ioctl, failed to enforce an upper bound on user-supplied values. A local user with access to the AMDGPU DRM device interface could submit excessively large input values, causing the kernel or driver path to allocate excessive memory and potentially trigger an out-of-memory condition. The expected impact is loss of availability through system instability, process termination by the OOM killer, GPU/graphics stack disruption, or host crash. It does not provide confidentiality or integrity impact by itself and does not enable remote exploitation without prior local access.

Why it matters to the business

Systems using affected Linux kernels with AMDGPU hardware or the AMDGPU driver exposed to local users may be vulnerable to intentional or accidental resource exhaustion. In practical terms, a low-privileged local user or compromised workload could degrade or crash a workstation, GPU compute node, desktop session host, or Linux system using AMD graphics. The business risk is highest for shared Linux workstations, VDI environments, GPU-enabled build or compute systems, kiosks, and multi-user servers where untrusted users can access DRM render devices. The CVSS score indicates moderate severity, EPSS is currently very low, it is not listed in CISA KEV, and there is no known exploit maturity reported, so remediation should be scheduled based on local exposure rather than treated as an active widespread exploitation emergency.

How an attack unfolds

An attacker first needs local code execution or an authenticated local account on a Linux system using an affected AMDGPU kernel driver. The attacker identifies accessible DRM device nodes, such as AMDGPU render or card devices under /dev/dri, and invokes the vulnerable AMDGPU user queue wait ioctl with abnormally large user-controlled values. Because vulnerable kernels do not cap the submitted value against the intended AMDGPU_USERQ_MAX_HANDLES limit, the driver may attempt excessive memory allocation. This can trigger kernel memory pressure, OOM-killer activity, GPU driver instability, termination of unrelated processes, graphical session failure, or a full system hang or reboot. The attack is not expected to cross privilege boundaries directly, but it can be useful to disrupt availability on shared systems or as a post-compromise impact technique.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the AMDGPU fix adding an upper-bound check in amdgpu_userq_wait_ioctl against AMDGPU_USERQ_MAX_HANDLES. Because no exact fixed package versions were provided, use vendor advisories for the deployed distribution and kernel stream, and verify the fix is present in the kernel source or changelog referencing the AMDGPU wait ioctl bounds check or upstream commit fcec012c664247531aed3e662f4280ff804d1476. Reboot systems after kernel upgrade so the patched kernel is active. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting membership in groups that grant access to /dev/dri devices, applying device cgroup controls for containers, and avoiding untrusted workloads on GPU-enabled hosts. These mitigations reduce exploitability but do not replace applying the kernel fix.

How to confirm the fix worked

Confirm the running kernel has been updated, not just installed, by checking the active kernel version after reboot and comparing it with the vendor-fixed kernel advisory. Validate that the AMDGPU driver in the running kernel contains an upper-bound check for user queue wait ioctl inputs against AMDGPU_USERQ_MAX_HANDLES. On source-based or custom kernels, inspect the AMDGPU DRM driver code or applied patches for the fix associated with upstream commit fcec012c664247531aed3e662f4280ff804d1476. Confirm that untrusted users or containers do not have unnecessary access to /dev/dri/card* or /dev/dri/renderD* devices. For exposure testing, inventory Linux systems with AMDGPU hardware or loaded amdgpu modules and identify those still running vulnerable kernel builds.

Typical attack path

1. Gain local access to a Linux system running an affected kernel with AMDGPU support.
2. Confirm the presence of AMDGPU DRM device nodes, commonly under /dev/dri/.
3. Open an accessible AMDGPU DRM render or card device from a low-privileged process.
4. Submit the vulnerable AMDGPU user queue wait ioctl with excessively large input values.
5. Force excessive kernel memory allocation in the AMDGPU wait path.
6. Cause out-of-memory behavior, GPU stack disruption, service interruption, system instability, or crash.

How to detect it

Detection should focus on signs of local denial-of-service activity rather than network indicators. Review kernel logs, systemd journal, audit logs, EDR telemetry, and GPU driver logs for unexplained OOM-killer events, sudden memory exhaustion, GPU resets, amdgpu errors, or system hangs that correlate with local processes accessing /dev/dri/card* or /dev/dri/renderD* device nodes. In auditd or EDR data, look for unusual processes opening DRM device files repeatedly or immediately before memory pressure events. On shared systems, correlate OOM events with user sessions, container starts, job scheduler activity, or recently executed binaries. Because exploitation may only involve legitimate ioctl calls to a device node, there may be no unique artifact beyond AMDGPU device access followed by memory exhaustion. If threat hunting finds suspicious local binaries or scripts associated with the event, preserve them for forensic analysis and investigate the initial local access path.

• amdgpu_userq_wait_ioctl
• AMDGPU_USERQ_MAX_HANDLES
• fcec012c664247531aed3e662f4280ff804d1476
• /dev/dri/card
• /dev/dri/renderD
• amdgpu
• Out of memory
• oom-killer
• invoked oom-killer
• Killed process
• Memory cgroup out of memory
• amdgpu: GPU reset
• amdgpu: ring
• drm:amdgpu

What your security team should do

• Inventory Linux systems with AMDGPU hardware, loaded amdgpu kernel modules, or exposed /dev/dri AMD GPU device nodes.
• Prioritize patching shared, multi-user, VDI, kiosk, GPU compute, and developer workstation systems where low-privileged users can access GPU devices.
• Apply the vendor-provided fixed kernel and reboot to ensure the patched kernel is running.
• For custom kernels, cherry-pick or verify the AMDGPU wait ioctl upper-bound fix associated with upstream commit fcec012c664247531aed3e662f4280ff804d1476.
• Restrict access to DRM render/card devices for untrusted users and containers until patching is complete.
• Monitor kernel, audit, and system logs for OOM-killer activity, AMDGPU errors, GPU resets, and repeated access to DRM device nodes from untrusted processes.
• Treat confirmed exploitation as a local post-compromise activity and investigate how the local account or workload obtained execution on the system.