CVE-2026-45976

What it actually does

This is a local availability vulnerability in the Linux kernel AMDGPU DRM driver. During AMDGPU RAS initialization, if amdgpu_nbio_ras_sw_init() fails, amdgpu_ras_init() returns without freeing an allocated context structure, causing a kernel memory leak. If the failing initialization path can be triggered repeatedly, unreclaimed kernel memory may accumulate and degrade system stability or lead to memory exhaustion. The issue does not directly provide code execution, privilege escalation, data disclosure, or data modification based on the published description.

Why it matters to the business

Systems using affected Linux kernels with AMDGPU hardware or the AMDGPU driver enabled may become unstable if the vulnerable initialization failure path is repeatedly exercised. The likely operational consequence is reduced availability, including degraded performance, service interruption, or host reboot caused by memory pressure. The risk is lower than a remote compromise because exploitation requires local access and specific driver conditions, and there is no known public exploitation or CISA KEV listing at this time.

How an attack unfolds

An attacker first needs local access to a system running an affected Linux kernel with the AMDGPU driver present and relevant AMD GPU/RAS initialization code reachable. The attacker then attempts to repeatedly trigger AMDGPU driver initialization or reinitialization conditions where amdgpu_nbio_ras_sw_init() fails after the RAS context allocation has occurred. Each failed attempt leaks a small amount of kernel memory because the error path returns before freeing the allocated structure. Over many repetitions, this can increase kernel memory pressure and may eventually cause degraded performance, out-of-memory behavior, driver instability, or broader host availability impact. No public exploit maturity is reported, and practical exploitability depends on whether an unprivileged or low-privileged local user can reliably cause the failing driver path on the target system.

How to fix it

Apply a Linux kernel update from the operating system or kernel vendor that includes the upstream AMDGPU fix for the memory leak in amdgpu_ras_init(). Because no fixed package versions were provided, use the latest vendor-supported kernel for the affected distribution and confirm that the patch is included in the changelog or source tree. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting the ability to load/unload kernel modules, disabling unneeded GPU access for untrusted users or containers, and avoiding AMDGPU driver exposure on systems that do not require it. Do not rely solely on mitigation if AMDGPU is required on multi-user systems; patching is the durable fix.

How to confirm the fix worked

Confirm the system is running a patched kernel from the Linux distribution or kernel vendor and verify that the AMDGPU driver source contains the corrected error path in amdgpu_ras_init(), where failure after amdgpu_nbio_ras_sw_init() branches to cleanup logic instead of returning directly. Validate package status with the distribution package manager, verify the running kernel version after reboot, and compare it against the vendor advisory or changelog. On systems with AMDGPU hardware, review kernel logs after driver initialization, GPU reset, suspend/resume, or module reload testing to confirm there are no recurring initialization failures or abnormal memory growth. For high-assurance validation, use kernel memory leak tooling such as kmemleak or controlled regression testing in a non-production environment.

Typical attack path

1. Gain local access to a Linux system running an affected kernel with the AMDGPU driver enabled or loadable.
2. Identify whether AMD GPU hardware, virtual GPU exposure, or driver configuration allows AMDGPU initialization paths to be exercised.
3. Trigger AMDGPU driver initialization, reset, reprobe, module load/unload, suspend/resume, or related error conditions that cause amdgpu_nbio_ras_sw_init() to fail.
4. Repeat the failing path to accumulate leaked kernel memory.
5. Monitor or wait for memory pressure, driver instability, out-of-memory events, service disruption, or host reboot.

How to detect it

There are no publicly reported exploitation indicators specific to this vulnerability. To assess possible prior exploitation or triggering, review kernel logs, system journals, GPU driver logs, and monitoring telemetry for repeated AMDGPU initialization failures followed by increasing kernel memory usage, slab growth, OOM killer events, GPU reset loops, or unexpected reboots. Relevant log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, kernel oops reports, GPU monitoring logs, and endpoint telemetry showing repeated modprobe/rmmod or device reset activity involving amdgpu. Investigate suspicious local user activity that repeatedly loads/unloads AMDGPU modules, resets GPU devices, manipulates PCI device binding, or causes suspend/resume or driver reprobe loops. Memory-forensics confirmation is difficult after reboot; on live systems, compare kernel memory growth with repeated AMDGPU failure events and consider using kmemleak or vendor debugging guidance in a controlled environment.

What your security team should do

• Inventory Linux systems using AMDGPU hardware, AMDGPU kernel modules, GPU passthrough, or GPU-enabled workloads.
• Prioritize patching multi-user Linux systems, GPU compute hosts, workstations, virtualization hosts with GPU passthrough, and systems where local users or containers can interact with GPU devices.
• Upgrade to the latest vendor-supported kernel that includes the AMDGPU RAS initialization memory leak fix, then reboot into the patched kernel.
• Restrict local access and GPU device access for untrusted users until patching is complete.
• Restrict kernel module loading/unloading to trusted administrators and ensure secure boot or module-signing controls are enforced where applicable.
• Monitor kernel logs and memory telemetry for repeated AMDGPU initialization failures, GPU reset loops, increasing slab/kernel memory use, and OOM killer activity.
• Because EPSS is very low and there is no known exploitation or KEV listing, treat this as a stability and local-denial-of-service issue rather than an emergency remote-compromise event unless exposed in shared or adversarial local-access environments.