CVE-2026-64430: NTB: epf: Avoid calling pci_irq_vector() from hardirq context
In the Linux kernel, the following vulnerability has been resolved:
NTB: epf: Avoid calling pciirqvector() from hardirq context
ntbepfvecisr() calls pciirqvector() in hardirq context to derive the vector number. pciirqvector() calls msigetvirq() that takes a mutex and can therefore trigger "scheduling while atomic" splats:
BUG: scheduling while atomic: kworker/u33:0/55/0x00010001 ... Call trace: ... schedule+0x38/0x110 schedulepreemptdisabled+0x28/0x50 mutexlock.constprop.0+0x848/0x908 mutexlockslowpath+0x18/0x30 mutexlock+0x4c/0x60 msidomaingetvirq+0xe8/0x138 pciirqvector+0x2c/0x60 ntbepfvecisr+0x28/0x120 [ntbhwepf] handleirqeventpercpu+0x70/0x3a8 handleirqevent+0x48/0x100 handleedgeirq+0x100/0x1c8 ...
Cache the Linux IRQ number for vector 0 when vectors are allocated and use it as a base in the ISR. Running the ISR in a threaded IRQ handler would also avoid the problem, but that would be unnecessary here.
Affected Software
Remediation
Event History
Frequently Asked Questions
Which systems are affected?
Affected systems are Linux kernel deployments using the NTB endpoint-function driver path involving ntb_hw_epf and its interrupt service routine. The issue occurs when that ISR calls pci_irq_vector() from hardirq context.
What is the practical impact?
The hardirq-context call can reach a mutex and trigger a "scheduling while atomic" condition. The supplied CVSS vector rates the impact as high availability impact, with no confidentiality or integrity impact.
Does exploitation require authentication or user interaction?
The supplied CVSS vector indicates network attack vector, low attack complexity, no privileges required, and no user interaction. The vulnerability data does not provide further exploit prerequisites.
What should be done if patching cannot happen immediately?
The provided data identifies an alternative implementation approach: handling the interrupt through a threaded IRQ handler would avoid the hardirq-context problem, though it is described as unnecessary for the fix. The available patch instead caches the Linux IRQ number for vector 0 during vector allocation and uses it as the ISR base.
How can administrators identify the issue in logs?
Affected systems may report "BUG: scheduling while atomic" messages. The shown call trace includes pci_irq_vector(), ntb_epf_vec_isr() from ntb_hw_epf, and mutex locking functions such as msi_domain_get_virq().