CVE-2026-45947

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel AMDGPU driver. In the amdgpu_acpi_enumerate_xcc() code path, an allocation for xcc_info is not released if amdgpu_acpi_dev_init() fails with -ENOMEM. Repeatedly reaching this error path can leak kernel memory, increasing memory pressure and potentially degrading system stability or causing availability-impacting failures. The flaw does not provide confidentiality or integrity impact and requires local access with low privileges according to the assigned CVSS vector.

Why it matters to the business

Systems using affected Linux kernel versions with AMDGPU driver support may be susceptible to local availability disruption. In practical terms, an attacker or malfunctioning local workload could contribute to kernel memory exhaustion, instability, service degradation, or host reboot scenarios. The risk is lower than remotely exploitable kernel issues because exploitation requires local access, it is not listed in CISA KEV, ransomware use is not reported, EPSS is very low, and no mature exploit is currently indicated; however, production systems with shared users, GPU workloads, or multi-tenant compute exposure should still prioritize kernel maintenance.

How an attack unfolds

An attacker first needs local code execution or an account on a system running an affected Linux kernel with the AMDGPU driver path available. The attacker then attempts to exercise the AMDGPU ACPI XCC enumeration path while inducing or relying on memory allocation failure conditions that cause amdgpu_acpi_dev_init() to return -ENOMEM. In vulnerable kernels, the function returns without freeing the previously allocated xcc_info object. By repeatedly triggering the vulnerable path, the attacker can cause cumulative kernel memory leakage. If enough memory is consumed, the system may experience memory pressure, degraded performance, failed allocations, hung GPU-related operations, or broader availability impact. There is no indication from the provided data that this issue is being exploited in the wild or used by named threat actors.

How to fix it

Upgrade to a Linux kernel version that contains the AMDGPU fix ensuring xcc_info is freed on the amdgpu_acpi_dev_init() error path. Because no exact fixed versions were provided, use the patched kernel packages from the relevant Linux distribution or vendor advisory once available. Where immediate patching is not possible, reduce exposure by limiting untrusted local shell access, restricting workload execution on GPU-capable systems, disabling or blacklisting the amdgpu driver only where operationally acceptable, and monitoring memory pressure on affected hosts. Kernel live patching may be used if the vendor provides a live patch for this issue, but a reboot into the fixed kernel is typically required for full remediation.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version is at or above the vendor-provided fixed build and that the installed kernel source or changelog includes the AMDGPU change freeing xcc_info in amdgpu_acpi_enumerate_xcc() error paths. Validate that the host has rebooted into the fixed kernel, not merely installed it. On source-based or custom kernels, inspect the drm/amd/amdgpu ACPI code path to ensure xcc_info is released when amdgpu_acpi_dev_init() returns -ENOMEM. For exposure validation, check whether the amdgpu module is present or loaded, whether AMD GPU hardware is available, and whether untrusted local users or workloads can execute on the system.

Typical attack path

1. Obtain local access to a Linux system running an affected kernel with AMDGPU support present or loaded.
2. Identify whether the system exposes AMDGPU/ACPI initialization paths that can be repeatedly exercised.
3. Trigger AMDGPU ACPI XCC enumeration while causing or waiting for an amdgpu_acpi_dev_init() -ENOMEM failure condition.
4. Repeat the trigger to accumulate unreleased kernel memory allocations.
5. Cause system memory pressure, service instability, GPU-related failures, or broader denial of service.

How to detect it

To determine whether this issue may have been exploited, focus on host telemetry rather than network indicators. Review kernel logs, system journals, GPU driver logs, audit logs, and endpoint telemetry for repeated AMDGPU initialization activity, allocation failures, memory pressure, OOM killer events, GPU resets, and unexplained local processes repeatedly interacting with GPU devices. Useful log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd, EDR process telemetry, and GPU workload schedulers where applicable. Look for temporal correlation between local user activity, repeated access to /dev/dri devices, AMDGPU/ACPI errors, increasing unreclaimable kernel memory, and OOM or reboot events. There are no known public exploit-specific artifacts from the provided data, so detection should emphasize behavioral signs of repeated trigger attempts and resulting memory exhaustion.

• amdgpu_acpi_enumerate_xcc
• amdgpu_acpi_dev_init
• xcc_info
• amdgpu
• AMDGPU
• -ENOMEM
• Out of memory
• oom-killer
• Memory allocation failure
• page allocation failure
• invoked oom-killer
• /dev/dri/card
• /dev/dri/renderD
• drm/amdgpu

What your security team should do

• Inventory Linux systems using AMDGPU drivers, especially shared compute, workstation, VDI, GPU, and multi-user environments.
• Apply vendor kernel updates that include the AMDGPU memory-leak fix and reboot systems into the patched kernel.
• Prioritize remediation based on local-user exposure and availability requirements rather than internet exposure, since exploitation requires local access.
• Restrict untrusted local access and workload execution on affected systems until patched.
• Monitor affected systems for abnormal kernel memory growth, GPU initialization errors, allocation failures, OOM activity, and unexpected reboots.
• For custom kernels, backport the upstream fix and ensure regression testing covers AMDGPU initialization and error paths.
• Track distribution advisories for exact fixed package versions because none were supplied in the input.
• Treat active exploitation likelihood as currently low due to very low EPSS, no KEV listing, no ransomware association, and no known exploit maturity, but do not defer normal kernel patch cycles.