CVE-2026-43448

What it actually does

This is a race condition in the Linux kernel NVMe PCI driver, specifically in nvme_poll_irqdisable(). The vulnerable code can call disable_irq() using one IRQ vector and later call enable_irq() using a different IRQ vector if a concurrent NVMe reset disables MSI-X in between those operations. That imbalance can trigger kernel IRQ management warnings and may destabilize NVMe I/O handling. The practical security impact is availability loss: under the right timing conditions, a local low-privileged attacker or workload capable of repeatedly stressing NVMe I/O and reset/timeout paths may cause kernel warnings, device instability, I/O disruption, or potentially a system crash. The flaw does not provide a direct confidentiality or integrity impact based on the available details.

Why it matters to the business

Systems using affected Linux kernels with NVMe PCI storage may experience storage instability or host availability issues if the race is triggered. For business operations, this can mean application outages, degraded service performance, failed jobs, filesystem or storage interruptions, and possible node reboots or crashes in environments that rely on local NVMe-backed workloads. The risk is lower than remotely exploitable vulnerabilities because exploitation requires local access and precise timing, EPSS is very low, and it is not listed in CISA KEV; however, production systems with untrusted local users, shared compute, CI runners, containers with access to storage stress paths, or high NVMe I/O churn should still prioritize kernel updates.

How an attack unfolds

An attacker first obtains local code execution with low privileges on a Linux system using an affected kernel and NVMe PCI storage. They then generate conditions that increase the likelihood of NVMe request timeouts, reset work, and polling activity occurring concurrently. The vulnerable path occurs when nvme_poll_irqdisable() disables an IRQ derived from pci_irq_vector(), while another kernel worker concurrently executes NVMe reset/disable logic and clears MSI-X state. When nvme_poll_irqdisable() later re-queries pci_irq_vector(), it may receive a different IRQ number and call enable_irq() on an IRQ that was not previously disabled by that path. This can produce an "Unbalanced enable for IRQ" kernel warning and may destabilize IRQ accounting for the device. Repeated triggering can result in NVMe I/O disruption or broader host availability impact. There is no indication that this vulnerability enables privilege escalation, data theft, or remote compromise by itself.

How to fix it

Apply a Linux kernel update from the operating system or kernel vendor that includes the nvme-pci fix for the race in nvme_poll_irqdisable(). The corrected implementation stores the IRQ number in a local variable so disable_irq() and enable_irq() operate on the same IRQ value even if NVMe reset logic changes MSI-X state concurrently. No exact fixed package versions were provided in the input, so use the latest vendor-supported kernel for the affected distribution or kernel branch and verify that the relevant NVMe PCI driver patch is included. If immediate patching is not possible, reduce exposure by limiting local shell access to trusted users, restricting untrusted workloads on systems with NVMe devices, avoiding unnecessary direct hardware access from containers or guests, and monitoring for NVMe timeout/reset instability. For high-availability services, schedule rolling kernel updates and reboots to avoid extended downtime.

How to confirm the fix worked

Confirm exposure by checking whether systems run an affected Linux kernel build and use the NVMe PCI driver. Validate remediation by confirming the installed kernel package or running kernel includes the vendor fix for the nvme_poll_irqdisable() IRQ race, then reboot into the patched kernel. After remediation, review kernel logs during NVMe stress or normal production load and confirm that warnings such as "Unbalanced enable for IRQ" no longer occur in the NVMe timeout/reset path. Useful validation commands include checking the running kernel with uname -a, checking loaded NVMe modules with lsmod or modinfo nvme and modinfo nvme_core, reviewing package changelogs for the NVMe PCI patch, and searching dmesg/journal logs for NVMe timeout, reset, and IRQ warning messages.

Typical attack path

1. Gain local access to a Linux system running an affected kernel with NVMe PCI storage.
2. Run workloads that heavily stress NVMe I/O queues and increase request timeout activity.
3. Attempt to induce or coincide with NVMe reset/disable behavior while polling IRQ disable logic is active.
4. Trigger the race where disable_irq() and enable_irq() operate on different IRQ numbers because MSI-X state changes concurrently.
5. Cause kernel IRQ warnings, NVMe device instability, I/O disruption, or potential system availability degradation.

How to detect it

To determine whether this issue may have already been triggered, review kernel logs from dmesg, journald, syslog, kern.log, crash dumps, and monitoring telemetry for IRQ imbalance warnings associated with NVMe timeout or reset activity. Key artifacts include "Unbalanced enable for IRQ" warnings, stack traces involving __enable_irq(), enable_irq(), nvme_poll_irqdisable(), nvme_timeout(), nvme_reset_work(), nvme_dev_disable(), blk_mq_timeout_work(), and repeated NVMe controller resets or I/O timeouts. Because this vulnerability is a race condition and not known to drop files, open network connections, create users, or leave conventional malware indicators, detection is primarily behavioral and log-based. Investigate any correlated local workload activity around the same time, especially storage stress tools, high-rate NVMe I/O, repeated device resets, or containers/jobs that triggered abnormal block-layer timeout activity. Absence of these log messages does not prove the system was never exposed, but their presence on an affected kernel is a strong signal that the vulnerable condition or a closely related NVMe IRQ handling fault occurred.

• Unbalanced enable for IRQ
• WARNING: kernel/irq/manage.c:753
• __enable_irq+
• enable_irq+
• nvme_poll_irqdisable
• nvme_timeout
• nvme_reset_work
• nvme_dev_disable
• blk_mq_timeout_work
• blk_mq_rq_timed_out
• blk_mq_handle_expired
• Workqueue: kblockd blk_mq_timeout_work
• drivers/nvme/host/pci.c
• pdev->msix_enabled = 0
• nvme-pci
• I/O timeout
• reset controller
• Abort status

What your security team should do

• Prioritize kernel updates on systems that combine affected Linux kernels, NVMe PCI storage, and untrusted or semi-trusted local workloads.
• Inventory Linux hosts using NVMe PCI devices and correlate them with running kernel versions and vendor patch status.
• Monitor kernel logs for IRQ imbalance warnings and NVMe timeout/reset activity, especially on systems reporting unexplained I/O stalls or reboots.
• Restrict local access and untrusted workload execution on vulnerable systems until patched, particularly in shared compute, CI/CD, hosting, and multi-user environments.
• Do not treat this as a likely remote compromise vector; focus response on availability risk, kernel stability, and operational resilience.
• After patching, reboot systems into the fixed kernel and verify that older vulnerable kernels are not still selected by the bootloader.
• For critical services, use rolling updates, workload evacuation, and storage redundancy to reduce outage risk during remediation.