CVE-2026-43298

What it actually does

This flaw is a local availability issue in the Linux kernel AMDGPU DRM driver. On AMDGPU virtual functions, VCNv2.5 does not enable the VCN poison interrupt, but the driver deinitialization path still attempts to release it. That invalid IRQ release path triggers a kernel warning and call trace in amdgpu_irq_put() during VCN hardware finalization, such as during AMDGPU module removal, device reset, driver unload, VM teardown, or GPU virtual function cleanup. In systems configured to panic on kernel warnings, or where GPU VF teardown is frequent, this can escalate from a warning into a host or guest service interruption.

Why it matters to the business

Affected Linux systems using AMDGPU virtual functions may experience GPU-driver instability, noisy kernel logs, failed cleanup operations, or downtime if kernel warnings are treated as fatal. The practical risk is highest for virtualization, VDI, GPU sharing, CI, cloud, or compute environments where AMD GPU virtual functions are attached and detached regularly. The vulnerability has low observed exploitation likelihood based on the provided EPSS value, is not listed in CISA KEV, and has no known public exploit maturity in the provided data, so remediation should be handled through normal kernel/driver maintenance unless the environment depends heavily on AMDGPU VF availability.

How an attack unfolds

An attacker needs local access with enough privilege to trigger AMDGPU VF teardown or driver deinitialization paths, such as unloading the amdgpu module, detaching a passed-through GPU virtual function, causing a VF reset, or otherwise initiating cleanup of the VCN hardware block. During cleanup, the vulnerable driver calls the VCN poison IRQ release path even though that interrupt was never enabled for the VF. The invalid release reaches amdgpu_irq_put(), generates a kernel WARNING and call trace, and may disrupt the GPU driver. If the system is configured with panic_on_warn or equivalent hardening/diagnostic settings, the warning can cause a kernel panic, resulting in a local denial of service.

How to fix it

Apply a Linux kernel or vendor driver update that includes the AMDGPU fix to skip VCN poison IRQ release on virtual functions. Because no exact fixed version was provided, track the fix by patch subject: "drm/amdgpu: Skip vcn poison irq release on VF" and install the relevant updated kernel from the Linux distribution, hardware vendor, or AMDGPU driver package. Where immediate patching is not possible, reduce exposure by limiting local administrative access, restricting who can unload kernel modules or manage GPU passthrough, avoiding unnecessary AMDGPU VF detach/reset operations, and reviewing whether kernel.panic_on_warn is appropriate for systems where availability is more important than crash-on-warning diagnostics. Systems not using AMDGPU, AMD GPU virtual functions, or VCNv2.5-related VF configurations are unlikely to be exposed to this specific issue.

How to confirm the fix worked

Confirm the running kernel or AMDGPU driver package contains the fix by checking distribution advisories, kernel changelogs, package changelogs, or source history for the patch titled "drm/amdgpu: Skip vcn poison irq release on VF". On patched test systems with AMDGPU VF configurations, exercise a controlled VF detach, VM shutdown, GPU reset, or amdgpu module unload workflow and verify that the kernel log no longer records WARNING traces from amdgpu_irq_put() or vcn_v2_5_hw_fini(). Also verify that the running kernel after reboot is the updated version, since installing a kernel package without rebooting leaves the vulnerable driver active.

Typical attack path

1. Obtain local access to a Linux system using the AMDGPU kernel driver with an affected AMD GPU virtual function configuration.
2. Gain sufficient privileges or operational control to trigger GPU VF deinitialization, device reset, driver unload, or module removal.
3. Initiate the vulnerable cleanup path, for example by detaching the VF, resetting the GPU function, stopping a VM using the VF, or unloading the amdgpu module.
4. The AMDGPU VCNv2.5 finalization path attempts to release a VCN poison IRQ that was not enabled on the virtual function.
5. The kernel logs a WARNING and call trace in amdgpu_irq_put(); systems configured to panic on warnings may crash or become unavailable.

How to detect it

This issue is most likely to leave evidence in kernel logs rather than application logs. Review dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, hypervisor host logs, and GPU/VM lifecycle orchestration logs for AMDGPU warnings during VF detach, VM shutdown, GPU reset, or amdgpu module unload. Look for call traces that include amdgpu_irq_put() and vcn_v2_5_hw_fini(), especially near messages such as "clean up the vf2pf work item" or commands/processes such as rmmod. Correlate timestamps with administrative actions, VM lifecycle events, PCI device detach/reset operations, and unexpected host or guest reboots. For systems configured with panic_on_warn, also check crash dumps, kdump/vmcore artifacts, and reboot history for kernel panics preceded by AMDGPU WARNING traces. There are no network indicators for this local driver issue.

• WARNING: CPU:
• amdgpu_irq_put
• vcn_v2_5_hw_fini
• [drm] clean up the vf2pf work item
• Comm: rmmod
• Modules linked in: amdgpu
• amdgpu(OE-)
• drm/amdgpu
• VCN poison irq
• kernel.panic_on_warn
• panic_on_warn
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory Linux systems using AMDGPU, especially virtualization hosts, VDI platforms, GPU passthrough systems, and compute nodes using AMD GPU virtual functions.
• Prioritize patching systems where AMDGPU VFs are operationally important or where kernel.panic_on_warn is enabled, because a warning may become a full system outage.
• Apply the vendor kernel or AMDGPU driver update that includes the fix for skipping VCN poison IRQ release on VFs, then reboot into the updated kernel.
• Restrict local administrative operations that can unload amdgpu, reset GPU devices, or detach GPU virtual functions until affected systems are patched.
• Monitor kernel logs for amdgpu_irq_put(), vcn_v2_5_hw_fini(), and related call traces to identify systems already hitting the vulnerable path.
• If availability is critical, evaluate whether panic-on-warning settings are necessary on affected GPU hosts while awaiting maintenance windows.