LiveActive security incident?Get immediate response
CVE Record

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

CriticalCVSS 9.4Not KEV-listedUpdated
Glexia's TakeAutomated analysiscritical

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.
Prepared
Confidence
high
Sources
8

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.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Critical
CVSS
9.4 (3.1)
Known Exploited
No
Published

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H

Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

2CVSS vectors
3Timeline events
2ADP providers
7Source links

SSVC decision data

CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: partial

CVSS vector scores

2 official scores

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.

ScoreVersionSeverityVectorExploitImpactSource
9.4CVSS 3.1CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H3.95.5Linux
5.5CVSS 3.1MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H1.83.6CISA-ADP

Vulnerability scoring details

Base CVSS 3.1 score

9.4Critical
CVSS 3.1 vector shape for CVE-2024-53058Attack VectorAttack ComplexityPrivileges RequiredUser InteractionScopeConfidentiality ImpactIntegrity ImpactAvailability Impact

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H

Attack Vector
NetworkAdjacentLocalPhysical
Attack Complexity
LowHigh
Privileges Required
NoneLowHigh
User Interaction
NoneRequired
Scope
ChangedUnchanged
Confidentiality Impact
HighLowNone
Integrity Impact
HighLowNone
Availability Impact
HighLowNone

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CISA-ADPCISA ADP Vulnrichment
cvssV3_1other:ssvc
CVECVE Program Container
Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxf748be531d7012c456b97f66091d86b3675c5fef, f748be531d7012c456b97f66091d86b3675c5fef, f748be531d7012c456b97f66091d86b3675c5fef, f748be531d7012c456b97f66091d86b3675c5fef, f748be531d7012c456b97f66091d86b3675c5fefunaffected
LinuxLinux4.7, 0, 5.15.171, 6.1.116, 6.6.60, 6.11.7, 6.12affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.