CVE-2026-89453

What it actually does

On Linux kernels with AMD IOMMU, iommu_call_iopf_notifier() looks up the requester with pci_get_domain_bus_and_slot(), which returns a PCI device with an elevated reference count. Neither the successful iommu_report_device_fault() path nor the abort path drops that reference, so every handled Page Request (PPR) / I/O Page Fault (IOPF) leaks a struct pci_dev reference. Repeated PPR handling pins PCI device objects, blocks unbind and hot-remove, and can exhaust kernel memory associated with PCI device tracking, producing a denial-of-service condition. This is the same ownership rule previously fixed in the older iommu_v2 ppr_notifier() path, now missing from the later IOPF notifier.

Why it matters to the business

Linux hosts that use AMD IOMMU with PRI/PASID-capable devices (commonly GPUs, NICs, and accelerators) can suffer gradual kernel resource exhaustion, failed PCI device teardown, and eventual instability or reboot. Systems without AMD IOMMU are unaffected. The issue is a local resource-leak denial of service, is not in CISA KEV, has no ransomware association, and has no known public exploit (exploit maturity: none) about 30 days after publication. Operational urgency is moderate for AMD IOMMU estates and low elsewhere.

How an attack unfolds

An attacker who can induce frequent IOMMU page-request faults on an AMD IOMMU host—typically via a PASID/PRI-capable device or a local workload that faults I/O mappings—causes the kernel IOPF notifier to take a PCI device reference on every event and never release it. Leaked references accumulate, pinning PCI device objects in memory and preventing orderly device release. Continued fault generation leads to kernel memory pressure, failed hot-remove or driver unbind, and host-level denial of service. This path does not by itself yield remote access or code execution. No named threat actors or campaigns are known to exploit it.

How to fix it

Apply the upstream Linux kernel fix that drops the PCI device reference (pci_dev_put) after handling the PPR entry in iommu_call_iopf_notifier() on both the success and abort paths. Upgrade to a distribution or stable kernel that includes that change; if a vendor kernel (for example RHEL, Ubuntu, SUSE, Debian, or cloud vendor kernels) has a backport, install that security update. No specific package versions were published with this record, so confirm the patch via vendor advisory or kernel changelog. Hosts without AMD IOMMU, or without PRI/PPR-capable devices, are not affected and can be deprioritized. There is no complete configuration workaround that preserves PPR handling without the reference drop.

How to confirm the fix worked

Confirm the running kernel includes the pci_dev_put after PPR/IOPF handling in the AMD IOMMU notifier (kernel changelog, vendor CVE mapping, or source inspection of iommu_call_iopf_notifier()). After patching, exercise or observe PPR/IOPF activity and verify PCI device reference counts do not monotonically increase (sysfs device refcount, driver unbind/hot-remove success, and kmemleak if enabled). On unpatched kernels, sustained PPR load should show growing pci_dev references and devices that cannot be released.

Typical attack path

1. Obtain local presence on a Linux host using AMD IOMMU with PPR/IOPF handling enabled
2. Cause a PASID/PRI-capable I/O device to generate a large volume of page-request / I/O page-fault events
3. Kernel iommu_call_iopf_notifier() takes a PCI device reference for each event and does not drop it
4. Leaked references pin PCI device objects and consume kernel memory over time
5. Device unbind or hot-remove fails and the host degrades into a denial-of-service state requiring reboot

How to detect it

This is a silent kernel resource leak, not a network intrusion. Hunt for AMD IOMMU PPR/IOPF activity plus symptoms of a pinned PCI device: rising reference counts on PCI devices that generate page requests, failed driver unbind or PCI hot-remove, growing kernel memory or kmemleak hits on PCI device objects, and AMD-Vi / IOMMU messages in kernel logs (dmesg, journalctl -k, persistent /var/log/kern.log or equivalent). Correlate with workloads on PASID/PRI-capable devices. There is no known exploit tooling or threat-actor TTP set; absence of alerts does not prove the leak did not occur. Compare refcount and slab trends before versus after a kernel that includes the reference drop.

What your security team should do

• Inventory Linux hosts with AMD IOMMU enabled, especially those with GPUs, NICs, or accelerators using PASID/PRI, and treat them as in-scope
• Apply vendor or upstream kernel updates that drop the PCI device reference after PPR handling; do not wait for KEV listing
• Until patched, restrict untrusted workloads that can induce I/O page faults on PRI-capable devices and avoid non-essential PCI hot-remove testing on those hosts
• Monitor kernel memory, PCI device refcounts, and failed unbind/hot-remove on AMD IOMMU systems
• Track distro security advisories for this AMD IOMMU PPR refcount leak and verify the fix is present after upgrade