CVE-2026-43195

What it actually does

This is a local improper input validation flaw in the Linux kernel AMDGPU DRM driver. A locally authenticated user with access to GPU user-queue functionality can submit an invalid queue size that does not meet hardware constraints, such as a non-power-of-two size or a size smaller than AMDGPU_GPU_PAGE_SIZE. Without validation, the driver may configure an invalid GPU ring/queue, causing GPU faults, driver instability, hangs, or denial of service. The impact is availability only; the published CVSS vector does not indicate confidentiality or integrity impact.

Why it matters to the business

Systems using affected Linux kernels with AMDGPU hardware may be vulnerable to local denial-of-service conditions, including GPU hangs, degraded graphics or compute workloads, and potential disruption of services that rely on AMD GPUs. This is most relevant for shared Linux workstations, VDI hosts, GPU compute nodes, CI runners, research clusters, and multi-user servers where untrusted or semi-trusted local users can run GPU workloads. The issue is not currently listed in CISA KEV, has no known public exploit maturity, and has very low EPSS, so it is generally a routine-priority kernel maintenance item unless the environment depends heavily on AMD GPU availability or allows many local users.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system and the ability to interact with AMDGPU user-queue interfaces. They then craft or use a program that requests an invalid GPU queue configuration, such as a queue size that is not a power of two or is smaller than the GPU page size expected by the hardware and driver. On vulnerable kernels, the AMDGPU driver may accept the invalid queue parameters and attempt to configure the GPU with them. This can trigger GPU faults, queue/ring failures, driver resets, application crashes, or a broader denial-of-service condition affecting GPU-dependent workloads. Exploitation does not require user interaction and does not provide a known path to remote code execution or data theft based on the available description.

How to fix it

Upgrade to a Linux kernel version that includes the upstream AMDGPU fix adding validation for user queue size constraints. Because no exact fixed package versions were provided, obtain the corrected kernel from the operating system vendor or distribution security channel and verify that the patch for `drm/amdgpu: validate user queue size constraints` is included. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users from GPU device access, reviewing permissions on `/dev/dri/*`, isolating untrusted GPU workloads in dedicated hosts or containers with constrained device access, and disabling or unloading AMDGPU functionality only where operationally acceptable. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the system continues running the vulnerable kernel.

How to confirm the fix worked

Confirm the running kernel is the patched vendor build, not just that an updated kernel package is installed. Validate with commands such as `uname -r`, distribution package queries, and vendor advisories for the specific kernel build. On source-built kernels, confirm the AMDGPU patch that enforces power-of-two queue sizes and minimum `AMDGPU_GPU_PAGE_SIZE` queue size is present. Check that systems with AMD GPUs have rebooted into the fixed kernel. If practical in a test environment, attempt to submit invalid AMDGPU user queue sizes and verify the driver rejects them cleanly rather than causing GPU faults or hangs. Also review `/dev/dri/*` permissions to ensure only intended users or services can access GPU devices.

Typical attack path

1. Obtain local user access to a Linux system using the affected AMDGPU kernel driver.
2. Confirm that AMDGPU hardware and relevant DRM/user-queue interfaces are available to the user.
3. Run a crafted GPU workload or proof-of-concept program that submits an invalid user queue size.
4. Cause the kernel driver to accept the invalid queue configuration because required size validation is missing.
5. Trigger GPU faults, hangs, driver resets, or failure of GPU-dependent applications and services.
6. Repeat the action if needed to sustain denial of service until the system, driver, or GPU stack is reset or patched.

How to detect it

Because this flaw causes availability symptoms rather than a distinctive payload, post-exploitation detection should focus on kernel, system, and GPU telemetry. Review `dmesg`, `journalctl -k`, syslog, audit logs, and GPU workload supervisor logs for AMDGPU faults, ring timeouts, GPU resets, queue creation failures, or repeated application crashes around the same time as local user GPU activity. Correlate events with process execution logs, shell history, job scheduler records, container runtime logs, and access to `/dev/dri/card*` or `/dev/dri/renderD*`. In shared GPU environments, look for repeated short-lived processes run by the same user immediately before AMDGPU resets or hangs. These indicators are not unique to this vulnerability and can also be caused by driver bugs, hardware instability, or malformed benign GPU workloads, so findings should be validated against kernel version and user activity.

• amdgpu: GPU fault
• amdgpu: ring gfx timeout
• amdgpu: ring compute timeout
• amdgpu: GPU reset begin
• amdgpu: GPU reset succeeded
• amdgpu: failed to reset gpu
• amdgpu: device lost
• amdgpu: VM fault
• /dev/dri/card0
• /dev/dri/renderD128
• drm/amdgpu

What your security team should do

• Inventory Linux systems using AMDGPU hardware and identify their running kernel versions.
• Prioritize patching shared, multi-user, GPU compute, VDI, workstation fleet, and CI systems where local users can run arbitrary GPU workloads.
• Apply the vendor-provided kernel update that includes the AMDGPU user queue size validation fix, then reboot into the updated kernel.
• Until patching is complete, restrict access to `/dev/dri/card*` and `/dev/dri/renderD*` devices to trusted users and workloads only.
• Monitor kernel and system logs for AMDGPU faults, GPU resets, ring timeouts, and repeated graphics/compute workload crashes that may indicate attempted triggering of the issue.
• Treat this as routine priority for single-user endpoints with trusted users, but elevate priority for business-critical GPU workloads or shared systems.
• Track distribution advisories because exact fixed package versions vary by Linux vendor and kernel branch.