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

Published Nov 19, 2024
·
Updated

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 TSOMAXBUFFSIZE 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: dmadesc[N + 0], dmadesc[N + 1], dmadesc[N + 2]. Then three elements of txq->txskbuffdma[] will be allocated to hold extra information to be reused in stmmactxclean(): txq->txskbuffdma[N + 0], txq->txskbuffdma[N + 1], txq->txskbuffdma[N + 2]. Now we focus on txq->txskbuffdma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmactxclean() will try to unmap the DMA buffer ONLYIF txq->txskbuffdma[entry].buf is a valid buffer address.

The expected behavior that saves DMA buffer address of this non-paged data to txq->txskbuffdma[entry].buf is: txq->txskbuffdma[N + 0].buf = NULL; txq->txskbuffdma[N + 1].buf = NULL; txq->txskbuffdma[N + 2].buf = dmamapsingle(); Unfortunately, the current code misbehaves like this: txq->txskbuffdma[N + 0].buf = dmamapsingle(); txq->txskbuffdma[N + 1].buf = NULL; txq->txskbuffdma[N + 2].buf = NULL;

On the stmmactxclean() side, when dmadesc[N + 0] is closed by the DMA engine, txq->txskbuffdma[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 dmadesc[N + 1], dmadesc[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 txq->txskbuffdma[entry].buf when assigning DMA buffer address.

Tested and verified on DWXGMAC CORE 3.20a

Other sources

This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.

Launchpad

Affected Software

16 affected componentsFixes available
Linux Linux kernel>=4.7<5.15.171
Linux Linux kernel>=5.16<6.1.116
Linux Linux kernel>=6.2<6.6.60
Linux Linux kernel>=6.7<6.11.7
Linux Linux kernel=6.12-rc1
Linux Linux kernel=6.12-rc2
Linux Linux kernel=6.12-rc3
Linux Linux kernel=6.12-rc4
Linux Linux kernel=6.12-rc5
debian/linux<=5.10.223-1, <=5.10.234-1
6.1.129-16.1.135-16.12.25-16.12.27-1
debian/linux-6.1
6.1.129-1~deb11u1
Microsoft cbl2 kernel 5.15.167.1-2
Microsoft cbl2 kernel 5.15.173.1-1
Microsoft azl3 kernel 6.6.64.2-1
Microsoft azl3 kernel 6.6.57.1-7
Microsoft cbl2 kernel 5.15.167.1-2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade debian/linux to a version that resolves this vulnerability.

    Fixed in 6.1.129-1Fixed in 6.1.135-1Fixed in 6.12.25-1Fixed in 6.12.27-1
  2. Upgrade

    Upgrade debian/linux-6.1 to a version that resolves this vulnerability.

    Fixed in 6.1.129-1~deb11u1
  3. Configuration

    Apply the code change described in the fix for "net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data" so that when an SKB non-paged data segment requires multiple DMA transmit descriptors, the DMA mapping result is stored in tx_q->tx_skbuff_dma[N + 2].buf (expected: 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();), preventing stmmac_tx_clean() from unmapping dma_desc[N + 0] immediately due to mis-associated DMA buffer addresses.

    Linux kernel net: stmmac (TSO) driver tx_q->tx_skbuff_dma array index used for DMA buffer address bookkeeping = Fix assignment to store dma_map_single() results in the correct element for multi-descriptor non-paged SKB data (N + 2)

Event History

Nov 19, 2024
CVE Published
via MITRE·05:19 PM
Data Sourced
via MITRE·05:19 PM
DescriptionSeverity
Data Sourced
via NVD·06:15 PM
RemedyDescriptionSeverityAffected Software
Dec 12, 2024
Data Sourced
via Microsoft·08:00 AM
DescriptionSeverityWeakness
Data Sourced
via Microsoft·08:00 AM
Affected Software
Updated
via Microsoft·08:00 AM
SeverityAffected Software
Updated
via Microsoft·08:00 AM
Affected Software
Updated
via Microsoft·08:00 AM
DescriptionSeverity
Feb 20, 2025
Data Sourced
via Launchpad·12:51 AM
Description
May 11, 2025
Data Sourced
via Ubuntu·01:10 AM
RemedyDescriptionSeverityAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2024-53058?

CVE-2024-53058 has not been assigned a specific severity rating, but it is related to a critical area of the Linux kernel affecting DMA operations.

2

How do I fix CVE-2024-53058?

To fix CVE-2024-53058, users should upgrade to the patched version of the Linux kernel that addresses this vulnerability.

3

Which Linux kernel versions are affected by CVE-2024-53058?

CVE-2024-53058 affects Linux kernel versions from 4.7 up to 6.12-rc5.

4

What type of vulnerability is CVE-2024-53058?

CVE-2024-53058 is a vulnerability related to unbalanced DMA map/unmap operations for non-paged SKB data.

5

Is CVE-2024-53058 specific to a particular platform?

CVE-2024-53058 may impact certain platforms that handle DMA operations in relation to protocol headers and payloads.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203