CVE-2026-43448 Linux CVE debrief

Who should care

Linux kernel maintainers, distribution security teams, and operators running NVMe PCI storage on affected kernel branches should care most. Systems that rely on NVMe timeouts, MSI-X/INTx transitions, or show IRQ-related warnings in logs deserve priority review.

Technical summary

The bug is a race in drivers/nvme/host/pci.c: nvme_poll_irqdisable() calls pci_irq_vector() twice, once before disable_irq() and again before enable_irq(). If nvme_reset_work()/nvme_dev_disable() disables the device in between, pdev->msix_enabled can change and pci_irq_vector() may return a different IRQ number. That can produce an IRQ accounting mismatch and kernel warnings. The fix is to save the IRQ number in a local variable so disable_irq() and enable_irq() operate on the same IRQ, even if IRQ vectors are freed concurrently.

Defensive priority

Medium

Recommended defensive actions

• Apply the upstream/stable Linux kernel patch referenced in NVD for CVE-2026-43448.
• Upgrade kernels to versions outside the vulnerable ranges listed by NVD.
• Review fleet kernel versions against the NVD CPE ranges for 5.7 through 6.19.9, plus 7.0 release candidates.
• Check affected hosts for IRQ imbalance warnings or NVMe timeout-related kernel log entries.
• Prioritize systems with NVMe PCI devices and active timeout handling, especially where storage availability is operationally critical.

Evidence notes

The supplied NVD record classifies this as CVSS 4.7 / Medium with AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H and CWE-362. The CVE description states the race between nvme_poll_irqdisable() and nvme_reset_work()/nvme_dev_disable(), and the included crash log shows "Unbalanced enable for IRQ 10" in __enable_irq(). NVD also lists six kernel patch references as remediation evidence. Vulnerable version ranges are taken from the supplied NVD CPE criteria.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.