CVE-2026-89455

What it actually does

The Linux kernel PCI PLDA host-controller driver frees an IRQ domain during teardown while per-event IRQs mapped from that domain are still registered through deferred, devm-managed cleanup. irq_domain_remove() can therefore release domain internals before the later free_irq() path runs, producing a kernel use-after-free when deferred cleanup dereferences the already-freed domain. Unmapped event, INTx, and MSI mappings and unguarded chained-handler setup on invalid IRQ numbers worsen teardown races. Resulting effects are kernel memory corruption, oops or panic, and a theoretical local privilege-escalation primitive if the freed object is reallocated. The bug is confined to the plda driver path and is triggered by device/driver teardown, not by ordinary I/O on a live controller.

Why it matters to the business

Practical exposure is narrow: only hosts whose PCIe root complex is driven by the in-kernel plda driver (certain SoC/RISC-V platforms such as StarFive VisionFive-class boards) are affected. The issue is not in CISA KEV, is not associated with ransomware, and has no known public exploit (maturity none) about 30 days after publication, so fleet-wide emergency patching is generally not warranted. Residual operational risk is unplanned host outage if the device is unbound, the module is removed, or the controller is hot-removed, plus a low-probability local escalation on those same systems. Organizations should still patch affected kernels on inventory-confirmed PLDA hardware to preserve kernel integrity and avoid stability incidents during maintenance.

How an attack unfolds

An attacker needs local access on a machine that actually loads the plda PCIe host driver. They then force driver teardown (sysfs unbind, module unload, or hot-removal) so plda_pcie_irq_domain_deinit() removes the event IRQ domain while event IRQs requested via devm_request_irq() remain on the deferred-free list. After remove() returns, the deferred free_irq() walks the already-freed domain. Without further heap control this typically panics the kernel (denial of service). With the ability to reallocate the freed object, an attacker could try to corrupt IRQ-domain state for local privilege escalation. No named threat actors, campaigns, or in-the-wild use are reported; successful weaponization would require a local kernel UAF primitive and PLDA-specific hardware, which sharply limits real-world appeal.

How to fix it

Install a Linux kernel that includes the upstream plda teardown fix: free each event IRQ with devm_free_irq() before irq_domain_remove(); dispose event, INTx, and MSI mappings with irq_dispose_mapping() before their domains are removed; and call irq_set_chained_handler_and_data() only when pcie->irq, pcie->msi_irq, and pcie->intx_irq are valid (>0). Prefer distribution or vendor kernels with that commit backported; rebuild custom kernels from a tree that contains the fix. No per-package version pins were supplied for this record. Until patched, avoid unloading or rebinding the plda driver on production PLDA hosts and restrict unprivileged access to PCI unbind and module-unload interfaces. Systems that do not load this driver need no plda-specific change.

How to confirm the fix worked

Inventory whether the plda PCIe host driver is loaded or built-in (lsmod, /sys/bus/pci, kernel config). Confirm the running kernel changelog or commit list includes the PCI plda use-after-free teardown fix. On representative PLDA hardware, exercise controlled bind/unbind or reboot of the host bridge under a KASAN or debug kernel if available and verify there is no use-after-free, oops, or irqdomain warning in dmesg during remove. On non-PLDA fleets, absence of the plda driver is sufficient evidence of non-exposure.

Typical attack path

1. Obtain local access on a host whose PCIe host bridge is bound to the Linux plda driver
2. Confirm the plda device/driver is present and identify a teardown trigger (unbind, module removal, or hot-unplug)
3. Induce driver remove so the event IRQ domain is destroyed while devm-managed event IRQs are still pending deferred free
4. Cause the deferred free_irq() path to run against the already-freed domain
5. Observe kernel oops/panic, or attempt to reallocate the freed domain object to turn the use-after-free into memory corruption
6. Use resulting corruption, if achieved, for denial of service or attempted local privilege escalation

How to detect it

Exploitation, if it occurred, would be local and would almost always leave a kernel oops, panic, or KASAN use-after-free at driver teardown rather than a network artifact. Review persistent kernel logs (journalctl --dmesg, kern.log, pstore, vmcore/crash dumps) around PCI host remove, unbind, or module unload. Search for plda driver symbols and irq-domain teardown on the stack (plda_pcie_irq_domain_deinit, irq_domain_remove, free_irq, devres). Correlate with administrative actions that unbind the PCI device or remove the module. Lack of logs after a hard panic does not prove the host was clean. No threat-actor TTPs or ransomware playbooks are associated with this CVE, so do not expect distinctive C2 or file-drop indicators.

• plda_pcie_irq_domain_deinit
• plda_init_interrupts
• PCI: plda
• irq_domain_remove
• KASAN: use-after-free
• Unable to handle kernel NULL pointer dereference
• RIP:.*plda_
• Call Trace:.*irq_dispose_mapping
• Call Trace:.*free_irq
• echo .*unbind.*> /sys/bus/pci/drivers/

What your security team should do

• Patch Linux kernels on inventory-confirmed PLDA/SoC hosts first; do not treat this as a generic all-Linux KEV-style emergency
• Identify systems that actually load the plda driver so effort is not wasted on unrelated PCI stacks
• Until patched, prevent unprivileged PCI unbind and kernel-module unload on those hosts
• Watch kernel logs and crash dumps for plda/irq-domain oopses around device removal; there is no network exploit path to hunt
• Reassess only if exploit maturity or KEV status changes; current evidence does not justify ransomware or mass-outbreak response