# CVE-2024-53058: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data > A bug in the stmmac network driver causes unbalanced DMA map/unmap operations, potentially leading to memory corruption and system crashes or code execution. - **Severity:** Critical 9.4 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H`) - **Exploited in the wild:** Not known - **Login needed:** Not needed - **Attackable:** Over the internet - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 19 Nov 2024 - **Updated:** 5 Aug 2026 - **Also known as:** AZL-53834, AZL-53942, BELL-CVE-2024-53058, DEBIAN-CVE-2024-53058, GHSA-wp26-g22c-7r5j, ROOT-OS-DEBIAN-11-CVE-2024-53058, UBUNTU-CVE-2024-53058 ## What is CVE-2024-53058? CVE-2024-53058 is a critical memory corruption vulnerability in Linux kernel, published on 19 Nov 2024. An attacker can exploit it over the internet without logging in, with no action from the victim. ### Official 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 ## Which versions are affected by CVE-2024-53058? It affects 1 product. Products: Linux kernel. ## How do I fix CVE-2024-53058? Apply the vendor's patch. ## Is CVE-2024-53058 being exploited? There is no known exploitation of CVE-2024-53058 in the wild and no public exploit code. ## Other vulnerabilities in Linux kernel - [CVE-2026-53266](https://insights.sbomify.com/CVE-2026-53266/): Linux Kernel Out-of-Bounds Write (high 8.8, exploited in the wild) - [CVE-2013-6282](https://insights.sbomify.com/CVE-2013-6282/): Linux Kernel Improper Input Validation (high 8.8, exploited in the wild) - [CVE-2022-0185](https://insights.sbomify.com/CVE-2022-0185/): Linux Kernel Heap-Based Buffer Overflow (high 8.4, exploited in the wild) - [CVE-2013-2094](https://insights.sbomify.com/CVE-2013-2094/): Linux Kernel Privilege Escalation (high 8.4, exploited in the wild) - [CVE-2026-53362](https://insights.sbomify.com/CVE-2026-53362/): Linux Kernel Unspecified (high 7.8, exploited in the wild) ## Fix prompt for AI coding agents ```text Check this codebase for CVE-2024-53058 and fix it if it is affected. What it is: CVE-2024-53058 is a critical memory corruption vulnerability in Linux kernel, published on 19 Nov 2024. An attacker can exploit it over the internet without logging in, with no action from the victim. Exploitation: There is no known exploitation of CVE-2024-53058 in the wild and no public exploit code. Affected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page. Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/CVE-2024-53058/ (Markdown: https://insights.sbomify.com/CVE-2024-53058/index.md) ``` ## Sources - CVE record: https://www.cve.org/CVERecord?id=CVE-2024-53058 - NVD: https://nvd.nist.gov/vuln/detail/CVE-2024-53058 - OSV: https://osv.dev/vulnerability/CVE-2024-53058 --- From sbomify Insights: https://insights.sbomify.com/CVE-2024-53058/ Summaries are generated and may contain mistakes; the official description above is the record.