CVE-2026-64430

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NTB: epf: Avoid calling pci_irq_vector() from hardirq context<br /> <br /> ntb_epf_vec_isr() calls pci_irq_vector() in hardirq context to derive<br /> the vector number. pci_irq_vector() calls msi_get_virq() that takes a<br /> mutex and can therefore trigger "scheduling while atomic" splats:<br /> <br /> BUG: scheduling while atomic: kworker/u33:0/55/0x00010001<br /> ...<br /> Call trace:<br /> ...<br /> schedule+0x38/0x110<br /> schedule_preempt_disabled+0x28/0x50<br /> __mutex_lock.constprop.0+0x848/0x908<br /> __mutex_lock_slowpath+0x18/0x30<br /> mutex_lock+0x4c/0x60<br /> msi_domain_get_virq+0xe8/0x138<br /> pci_irq_vector+0x2c/0x60<br /> ntb_epf_vec_isr+0x28/0x120 [ntb_hw_epf]<br /> __handle_irq_event_percpu+0x70/0x3a8<br /> handle_irq_event+0x48/0x100<br /> handle_edge_irq+0x100/0x1c8<br /> ...<br /> <br /> Cache the Linux IRQ number for vector 0 when vectors are allocated and<br /> use it as a base in the ISR. Running the ISR in a threaded IRQ handler<br /> would also avoid the problem, but that would be unnecessary here.