In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: fix TX descriptor availability check for TSO traffic
stmmac_tso_xmit() estimates the number of free TX descriptors required by
a TSO skb as:
<pre>
(skb->len - proto_hdr_len) / TSO_MAX_BUFF_SIZE + 1
</pre>
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.
CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H
CVSS Score: 7
AV:N - 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:H - 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:N - 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:N - 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:U - 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:L - 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:L - 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:H - 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.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
High |
Confidentiality Impact |
Low |
| Privileges Required |
None |
Integrity Impact |
Low |
| User Interaction |
None |
Availability Impact |
High |
AV:N - 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:H - 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:N - 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:N - 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:U - 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:L - 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:L - 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:H - 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.
CVSS 3.1