CVE-2026-64430

What it actually does

This is a Linux kernel denial-of-service flaw in the NTB EPF driver. The interrupt service routine ntb_epf_vec_isr() calls pci_irq_vector() while running in hard interrupt context. That code path can acquire a mutex through msi_get_virq(), which is not safe in atomic context and can trigger "scheduling while atomic" kernel faults. Depending on kernel configuration, workload, and hardware use of the NTB endpoint function driver, the result can be kernel warnings, IRQ handling instability, hung tasks, or a system crash/panic that affects availability. The issue is availability-only: it does not directly provide confidentiality or integrity compromise.

Why it matters to the business

Systems using the affected Linux NTB EPF functionality may become unstable or unavailable when the vulnerable interrupt path is exercised. In operational terms, this can interrupt services hosted on affected hosts, cause appliance or embedded platform downtime, and require manual recovery or reboot. The vulnerability is not currently listed in CISA KEV, is not reported as ransomware-used, has low EPSS probability at 0.0049, and has no known exploit maturity in the provided data, so priority is highest for environments that actually load or depend on the NTB EPF driver or expose NTB/PCIe endpoint functionality.

How an attack unfolds

An attacker would need a way to cause the affected NTB EPF interrupt handler to execute under conditions that reach the vulnerable code path. In a plausible end-to-end scenario, the attacker targets a system or device using the Linux NTB endpoint function driver, stimulates NTB-related interrupt activity, and causes ntb_epf_vec_isr() to call pci_irq_vector() from hardirq context. Because pci_irq_vector() can attempt to take a mutex, the kernel detects an invalid sleep/schedule attempt while atomic. Repeated or carefully timed triggering may produce kernel splats, IRQ disruption, hung execution, or a crash, resulting in denial of service. There is no indication from the provided data that public exploit code, named threat actors, ransomware campaigns, or active KEV exploitation are associated with this issue.

How to fix it

Apply a Linux kernel update from the relevant distribution, appliance vendor, or kernel source tree that includes the NTB EPF fix. The corrected implementation caches the Linux IRQ number for vector 0 when vectors are allocated and uses that cached value as the base in the interrupt handler instead of calling pci_irq_vector() from hardirq context. No exact fixed package versions were provided, so remediation should be based on vendor advisories and kernel changelogs referencing the NTB EPF hardirq/pci_irq_vector fix. If immediate patching is not possible, reduce exposure by disabling or unloading the ntb_hw_epf/NTB EPF functionality where it is not required, removing unused NTB/PCIe endpoint configurations, restricting access to peer devices or interfaces that can stimulate NTB interrupts, and scheduling maintenance windows for prompt kernel replacement on systems that depend on this driver.

How to confirm the fix worked

Confirm the running kernel includes the patch that avoids pci_irq_vector() in ntb_epf_vec_isr() and caches the vector-0 Linux IRQ during allocation. Validate package status using the operating system vendor’s kernel package metadata, advisory tooling, or source-level confirmation if using custom kernels. Check whether the NTB EPF driver is present or loaded by reviewing kernel modules and configuration, such as lsmod output for ntb_hw_epf and kernel config options related to NTB endpoint support. After remediation, exercise normal NTB functionality and confirm kernel logs no longer show "scheduling while atomic" call traces involving ntb_epf_vec_isr(), pci_irq_vector(), msi_domain_get_virq(), or ntb_hw_epf. For systems where the driver is not needed, validate mitigation by confirming the module is not loaded and cannot be autoloaded unexpectedly.

Typical attack path

1. Identify a Linux-based host, appliance, or embedded system using the NTB EPF driver or NTB/PCIe endpoint functionality.
2. Reach or influence the NTB communication path or peer device behavior sufficiently to generate NTB EPF vector interrupts.
3. Trigger interrupt activity that invokes ntb_epf_vec_isr() in hardirq context.
4. Cause the handler to call pci_irq_vector(), leading into msi_get_virq() and mutex acquisition from atomic context.
5. Induce kernel "scheduling while atomic" faults, IRQ instability, hung tasks, or a crash/panic.
6. Repeat the trigger as needed to sustain or recur service disruption.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs, persistent journald logs, serial console captures, crash dumps, and monitoring alerts for kernel oops/panic events. Relevant sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k output, dmesg history, kdump/vmcore records, hypervisor console logs for appliances, and hardware management controller event logs if they capture kernel console output. Search for "scheduling while atomic" events with call traces containing ntb_epf_vec_isr, pci_irq_vector, msi_domain_get_virq, or the ntb_hw_epf module. Correlate timestamps with NTB/PCIe endpoint activity, peer-device resets, maintenance actions, unexplained host reboots, watchdog events, cluster failovers, or availability alerts. Because this issue produces generic kernel instability rather than a unique attacker payload, detection should focus on the vulnerable call trace and repeated triggering patterns rather than assuming any single log line proves malicious exploitation.

• BUG: scheduling while atomic
• scheduling while atomic:
• ntb_epf_vec_isr
• pci_irq_vector
• msi_domain_get_virq
• msi_get_virq
• ntb_hw_epf
• __handle_irq_event_percpu
• handle_edge_irq
• schedule_preempt_disabled
• __mutex_lock_slowpath
• mutex_lock+0x
• Call trace:
• kernel panic
• Kernel panic
• hung task
• watchdog: BUG: soft lockup

What your security team should do

• Prioritize inventory first: identify Linux systems, appliances, and embedded platforms that load ntb_hw_epf or use NTB/PCIe endpoint functionality.
• Patch affected systems with vendor-provided kernel updates that include the NTB EPF interrupt-context fix.
• Treat internet-wide urgency as moderate because the issue is not KEV-listed, not known ransomware-used, has low EPSS, and has no known exploit maturity; treat operational urgency as high for systems where NTB EPF is required for production availability.
• If patching is delayed, disable or unload NTB EPF functionality where not operationally required and restrict access to NTB peer devices or management paths that can generate NTB events.
• Monitor kernel logs for "scheduling while atomic" and call traces involving ntb_epf_vec_isr, pci_irq_vector, msi_domain_get_virq, or ntb_hw_epf.
• For high-availability platforms, plan failover or maintenance procedures before applying kernel updates because remediation typically requires rebooting into a fixed kernel.
• Add this condition to vulnerability management exceptions only when the driver is absent, unloaded, and not compiled into the running kernel.