Linux Kernel up to 5.15.170/6.1.115/6.6.59/6.11.6 stmmac_tx_clean array index

Summaryinfo

A vulnerability, which was classified as problematic, was found in Linux Kernel up to 5.15.170/6.1.115/6.6.59/6.11.6. Affected by this issue is the function stmmac_tx_clean. Such manipulation leads to array index. This vulnerability is listed as CVE-2024-53058. There is no available exploit. You should upgrade the affected component.

Detailsinfo

A vulnerability was found in Linux Kernel up to 5.15.170/6.1.115/6.6.59/6.11.6. It has been rated as problematic. Affected by this issue is the function stmmac_tx_clean. The manipulation with an unknown input leads to a array index vulnerability. Using CWE to declare the problem leads to CWE-129. The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array. The impact remains unknown. CVE summarizes:

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

The advisory is shared for download at git.kernel.org. This vulnerability is handled as CVE-2024-53058 since 11/19/2024. The exploitation is known to be easy. There are known technical details, but no exploit is available. The current price for an exploit might be approx. USD $0-$5k (estimation calculated on 12/07/2025).

The vulnerability scanner Nessus provides a plugin with the ID 211777 (Debian dsa-5818 : affs-modules-6.1.0-21-4kc-malta-di - security update), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 5.15.171, 6.1.116, 6.6.60 or 6.11.7 eliminates this vulnerability. Applying the patch ece593fc9c00/a3ff23f7c3f0/07c9c26e3754/58d23d835eb4/66600fac7a98 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (211777) and CERT Bund (WID-SEC-2024-3509). Once again VulDB remains the best source for vulnerability data.

Affected

• Google Container-Optimized OS
• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• Oracle Linux
• RESF Rocky Linux
• Dell NetWorker
• Open Source Linux Kernel
• Dell Avamar
• IBM QRadar SIEM
• IBM DataPower Gateway
• Dell PowerProtect Data Domain

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 5.15.170
• 6.1.115
• 6.6.0
• 6.6.1
• 6.6.2
• 6.6.3
• 6.6.4
• 6.6.5
• 6.6.6
• 6.6.7
• 6.6.8
• 6.6.9
• 6.6.10
• 6.6.11
• 6.6.12
• 6.6.13
• 6.6.14
• 6.6.15
• 6.6.16
• 6.6.17
• 6.6.18
• 6.6.19
• 6.6.20
• 6.6.21
• 6.6.22
• 6.6.23
• 6.6.24
• 6.6.25
• 6.6.26
• 6.6.27
• 6.6.28
• 6.6.29
• 6.6.30
• 6.6.31
• 6.6.32
• 6.6.33
• 6.6.34
• 6.6.35
• 6.6.36
• 6.6.37
• 6.6.38
• 6.6.39
• 6.6.40
• 6.6.41
• 6.6.42
• 6.6.43
• 6.6.44
• 6.6.45
• 6.6.46
• 6.6.47
• 6.6.48
• 6.6.49
• 6.6.50
• 6.6.51
• 6.6.52
• 6.6.53
• 6.6.54
• 6.6.55
• 6.6.56
• 6.6.57
• 6.6.58
• 6.6.59
• 6.11.0
• 6.11.1
• 6.11.2
• 6.11.3
• 6.11.4
• 6.11.5
• 6.11.6

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion