Description
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.
Published: 2026-08-26
Score: 7.5 High
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service
Action: Patch Now
AI Analysis

Impact

The bnxt network driver in the Linux kernel contains a deadlock issue that occurs when an IRQ affinity notifier is unregistered. The callback executed during unregistration holds the netdev instance lock and then attempts to cancel work under the same lock. Because the work cancellation and queue restart happen while the lock is still held, the system can enter a deadlock, halting network packet processing and potentially causing the driver to become unresponsive.

Affected Systems

Any Linux kernel build that includes the pre‑patch version of the bnxt driver is vulnerable. Systems using older kernel releases that have not yet incorporated the commit that reverses the notifier registration order and moves the queue restart to a separate service task are at risk.

Risk and Exploitability

The vulnerability has a CVSS score of 7.5 and an EPSS score of < 1%, indicating a very low probability of exploitation. It is not listed in the CISA KEV catalog, indicating no known public exploitation. Exploitation would likely require an attacker to trigger a driver unload or reload with privileged kernel access, making remote unauthenticated attacks infeasible. Nevertheless, an accidental deadlock can interrupt critical network operations, leading to service outage and impacting availability. Prompt remediation is recommended to prevent potential downtime.

Generated by OpenCVE AI on August 28, 2026 at 16:35 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest Linux kernel update that incorporates the bnxt driver patch addressing the race condition and deadlock weaknesses.
  • Reload the bnxt network driver or reboot the system to clear any lingering locks and ensure the updated code is active.
  • Monitor system and network logs for signs of lock contention or driver restarts that may indicate a remaining deadlock.

Generated by OpenCVE AI on August 28, 2026 at 16:35 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 28 Aug 2026 08:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-668

Thu, 27 Aug 2026 18:00:00 +0000


Thu, 27 Aug 2026 11:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-668

Thu, 27 Aug 2026 09:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-776

Thu, 27 Aug 2026 06:15:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}


Wed, 26 Aug 2026 17:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-776

Wed, 26 Aug 2026 14:45:00 +0000

Type Values Removed Values Added
Description 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.
Title eth: bnxt: avoid deadlock when canceling IRQ affinity notifier
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-27T05:01:06.342Z

Reserved: 2026-08-15T05:44:03.931Z

Link: CVE-2026-74745

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-26T15:16:53.387

Modified: 2026-08-27T06:17:24.793

Link: CVE-2026-74745

cve-icon Redhat

Severity : Low

Publid Date: 2026-08-26T00:00:00Z

Links: CVE-2026-74745 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-28T16:45:03Z

Weaknesses