CVE-2024-53058

net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data

MEDIUM
5.5
CVSS Score
Published: November 19, 2024 at 05:19 PM UTC
Updated: August 5, 2026 at 12:05 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.5
Exploit prediction
EPSS 0.6%
SSVC
No known exploit

Description

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

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

4.7 ≤ v < 5.15.1714.7 ≤ v < 6.1.1164.7 ≤ v < 6.11.74.7 ≤ v < 6.124.7 ≤ v < 6.6.605.16 ≤ v < 6.1.1166.2 ≤ v < 6.6.606.7 ≤ v < 6.11.76.12 rc16.12 rc26.12 rc36.12 rc46.12 rc5f748be531d7012c456b97f66091d86b3675c5fef
Vendor states this is fixed in 58d23d835eb498336716cca55b5714191a309286 (fixed)
Vendor states this is fixed in 66600fac7a984dea4ae095411f644770b2561ede (fixed)
Vendor states this is fixed in 7c9c26e37542486e34d767505e842f48f29c3f6 (fixed)
Vendor states this is fixed in a3ff23f7c3f0e13f718900803e090fd3997d6bc9 (fixed)
Vendor states this is fixed in ece593fc9c00741b682869d3f3dc584d37b7c9df (fixed)
Vendor states this is fixed in 4.7 (unaffected)
Vendor states this is fixed in 5.15.171 (unaffected)
Vendor states this is fixed in 6.1.116 (unaffected)
Vendor states this is fixed in 6.11.7 (unaffected)
Vendor states this is fixed in 6.12 (unaffected)
Vendor states this is fixed in 6.6.60 (unaffected)

References (6)

Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/07c9c26e37542486e34d767505e842f48f29c3f6
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/58d23d835eb498336716cca55b5714191a309286
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/66600fac7a984dea4ae095411f644770b2561ede
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/a3ff23f7c3f0e13f718900803e090fd3997d6bc9
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/ece593fc9c00741b682869d3f3dc584d37b7c9df
Source: af854a3a-2127-422b-91ae-364da2661108
https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

5.5MEDIUMCISA-ADP
Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusMODIFIED
CWE
NVD-CWE-noinfo

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card