CVE-2024-53058: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data
In case the non-paged data of a SKB carries protocol header and protocol
payload to be transmitted on a certain platform that the DMA AXI address
width is configured to 40-bit/48-bit, or the size of the non-paged data
is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI
address width is configured to 32-bit, then this SKB requires at least
two DMA transmit descriptors to serve it.
For example, three descriptors are allocated to split one DMA buffer
mapped from one piece of non-paged data:
dma_desc[N + 0],
dma_desc[N + 1],
dma_desc[N + 2].
Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold
extra information to be reused in stmmac_tx_clean():
tx_q->tx_skbuff_dma[N + 0],
tx_q->tx_skbuff_dma[N + 1],
tx_q->tx_skbuff_dma[N + 2].
Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer
address returned by DMA mapping call. stmmac_tx_clean() will try to
unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf
is a valid buffer address.
The expected behavior that saves DMA buffer address of this non-paged
data to tx_q->tx_skbuff_dma[entry].buf is:
tx_q->tx_skbuff_dma[N + 0].buf = NULL;
tx_q->tx_skbuff_dma[N + 1].buf = NULL;
tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single();
Unfortunately, the current code misbehaves like this:
tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single();
tx_q->tx_skbuff_dma[N + 1].buf = NULL;
tx_q->tx_skbuff_dma[N + 2].buf = NULL;
On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the
DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address
obviously, then the DMA buffer will be unmapped immediately.
There may be a rare case that the DMA engine does not finish the
pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go
horribly wrong, DMA is going to access a unmapped/unreferenced memory
region, corrupted data will be transmited or iommu fault will be
triggered :(
In contrast, the for-loop that maps SKB fragments behaves perfectly
as expected, and that is how the driver should do for both non-paged
data and paged frags actually.
This patch corrects DMA map/unmap sequences by fixing the array index
for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address.
Tested and verified on DWXGMAC CORE 3.20a
Security readout for executives and security teams
Plain-English summary
A flaw in the Linux stmmac Ethernet driver can release a DMA mapping before hardware finishes transmitting from it. Under specific TSO and hardware conditions, this may corrupt transmitted data or trigger an IOMMU fault, potentially disrupting availability. The supplied record rates it critical, but exposure depends on the driver, configuration, hardware, and traffic path.
Executive priority
Prioritize confirmation and patching for production appliances, embedded systems, and network-facing infrastructure using stmmac with TSO. Do not assume every Linux host is exposed. Escalate systems showing IOMMU faults or transmission corruption, while tracking vendor packages because the supplied evidence does not identify a universal configuration workaround.
Technical view
When non-paged SKB data spans multiple transmit descriptors, stmmac records the DMA address against the first descriptor instead of the last. Cleanup may therefore unmap the buffer while later descriptors still reference it. The resolved code corrects the tx_skbuff_dma array index. The condition involves TSO and particular buffer-size or DMA AXI address-width scenarios.
Likely exposure
Likely exposure is limited to Linux systems using the stmmac driver and TSO where non-paged SKB data requires multiple DMA descriptors. The supplied version data is ambiguous when flattened, so determine status using the exact kernel build, vendor advisory, and referenced stable commits rather than version strings alone.
Exploitation context
The supplied sources provide no evidence of active exploitation, and the CVE is not listed as KEV in the bundle. They describe possible corrupted transmissions and IOMMU faults, but do not establish reliable remote code execution or a demonstrated attack. Treat network reachability in the CVSS vector cautiously when prioritizing individual systems.
Researcher notes
The failure is an unbalanced DMA map/unmap lifetime caused by associating one mapped non-paged buffer with the wrong descriptor entry. A race exists when the first descriptor completes before subsequent descriptors. Testing cited in the description covered DWXGMAC CORE 3.20a; broader hardware reproducibility and attacker control are not established by the bundle.
Mitigation direction
Upgrade to a vendor-supported kernel containing the referenced stable fix.
Confirm custom kernels include the DMA bookkeeping index correction.
Review Linux distribution advisories for the exact kernel package and platform.
If patching is delayed, seek vendor-approved mitigations; none are named in the supplied sources.
Validation and detection
Identify systems using the stmmac Ethernet driver and record exact kernel builds.
Determine whether TSO is enabled on affected stmmac interfaces.
Check hardware documentation for 32-bit, 40-bit, or 48-bit DMA AXI addressing.
Verify the applicable stable fix is present in source or vendor package metadata.
Review kernel logs for IOMMU faults and investigate unexplained transmitted-data corruption.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-53058 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.