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: n/a
Action: n/a
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 that is not available. 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 27, 2026 at 11:11 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest Linux kernel update that contains the bnxt driver patch identified by the commit references.
  • Reload the bnxt network driver or reboot the system to ensure the updated code is in use.
  • Continuously monitor system and network logs for indications of packet queue stalls or driver restarts to confirm that the deadlock no longer occurs.

Generated by OpenCVE AI on August 27, 2026 at 11:11 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

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

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-27T11:15:18Z

Weaknesses
  • CWE-668

    Exposure of Resource to Wrong Sphere