Look up another CVE · open CVE-2026-97573 in the interactive tracker
CVE-2026-97573
bnxt_en: Handle buffer allocation failure in bnxt_rx_ring_reset()
Published 2026-09-25 (24 days ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-97573 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 | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
bnxt_rx_ring_reset() frees the ring buffers and then reallocates them, ignoring the result. bnxt_alloc_one_rx_ring() can fail in bnxt_alloc_one_tpa_info_data(), which returns -ENOMEM on the first failed allocation and leaves the remaining rxr->rx_tpa[] entries zeroed. The error isn't propagated up, so the loop in bnxt_rx_ring_reset continues and at the end the code re-enables TPA with partially unallocated rx_tpa array. This means that when the agg_id from hardware is mapped to a SW index in rxr->rx_tpa[], an uninitialized slot can be chosen which would hand a zero DMA address to the device. Fix this by falling back to a global reset, which is what the existing code already does when other functions fail, but unlike the other failure cases this particular failure has to return because TPA can't be re-enabled since the allocation failed.
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
- 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, sid, bookworm · linux-6.12Mnot 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-09-25 (24 days ago)source
- CVSS
- 8.1 high
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.60%, higher than 47.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- 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 |
|---|---|---|
| 5.10 | 5.10.271 | 52fc97cbc3ba |
| 5.10 | 5.15.222 | 40b4a7bb6b0b |
| 5.10 | 6.1.189 | af9a2bdaba0b |
| 5.10 | 6.6.158 | cfec9e7f15a5 |
| 5.10 | 6.12.111 | 1a3670b6a6b5 |
| 5.10 | 6.18.53 | 4a17c73c8379 |
| 5.10 | 7.2.7 | 8b2fd5c0aeda |
| 5.10 | 7.3 | 961e2a17c5e3 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
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
- The fixed function bnxt_rx_ring_reset() is a driver error path with no malformed input. What it damages is received data: bnxt_tpa_start() hands the NIC a stale rx_tpa[] mapping, and the NIC DMAs packet bytes sent by a remote host into that freed buffer. The remote peer supplies the data that gets written, so the vector is Network.
- AC:HAttack complexity, high
- Two things must happen together. A pre-P5 chip must hit an RX buffer error, cons mismatch or ring-monitor event that schedules the per-ring reset, and the GFP_KERNEL refill in bnxt_alloc_one_tpa_info_data() must fail under memory pressure. A remote sender cannot force that allocation failure.
- PR:NPrivileges required, none
- No authentication is involved. Any host that can send TCP traffic that the NIC aggregates with TPA (hardware GRO/LRO) fills the stale buffers and can also generate the traffic that leads to RX buffer errors.
- UI:NUser interaction, none
- No user action is needed. The reset runs from the bnxt sp_task workqueue, and the bad TPA slot is used as soon as TPA_START completions arrive.
- S:UScope, unchanged
- The corruption hits kernel memory on the host that owns the NIC, which is the same authority as the driver. No VM or other security boundary is crossed.
- C:HConfidentiality impact, high
- bnxt_free_one_tpa_info_data() clears tpa_info->data but leaves tpa_info->mapping stale. The NIC then writes into a page returned to page_pool that can be reused, and a reused buffer carrying other data can end up delivered as the next RX packet.
- I:HIntegrity impact, high
- The device DMA-writes TCP payload bytes chosen by the remote sender into freed memory (bnxt_tpa_start() puts the stale mapping into rx_bd_haddr). That is a write into memory the kernel may have reused, with attacker-chosen contents.
- A:HAvailability impact, high
- The NULL tpa_info->data is moved into rx_buf_ring by bnxt_tpa_start(). When that buffer is consumed, the RX path dereferences NULL, and on top of that the stray DMA corrupts memory, so the kernel crashes.