Skip to main content

CVE-2024-53058: Vulnerability in Linux Linux

High
VulnerabilityCVE-2024-53058cvecve-2024-53058
Published: Tue Nov 19 2024 (11/19/2024, 17:19:40 UTC)
Source: CVE
Vendor/Project: Linux
Product: Linux

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

AI-Powered Analysis

AILast updated: 06/28/2025, 14:25:43 UTC

Technical Analysis

CVE-2024-53058 is a vulnerability in the Linux kernel's stmmac network driver, specifically related to the handling of TCP Segmentation Offload (TSO) for non-paged socket buffer (SKB) data. The issue arises from an incorrect DMA (Direct Memory Access) map/unmap sequence when transmitting large SKB data that requires multiple DMA transmit descriptors. On certain hardware platforms with specific DMA AXI address width configurations (40-bit/48-bit or 32-bit with large buffer sizes), a single SKB non-paged data buffer is split across multiple DMA descriptors. The driver is expected to set the DMA buffer address only on the last descriptor's tx_skbuff_dma[].buf entry and set the others to NULL. However, due to a coding error, the first descriptor's buf is set with the DMA address while the subsequent descriptors are set to NULL. During transmission cleanup (stmmac_tx_clean()), the DMA buffer is unmapped prematurely when the first descriptor completes, even though the other descriptors may still be in use by the DMA engine. This leads to a use-after-unmap condition where the DMA engine accesses unmapped memory, causing data corruption or IOMMU faults. The vulnerability is subtle and hardware/platform dependent but can cause network data corruption or system instability. The patch corrects the DMA mapping by assigning the DMA buffer address to the correct descriptor index, ensuring proper synchronization between DMA mapping and unmapping. This flaw was verified on the DWXGMAC CORE 3.20a hardware and affects Linux kernel versions identified by the given commit hashes. No known exploits are reported in the wild yet, and no CVSS score has been assigned.

Potential Impact

For European organizations, this vulnerability poses a risk primarily to systems running affected Linux kernel versions with the stmmac driver enabled, especially on hardware platforms using the DWXGMAC or similar Ethernet MAC cores with the described DMA configurations. The impact includes potential network data corruption, leading to degraded network reliability, packet loss, or transmission errors. In critical infrastructure or industrial control systems relying on Linux-based embedded devices or network appliances, this could disrupt operations or cause intermittent failures. Additionally, the use-after-unmap condition could trigger IOMMU faults, potentially leading to kernel crashes or denial of service. While this vulnerability does not directly enable remote code execution or privilege escalation, the resulting instability and data corruption can affect availability and integrity of network communications. European organizations with embedded Linux devices in telecommunications, manufacturing, or network infrastructure are particularly at risk. The lack of known exploits reduces immediate threat but patching is important to prevent future exploitation and maintain system stability.

Mitigation Recommendations

1. Apply the official Linux kernel patch that corrects the DMA map/unmap sequence in the stmmac driver as soon as it becomes available in your distribution or kernel vendor updates. 2. For embedded or custom Linux systems, rebuild and deploy updated kernels incorporating the fix. 3. Identify and inventory devices using the stmmac driver and verify their kernel versions and hardware platforms against the affected list. 4. Where possible, temporarily disable TSO offloading on affected network interfaces to reduce exposure until patched, using ethtool commands (e.g., 'ethtool -K <interface> tso off'). 5. Monitor system logs for IOMMU faults or network transmission errors that could indicate exploitation or manifestation of this bug. 6. Coordinate with hardware vendors to confirm platform-specific mitigations or firmware updates if applicable. 7. Implement network segmentation and redundancy to minimize impact of potential network disruptions caused by this vulnerability. 8. Maintain rigorous patch management and testing procedures to ensure timely deployment of kernel updates across all Linux systems.

Need more detailed analysis?Get Pro

Technical Details

Data Version
5.1
Assigner Short Name
Linux
Date Reserved
2024-11-19T17:17:24.974Z
Cisa Enriched
false
Cvss Version
null
State
PUBLISHED

Threat ID: 682d9824c4522896dcbdf869

Added to database: 5/21/2025, 9:08:52 AM

Last enriched: 6/28/2025, 2:25:43 PM

Last updated: 8/18/2025, 11:30:52 PM

Views: 14

Actions

PRO

Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.

Please log in to the Console to use AI analysis features.

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats