CVE-2026-98592: net: spacemit: clear TX descriptor on fragment mapping failure
In the Linux kernel, the following vulnerability has been resolved:
net: spacemit: clear TX descriptor on fragment mapping failure
emactxmemmap() writes TXDESC0OWN into the ring descriptor for every slot beyond oldhead as soon as that slot's memset()'d local copy is committed with "txdescaddr = txdesc", i.e. before the buffers for that slot have necessarily all been mapped successfully. If emactxmapfrag() then fails on a later fragment, the errfreeskb path calls emacfreetxbuf() to unmap and drop the skb, but leaves the already-written descriptor memory untouched, and txring->head is never advanced past oldhead (the "txring->head = head" store is skipped by the goto).
So a slot between oldhead and the rolled-back head can be left with TXDESC0OWN set and bufferaddr{1,2} pointing at DMA mappings that emacfreetxbuf() just tore down, while software considers that slot free again. The next successful emactxmemmap() call only rebuilds oldhead itself; if the DMA engine auto-advances into the following descriptor once it finishes oldhead's packet, it will fetch that stale, already-unmapped address.
emactxcleandesc() already treats emacfreetxbuf() and clearing the descriptor as a pair when reclaiming completed descriptors; do the same in the mapping failure path.
Affected Software
Event History
Frequently Asked Questions
Which systems are relevant to this issue?
Systems using the Linux kernel's SpacemiT Ethernet MAC transmit path are relevant. The failure condition occurs when mapping a later transmit fragment fails after earlier ring descriptors have already been written.
What can happen after the failure occurs?
A transmit descriptor can remain marked as owned by DMA while its buffer addresses refer to mappings that were already unmapped. A subsequent successful transmit may allow the DMA engine to advance to and fetch the stale descriptor.