Look up another CVE · open CVE-2026-74745 in the interactive tracker
CVE-2026-74745
eth: bnxt: avoid deadlock when canceling IRQ affinity notifier
Published 2026-08-26 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-74745 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.10-1 | Update the kernel and reboot. Fixed in 7.1.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.10-1 | Update the kernel and reboot. Fixed in 7.1.10-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/ethernet/broadcom/bnxt/bnxt.c
drivers/net/ethernet/broadcom/bnxt/bnxt.h
- What this is
- BROADCOM BNXT_EN 50 GIGABIT ETHERNET DRIVERMAINTAINERS section matched on drivers/net/ethernet/broadcom/bnxt/ · netdev@vger.kernel.org · Maintained
- Kernel module
- bnxt_en
Check it on the machine
grep -wE 'CONFIG_BNXT|CONFIG_ETHERNET|CONFIG_NET_VENDOR_BROADCOM' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w bnxt_enPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_BNXT, CONFIG_ETHERNET, CONFIG_NET_VENDOR_BROADCOM
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-26 (2 months ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.61%, higher than 48.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.15 | 6.18.57 | d10e73572cda |
| 6.15 | 7.1.10 | 8b1118fc5a5d |
| 6.15 | 7.2 | 51e96fa31f7e |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- Remote traffic can stall bnxt TX queues and fire netdev watchdog bnxt_tx_timeout(), driving bnxt_reset()/bnxt_close_nic() to bnxt_free_irq() under RTNL and netdev_lock on internet-facing Broadcom NetXtreme cloud/DC servers without local syscall access.
- AC:LAttack complexity, low
- On TPH-capable bnxt NICs the affinity notifier is auto-registered; an attacker can repeatedly provoke TX-timeout teardown while system irqbalance or CPU hotplug migrates MSIX affinity, controlling both deadlock sides without uncontrollable memory layout or rare victim state.
- PR:NPrivileges required, none
- Exploitation requires only sending traffic that triggers netdev TX-timeout recovery on an already-up bnxt interface; concurrent IRQ affinity updates are performed by irqbalance/hotplug without attacker credentials, CAP_NET_ADMIN, or init-namespace root.
- UI:NUser interaction, none
- No victim interaction is needed beyond normal operation of a bnxt uplink on a host running irqbalance; the attacker only sends traffic to provoke watchdog reset coincident with kernel-driven affinity migration.
- S:UScope, unchanged
- The netdev_lock/workqueue inversion deadlocks NIC teardown inside the host kernel and does not cross VM, container, or IOMMU boundaries to another security authority.
- C:NConfidentiality impact, none
- This is a pure locking deadlock between irq_set_affinity_notifier cancel_work_sync and bnxt_irq_affinity_notify; there is no memory corruption, use-after-free, out-of-bounds access, or information disclosure.
- I:NIntegrity impact, none
- The flaw does not modify attacker-controlled data or achieve code execution; it only wedges threads waiting on netdev_lock during IRQ notifier cancellation without altering kernel memory contents.
- A:HAvailability impact, high
- Deadlock during bnxt_close_nic/bnxt_free_irq leaves RTNL and netdev_lock held indefinitely, freezing host-wide network reconfiguration and the affected interface until reboot, matching CVSS guidance for kernel deadlocks.