Look up another CVE · open CVE-2026-98052 in the interactive tracker
CVE-2026-98052
net: bcmasp: clear txcb->last before writing each descriptor
Published 2026-09-25 (24 days 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-98052 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 | 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
bcmasp_xmit() only wrote txcb->last = true for the final fragment of an SKB; non-final fragments left the field untouched. If a descriptor slot was reused while it still held a stale true from a previous SKB (possible when tx_spb_ring_full() underreported fullness), bcmasp_tx_reclaim() would see last == true mid-SKB and call dev_consume_skb_any() prematurely, freeing the sk_buff while its remaining fragments were still in flight. Unconditionally clear txcb->last before the conditional set so every descriptor slot starts from a known false state regardless of what a prior transmission left behind.
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/asp2/bcmasp_intf.c
- What this is
- BROADCOM ASP 2.0 ETHERNET DRIVERMAINTAINERS section matched on drivers/net/ethernet/broadcom/asp2/ · bcm-kernel-feedback-list@broadcom.com · Supported
Check it on the machine
grep -wE 'CONFIG_BCMASP|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.
Show whether Debian builds this, per release
Debian does not build this code in 4 releases. The build rule could not be established for 1 release, so nothing is claimed about those.
- bookworm?
- trixie, forky, sid, bookworm · linux-6.12n
- ?
- not established - no Makefile entry for the affected file
- n
- not enabled on any flavour - this release does not build the code
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switches
- CONFIG_BCMASP, 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
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.2% 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.6 | 6.6.158 | 1e213ba7cb3b |
| 6.6 | 6.12.111 | 9b26b54861ce |
| 6.6 | 6.18.53 | 47a5cecca925 |
| 6.6 | 7.2.7 | 17e6ad484dea |
| 6.6 | 7.3 | 18e5e0ec0e92 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| 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:LAttack vector, local
- The bug is in bcmasp_xmit() TX ring bookkeeping, reached via sendmsg/sendfile -> dev_queue_xmit -> bcmasp_xmit; no malformed input exists and the trigger is TX ring pressure from multi-fragment (NETIF_F_SG) SKBs, which a local user produces by flooding sockets through the bcmasp interface.
- AC:LAttack complexity, low
- The attacker controls the traffic load: flooding multi-frag SKBs makes buggy tx_spb_ring_full() let bcmasp_xmit overwrite unreclaimed slots, so non-final fragments repeatedly land in slots holding a stale txcb->last=true; no hardware state outside the attacker's control is needed.
- PR:LPrivileges required, low
- Sending TCP/UDP traffic that egresses the bcmasp netdev needs only an ordinary unprivileged local account; there is no capability check anywhere on the transmit path.
- UI:NUser interaction, none
- No victim action is involved; the attacker generates the transmit traffic entirely by themselves.
- S:UScope, unchanged
- The corruption affects kernel sk_buff/page memory in the same kernel that runs the driver; no VM or IOMMU boundary is crossed.
- C:HConfidentiality impact, high
- bcmasp_tx_reclaim() frees the skb (dev_consume_skb_any) while its later fragments are still mapped for DMA, so freed and reallocated pages can be transmitted on the wire and the stale skb is accessed again: a use-after-free with disclosure potential.
- I:HIntegrity impact, high
- When the real final fragment is reclaimed later, dev_consume_skb_any() is called a second time on the same skb, a double free/UAF of sk_buff and frag pages that could be groomed into slab corruption.
- A:HAvailability impact, high
- Double freeing the sk_buff and touching freed memory in bcmasp_tx_reclaim() from TX NAPI causes slab corruption and kernel oops/panic on the host.