Look up another CVE · open CVE-2026-97953 in the interactive tracker
CVE-2026-97953
net: stmmac: fix TX descriptor availability check for TSO traffic
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-97953 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| 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
stmmac_tso_xmit() estimates the number of free TX descriptors required by a TSO skb as: (skb->len - proto_hdr_len) / TSO_MAX_BUFF_SIZE + 1 which assumes the payload is split into TSO_MAX_BUFF_SIZE chunks. This underestimates the descriptors actually consumed by stmmac_tso_allocator(), since each fragment is mapped individually and so it needs at least one descriptor regardless of its size. Moreover, one descriptor is used for the L2/L3/L4 headers and, when the MSS changes, one more is consumed for the MSS context descriptor. For a highly fragmented TSO skb the check can therefore pass even when the ring has too few free slots. stmmac_tso_allocator() then writes past the available descriptors, overwriting descriptors still owned by the DMA engine, corrupting the TX ring. Add stmmac_tso_get_num_desc() to compute the exact number of descriptors needed for the header, the linear payload and each fragment, plus the MSS context descriptor when required, and use it in the availability check.
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/stmicro/stmmac/stmmac_main.c
- What this is
- STMMAC ETHERNET DRIVERMAINTAINERS section matched on drivers/net/ethernet/stmicro/stmmac/ · netdev@vger.kernel.org · Maintained
- Kernel module
- stmmac
Check it on the machine
grep -wE 'CONFIG_ETHERNET|CONFIG_NET_VENDOR_STMICRO|CONFIG_STMMAC_ETH' /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 stmmacPrints 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, ppc64el/powerpc64le
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, s390x/s390x
- bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_ETHERNET, CONFIG_NET_VENDOR_STMICRO, CONFIG_STMMAC_ETH
- 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.0 high
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.41%, higher than 33.7% 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 |
|---|---|---|
| 4.7 | 6.12.111 | ffa6d2481bc1 |
| 4.7 | 6.18.53 | c28175220f80 |
| 4.7 | 7.2.7 | 65820fc743ea |
| 4.7 | 7.3 | 5e38d732ec67 |
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:NAttack vector, network
- On a stmmac router or bridge, a remote sender's TCP segments are merged by GRO (payload left in the linear head plus up to 17 fragments) and forwarded to stmmac_tso_xmit(). Flows with different segment sizes also force an MSS context descriptor. The old check, (skb->len - proto_hdr_len)/TSO_MAX_BUFF_SIZE + 1, asks for 1 descriptor where 20 are written, so the remote packets themselves shape the skb that overruns the ring.
- AC:HAttack complexity, high
- The overrun happens only when the queue is awake with stmmac_tx_avail() just under the real count (about 19 free for a 20-descriptor skb), and remotely it also needs the host to forward traffic and the ingress NIC to keep payload in the linear head. The attacker can flood toward that window and retry but cannot set ring occupancy exactly, and other traffic changes it.
- PR:NPrivileges required, none
- No authentication is involved: GRO merging and IP forwarding/bridging to the stmmac egress port accept any sender's packets, and TSO is used for any forwarded GSO skb that passes stmmac_tso_valid_packet() (gso_size >= 64).
- UI:NUser interaction, none
- Nobody on the target has to do anything. The attacker's own flows produce the fragmented GSO skbs and fill the TX ring during normal forwarding.
- S:UScope, unchanged
- The damage stays inside the host kernel's stmmac TX ring and its bookkeeping (tx_skbuff[], tx_skbuff_dma[]). No VM, IOMMU or sandbox boundary is crossed.
- C:LConfidentiality impact, low
- Once cur_tx catches up with dirty_tx, later sends overwrite descriptors the DMA engine still owns. Frames can then carry the wrong buffers or buffers already released by stmmac_tx_clean(), a limited, uncontrolled leak of data from other flows or memory. It gives no arbitrary read.
- I:LIntegrity impact, low
- Overwritten live descriptors garble other flows' outgoing frames (payload chunks swapped into the wrong TSO frame) and corrupt the driver's per-entry skb and DMA bookkeeping. The device only reads memory for TX, so there is no general kernel memory write.
- A:HAvailability impact, high
- After the extra write makes the ring look empty (cur_tx == dirty_tx), completed skbs and DMA mappings are never reclaimed and later sends overwrite in-flight descriptors, triggering WARN_ONs, a TX stall, the netdev watchdog timeout and an interface reset. The attacker can repeat this at will.