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_skbuf
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.15.171, 6.1.116, 6.11.7, 6.6.60
- CVEs
- CVE-2024-53058
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 02:02 UTC · Revision 1
Source evidence
net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data
core-osv · Original sourcePublished 19 Nov 2024, 17:19 UTC
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_skbuf
osv:CVE-2024-53058
Kernel
Fixed versions: 5.15.171, 6.1.116, 6.6.60, 6.11.7
Complete source record
{
"id": "3b3fcc21dadf6882ec387e59aee3b75f72dbbd8608cde3c4d00715f2310dd6f8",
"url": "https://osv.dev/vulnerability/CVE-2024-53058",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data",
"summary": "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_skbuf",
"evidence": "osv:CVE-2024-53058",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.15.171",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.116",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.60",
"evidence": "/affected/1/ranges"
},
{
"value": "6.11.7",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "critical",
"structured": {
"id": "CVE-2024-53058",
"aliases": [
"CVE-2024-53058"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "f748be531d7012c456b97f66091d86b3675c5fef"
},
{
"fixed": "ece593fc9c00741b682869d3f3dc584d37b7c9df"
},
{
"fixed": "a3ff23f7c3f0e13f718900803e090fd3997d6bc9"
},
{
"fixed": "07c9c26e37542486e34d767505e842f48f29c3f6"
},
{
"fixed": "58d23d835eb498336716cca55b5714191a309286"
},
{
"fixed": "66600fac7a984dea4ae095411f644770b2561ede"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-53058.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "4.7.0"
},
{
"fixed": "5.15.171"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.116"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.60"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.11.7"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-53058.json"
}
}
],
"modified": "2026-10-28T02:30:25.480317152Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/07c9c26e37542486e34d767505e842f48f29c3f6",
"https://git.kernel.org/stable/c/58d23d835eb498336716cca55b5714191a309286",
"https://git.kernel.org/stable/c/66600fac7a984dea4ae095411f644770b2561ede",
"https://git.kernel.org/stable/c/a3ff23f7c3f0e13f718900803e090fd3997d6bc9",
"https://git.kernel.org/stable/c/ece593fc9c00741b682869d3f3dc584d37b7c9df",
"https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/53xxx/CVE-2024-53058.json",
"https://nvd.nist.gov/vuln/detail/CVE-2024-53058",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/53xxx/CVE-2024-53058.json"
}
},
"related_cves": [
{
"value": "CVE-2024-53058",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 491767,
"published_at": "2024-11-19T17:19:40.912+00:00"
}