CVE-2026-74745

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: bnxt: avoid deadlock when canceling IRQ affinity notifier<br /> <br /> Unregistering IRQ affinity notifiers waits for the callback synchronously.<br /> bnxt takes the netdev instance lock in the notifier (to restart the queue)<br /> and cancels the work under the same lock. This may obviously deadlock.<br /> <br /> Move the restart to the async service task. The queue restart isn&amp;#39;t<br /> super time sensitive. Store the new TPH tag, schedule the task.<br /> Safely canceling the service task is already ironed out.<br /> <br /> In bnxt_request_irq() the order of registering notifier, affinity and<br /> initial TPH programming has to be inverted. I think it was racy<br /> previously since user may trigger an update as soon as notifier<br /> is installed.<br /> <br /> There&amp;#39;s a small known gap - if pcie_tph_get_cpu_st() fails at init<br /> and the target tag is 0 we may miss programming the entry.<br /> This does not seem worth fixing, the code has skip-on-failure<br /> all over the place, anyway.