{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-06-12T07:08:33.142","vulnerabilities":[{"cve":{"id":"CVE-2024-53058","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","published":"2024-11-19T18:15:25.767","lastModified":"2025-11-03T23:17:16.873","vulnStatus":"Modified","cveTags":[],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data\n\nIn case the non-paged data of a SKB carries protocol header and protocol\npayload to be transmitted on a certain platform that the DMA AXI address\nwidth is configured to 40-bit/48-bit, or the size of the non-paged data\nis bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI\naddress width is configured to 32-bit, then this SKB requires at least\ntwo DMA transmit descriptors to serve it.\n\nFor example, three descriptors are allocated to split one DMA buffer\nmapped from one piece of non-paged data:\n    dma_desc[N + 0],\n    dma_desc[N + 1],\n    dma_desc[N + 2].\nThen three elements of tx_q->tx_skbuff_dma[] will be allocated to hold\nextra information to be reused in stmmac_tx_clean():\n    tx_q->tx_skbuff_dma[N + 0],\n    tx_q->tx_skbuff_dma[N + 1],\n    tx_q->tx_skbuff_dma[N + 2].\nNow we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer\naddress returned by DMA mapping call. stmmac_tx_clean() will try to\nunmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf\nis a valid buffer address.\n\nThe expected behavior that saves DMA buffer address of this non-paged\ndata to tx_q->tx_skbuff_dma[entry].buf is:\n    tx_q->tx_skbuff_dma[N + 0].buf = NULL;\n    tx_q->tx_skbuff_dma[N + 1].buf = NULL;\n    tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single();\nUnfortunately, the current code misbehaves like this:\n    tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single();\n    tx_q->tx_skbuff_dma[N + 1].buf = NULL;\n    tx_q->tx_skbuff_dma[N + 2].buf = NULL;\n\nOn the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the\nDMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address\nobviously, then the DMA buffer will be unmapped immediately.\nThere may be a rare case that the DMA engine does not finish the\npending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go\nhorribly wrong, DMA is going to access a unmapped/unreferenced memory\nregion, corrupted data will be transmited or iommu fault will be\ntriggered :(\n\nIn contrast, the for-loop that maps SKB fragments behaves perfectly\nas expected, and that is how the driver should do for both non-paged\ndata and paged frags actually.\n\nThis patch corrects DMA map/unmap sequences by fixing the array index\nfor tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address.\n\nTested and verified on DWXGMAC CORE 3.20a"},{"lang":"es","value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: TSO: Fix DMA map/unmap no balanceado para datos SKB no paginados En caso de que los datos no paginados de un SKB lleven encabezado de protocolo y payload de protocolo para ser transmitidos en una determinada plataforma que el ancho de dirección DMA AXI está configurado a 40 bits/48 bits, o el tamaño de los datos no paginados es mayor que TSO_MAX_BUFF_SIZE en una determinada plataforma que el ancho de dirección DMA AXI está configurado a 32 bits, entonces este SKB requiere al menos dos descriptores de transmisión DMA para servirlo. Por ejemplo, se asignan tres descriptores para dividir un buffer DMA mapeado a partir de una pieza de datos no paginados: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Luego, se asignarán tres elementos de tx_q->tx_skbuff_dma[] para almacenar información adicional que se reutilizará en stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Ahora nos centramos en tx_q->tx_skbuff_dma[entry].buf, que es la dirección del búfer DMA devuelta por la llamada de mapeo DMA. stmmac_tx_clean() intentará desasignar el búfer DMA _SOLO_SI_ tx_q->tx_skbuff_dma[entry].buf es una dirección de búfer válida. El comportamiento esperado que guarda la dirección del buffer DMA de estos datos no paginados en tx_q->tx_skbuff_dma[entrada].buf es: 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(); Desafortunadamente, el código actual se comporta mal de esta manera: 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; En el lado stmmac_tx_clean(), cuando el motor DMA cierra dma_desc[N + 0], tx_q->tx_skbuff_dma[N + 0].buf es obviamente una dirección de búfer válida, entonces el búfer DMA se desasignará inmediatamente. Puede haber un caso poco común en el que el motor DMA no finalice aún los dma_desc[N + 1], dma_desc[N + 2] pendientes. Ahora las cosas saldrán terriblemente mal, DMA accederá a una región de memoria no mapeada/no referenciada, se transmitirán datos corruptos o se activará un error de iommu :( Por el contrario, el bucle for que mapea fragmentos SKB se comporta perfectamente como se espera, y así es como el controlador debería funcionar tanto para datos no paginados como para fragmentos paginados en realidad. Este parche corrige las secuencias de mapeo/desasignamiento de DMA al arreglar el índice de matriz para tx_q->tx_skbuff_dma[entry].buf al asignar la dirección del búfer de DMA. Probado y verificado en DWXGMAC CORE 3.20a"}],"metrics":{"cvssMetricV31":[{"source":"nvd@nist.gov","type":"Primary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":3.6},{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":3.6}]},"weaknesses":[{"source":"nvd@nist.gov","type":"Primary","description":[{"lang":"en","value":"NVD-CWE-noinfo"}]}],"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"4.7","versionEndExcluding":"5.15.171","matchCriteriaId":"F7B2EF6A-A80D-4A30-B1E9-7DBA47DFA518"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.16","versionEndExcluding":"6.1.116","matchCriteriaId":"43EFDC15-E4D4-4F1E-B70D-62F0854BFDF3"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.2","versionEndExcluding":"6.6.60","matchCriteriaId":"75088E5E-2400-4D20-915F-7A65C55D9CCD"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.7","versionEndExcluding":"6.11.7","matchCriteriaId":"E96F53A4-5E87-4A70-BD9A-BC327828D57F"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.12:rc1:*:*:*:*:*:*","matchCriteriaId":"7F361E1D-580F-4A2D-A509-7615F73167A1"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.12:rc2:*:*:*:*:*:*","matchCriteriaId":"925478D0-3E3D-4E6F-ACD5-09F28D5DF82C"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.12:rc3:*:*:*:*:*:*","matchCriteriaId":"3C95E234-D335-4B6C-96BF-E2CEBD8654ED"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.12:rc4:*:*:*:*:*:*","matchCriteriaId":"E0F717D8-3014-4F84-8086-0124B2111379"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.12:rc5:*:*:*:*:*:*","matchCriteriaId":"24DBE6C7-2AAE-4818-AED2-E131F153D2FA"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/07c9c26e37542486e34d767505e842f48f29c3f6","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/58d23d835eb498336716cca55b5714191a309286","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/66600fac7a984dea4ae095411f644770b2561ede","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/a3ff23f7c3f0e13f718900803e090fd3997d6bc9","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/ece593fc9c00741b682869d3f3dc584d37b7c9df","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html","source":"af854a3a-2127-422b-91ae-364da2661108"}]}}]}