CVE-2024-53058

Source
https://cve.org/CVERecord?id=CVE-2024-53058
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-53058.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2024-53058
Downstream
Related
Published
2024-11-19T17:19:40.912Z
Modified
2026-05-28T03:52:59.128926591Z
Severity
  • 5.5 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
Summary
net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data
Details

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 TSOMAXBUFF_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: 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->txskbuff_dma[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->txskbuff_dma[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->txskbuff_dma[entry].buf when assigning DMA buffer address.

Tested and verified on DWXGMAC CORE 3.20a

Database specific
{
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/53xxx/CVE-2024-53058.json",
    "cna_assigner": "Linux"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
f748be531d7012c456b97f66091d86b3675c5fef
Fixed
ece593fc9c00741b682869d3f3dc584d37b7c9df
Fixed
a3ff23f7c3f0e13f718900803e090fd3997d6bc9
Fixed
07c9c26e37542486e34d767505e842f48f29c3f6
Fixed
58d23d835eb498336716cca55b5714191a309286
Fixed
66600fac7a984dea4ae095411f644770b2561ede

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-53058.json"

Linux / Kernel

Package

Name
Kernel

Affected 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

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-53058.json"