CVE-2026-74745 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
eth: bnxt: avoid deadlock when canceling IRQ affinity notifier
Unregistering IRQ affinity notifiers waits for the callback synchronously. bnxt takes the netdev instance lock in the notifier (to restart the queue) and cancels the work under the same lock. This may obviously deadlock.
Move the restart to the async service task. The queue restart isn't super time sensitive. Store the new TPH tag, schedule the task. Safely canceling the service task is already ironed out.
In bnxt_request_irq() the order of registering notifier, affinity and initial TPH programming has to be inverted. I think it was racy previously since user may trigger an update as soon as notifier is installed.
There's a small known gap - if pcie_tph_get_cpu_st() fails at init and the target tag is 0 we may miss programming the entry. This does not seem worth fixing, the code has skip-on-failure all over the place, anyway.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel driver for Broadcom NetXtreme-C/E network adapters contained a critical concurrency flaw within its interrupt request affinity handling logic that could lead to system deadlocks during dynamic configuration changes. The vulnerability stems from an improper locking strategy employed when unregistering IRQ affinity notifiers. Specifically, the notifier callback function is invoked synchronously and attempts to acquire the netdev instance lock in order to restart network queues. Simultaneously, the code path for canceling associated work items operates under this same lock context. This creates a circular dependency where the execution flow waits for itself or holds resources that prevent necessary cleanup operations from completing, resulting in a classic deadlock scenario that can freeze the affected network interface and potentially impact system stability depending on how deeply the kernel scheduler is blocked by the contention.
To resolve this issue, the architectural approach was modified to decouple the queue restart operation from the synchronous notifier callback. The fix involves moving the logic responsible for restarting queues into an asynchronous service task. Since the immediate restart of network queues is not time-critical in this context, deferring the action allows the system to safely manage resource release without holding locks that conflict with cancellation routines. By scheduling a deferred work item instead of executing queue restart code directly within the notifier, the driver ensures that lock acquisition order remains consistent and prevents the circular wait condition. Additionally, the initialization sequence for requesting interrupts was restructured to invert the order in which notifiers are registered relative to affinity settings and initial TPH tag programming. This change addresses a race condition where user-space triggers could occur immediately after notifier installation but before proper alignment of affinity parameters, ensuring that state transitions happen only when all prerequisites are securely established.
From a vulnerability classification perspective, this defect aligns with CWE-833, which covers Deadlocks due to improper locking mechanisms, and specifically relates to race conditions during resource initialization described under CWE-362. In the context of the MITRE ATT&CK framework for enterprise security, while not an exploit vector per se, such concurrency bugs can be leveraged in denial-of-service attacks if triggered by local users with sufficient privileges to modify network interface configurations or interrupt affinities. The operational impact includes potential service disruption where the network driver becomes unresponsive, requiring a system reboot or module reload to restore functionality. Although there is a known minor gap regarding failure handling for pcie_tph_get_cpu_st initialization that may result in missed TPH tag programming entries, this edge case was deemed low-risk due to existing skip-on-failure patterns throughout the codebase and does not constitute a primary security vulnerability requiring immediate patching beyond standard maintenance practices.