CVE-2026-89454

What it actually does

In the Linux kernel PCI PLDA host-controller path, plda_init_interrupts() creates IRQ domains and mappings but does not unwind them if a later step fails (platform_get_irq() or irq_create_mapping()). Failed init therefore leaks IRQ domain objects and can leave port->intx_irq initialized after a mapping failure, consuming kernel interrupt resources and risking interrupt-subsystem exhaustion or instability (denial of service) if that error path is hit repeatedly.

Why it matters to the business

Practical risk is limited to Linux systems using PLDA-based PCI controllers and is a local resource-leak denial of service, not remote code execution. The issue is not in CISA KEV, has no ransomware association, and exploit maturity is none about 30 days after publication, so most organizations face low operational urgency unless they run affected PLDA PCI hardware and see repeated probe or interrupt-init failures.

How an attack unfolds

This is an error-path resource leak, not a memory-corruption or remote primitive. A local actor who can cause PLDA PCI interrupt initialization to fail after IRQ domains are created—such as by inducing platform IRQ lookup or mapping failures during host-controller probe—can leave domains and mappings allocated. Repeating that failure path can exhaust IRQ-domain or mapping capacity and degrade interrupt handling. No public exploit, named threat actor, or in-the-wild campaign is associated with this issue.

How to fix it

Apply a Linux kernel update that includes the PCI plda fix: error paths in plda_init_interrupts() must call plda_pcie_irq_domain_deinit() so IRQ domains and intx/msi mappings are disposed before domains are removed. Prefer distro or vendor kernel packages that contain this change; rebuild custom kernels from a tree that has the deinit-on-error unwind. No specific upstream version numbers were supplied with this record—confirm the patch is present in the kernel you ship. There is no complete configuration-only workaround; reducing unnecessary PLDA probe retries only lowers leak frequency.

How to confirm the fix worked

Confirm the running kernel changelog or source contains the plda_init_interrupts() error-path call to plda_pcie_irq_domain_deinit() and that mapping-failure paths no longer leave intx_irq set without teardown. After update, boot on PLDA PCI hardware (or a representative image), exercise host-controller probe including simulated IRQ get/mapping failures in a lab, and verify no leftover IRQ domains or mappings and no growing irq_domain / proc interrupt anomalies across repeated failed inits.

Typical attack path

1. Obtain local or equivalent access on a Linux system that uses a PLDA PCI host controller
2. Cause plda_init_interrupts() to fail after IRQ domains are created (IRQ lookup or mapping failure during probe)
3. Repeat the failed init path so leaked IRQ domains and mappings accumulate
4. Degrade or exhaust kernel interrupt resources, producing a local denial of service

How to detect it

This leak leaves no reliable network or malware IOC and is not known to be exploited. To see whether the error path already ran, review kernel logs (dmesg, journalctl -k) around PCI/PLDA host-controller probe for interrupt-init or mapping failures, correlate with driver load of the plda PCI host driver, and look for unexplained growth in IRQ domains or interrupt mapping exhaustion after failed probes. Absence of those logs does not prove the bug was never hit; presence indicates the leaky path may have run, not that an attacker caused it.

What your security team should do

• Inventory Linux hosts for PLDA PCI host-controller usage (PCI plda driver) and prioritize those for kernel updates
• Patch to a kernel that unwinds IRQ domains on plda_init_interrupts() failure; treat as routine DoS hygiene, not emergency KEV response
• Watch dmesg/journal for PLDA/PCI interrupt-init failures and IRQ-domain pressure on remaining unpatched systems
• Do not invest in exploit hunting or emergency hunting playbooks; exploit maturity is none and there is no KEV or ransomware signal