CVE-2026-43400

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel AMDGPU DRM driver. The affected ioctl path, amdgpu_userq_signal_ioctl, accepted excessively large user-supplied values without enforcing an upper bound. A local user with access to AMDGPU DRM device nodes could submit oversized values that cause excessive kernel memory allocation, potentially triggering out-of-memory conditions and system instability or crash. The impact is availability-only; it does not directly provide code execution, privilege escalation, or data disclosure based on the available description.

Why it matters to the business

Systems using affected Linux kernels with AMDGPU hardware or enabled AMDGPU DRM functionality may be vulnerable to local users or compromised low-privilege workloads causing service outages. This is most relevant for shared Linux workstations, GPU compute nodes, VDI hosts, CI/build systems, research clusters, and multi-user servers where untrusted or semi-trusted users can access GPU device files. Although exploitation is local and no known public exploitation or KEV listing is reported, successful abuse can interrupt business operations by crashing hosts, killing workloads, or degrading GPU-dependent services.

How an attack unfolds

An attacker first needs local code execution or an existing low-privilege account on a Linux system where the AMDGPU driver is present and accessible. The attacker opens an AMDGPU DRM device, such as a render or card device under /dev/dri, and invokes the vulnerable signal ioctl with abnormally large handle/count values. Because vulnerable kernels do not properly cap those inputs, the kernel may attempt excessive allocation or processing. Repeated or single oversized requests can exhaust memory, invoke the kernel OOM killer, terminate critical processes, hang GPU-related services, or crash the host. This attack does not require user interaction and is not expected to be exploitable remotely unless an attacker can first run code locally through another weakness, compromised account, container escape/misconfiguration, or exposed compute workload.

How to fix it

Upgrade to a Linux kernel version that includes the AMDGPU fix adding an upper-bound check against AMDGPU_USERQ_MAX_HANDLES in amdgpu_userq_signal_ioctl. No exact fixed package versions were provided in the input, so use the fixed kernel packages from the relevant Linux distribution, vendor advisory, or upstream stable kernel release that contains the patch derived from commit be267e15f99bc97cbe202cd556717797cdcf79a5. Where immediate patching is not possible, reduce exposure by restricting access to GPU DRM device nodes, removing untrusted users from groups that grant /dev/dri access, disabling or unloading the amdgpu module where AMDGPU functionality is not required, isolating untrusted workloads from GPU-capable hosts, and applying cgroup/container resource controls to limit the blast radius of memory exhaustion. Reboot into the patched kernel after installation; simply installing a kernel package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the system is running a vendor kernel that contains the AMDGPU ioctl bounds-check fix, not merely that an updated package is installed. Validate with uname -r, distribution package changelogs, vendor CVE advisories, or source inspection for the upper-bound check using AMDGPU_USERQ_MAX_HANDLES in the amdgpu_userq_signal_ioctl path. Check whether AMDGPU is loaded with lsmod | grep amdgpu and whether GPU device nodes are accessible with ls -l /dev/dri/. Confirm untrusted users do not have unnecessary access to /dev/dri/card* or /dev/dri/renderD*. After patching and rebooting, verify that the running kernel version matches the fixed vendor build and that GPU workloads continue to function normally.

Typical attack path

1. Obtain local shell access or the ability to execute code as a low-privilege user on a Linux system.
2. Confirm that AMDGPU DRM device nodes are present and accessible, commonly under /dev/dri/.
3. Open an AMDGPU DRM device such as /dev/dri/renderD* or /dev/dri/card*.
4. Call the vulnerable AMDGPU user queue signal ioctl with extremely large user-controlled values.
5. Trigger excessive kernel memory allocation or processing in the AMDGPU driver.
6. Cause out-of-memory behavior, process termination, GPU instability, system hang, or host crash.

How to detect it

To determine whether this was already exploited, review host-level telemetry and kernel logs for memory exhaustion or GPU-driver instability correlated with local access to AMDGPU DRM devices. Relevant sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd logs, EDR process telemetry, shell history where available, and container runtime logs for workloads with /dev/dri passthrough. Look for OOM killer events, sudden host reboots, GPU resets, amdgpu ring timeouts, DRM scheduler failures, or repeated process access to /dev/dri/renderD* and /dev/dri/card*. Exploitation may leave few durable artifacts because the primary effect is resource exhaustion, so absence of a clear payload file does not rule it out. Correlate suspicious events with local users, batch jobs, containers, or processes that had GPU device access immediately before the outage.

• amdgpu_userq_signal_ioctl
• AMDGPU_USERQ_MAX_HANDLES
• /dev/dri/renderD
• /dev/dri/card
• /dev/dri/renderD*
• /dev/dri/card*
• Out of memory: Killed process
• oom-killer
• invoked oom-killer
• Memory cgroup out of memory
• amdgpu: GPU reset
• amdgpu: ring
• ring gfx timeout
• drm_sched_job_timedout
• amdgpu_job_timedout
• [drm:amdgpu_job_timedout]
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Prioritize patching shared, multi-user, GPU-enabled Linux systems, especially compute clusters, workstations, VDI hosts, and CI runners where low-privilege users or workloads can access AMDGPU devices.
• Inventory Linux systems with the amdgpu module loaded and /dev/dri device nodes exposed to non-administrative users.
• Apply vendor-provided fixed kernel updates and reboot into the patched kernel.
• If patching is delayed, restrict access to /dev/dri devices by tightening group membership, udev rules, container device passthrough policies, and GPU scheduling controls.
• Review recent kernel logs for OOM killer activity, GPU hangs, amdgpu errors, or unexplained crashes on AMDGPU-enabled systems.
• Monitor for unusual local processes repeatedly opening /dev/dri/card* or /dev/dri/renderD* and causing memory pressure.
• Do not treat this as a network-exposed remote-code-execution issue; focus response on local access control, shared-host hardening, and availability monitoring.