| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2024-53058: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data |
| |
| 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 |
| |
| The Linux kernel CVE team has assigned CVE-2024-53058 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 4.7 with commit f748be531d7012c456b97f66091d86b3675c5fef and fixed in 5.15.171 with commit ece593fc9c00741b682869d3f3dc584d37b7c9df |
| Issue introduced in 4.7 with commit f748be531d7012c456b97f66091d86b3675c5fef and fixed in 6.1.116 with commit a3ff23f7c3f0e13f718900803e090fd3997d6bc9 |
| Issue introduced in 4.7 with commit f748be531d7012c456b97f66091d86b3675c5fef and fixed in 6.6.60 with commit 07c9c26e37542486e34d767505e842f48f29c3f6 |
| Issue introduced in 4.7 with commit f748be531d7012c456b97f66091d86b3675c5fef and fixed in 6.11.7 with commit 58d23d835eb498336716cca55b5714191a309286 |
| Issue introduced in 4.7 with commit f748be531d7012c456b97f66091d86b3675c5fef and fixed in 6.12 with commit 66600fac7a984dea4ae095411f644770b2561ede |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2024-53058 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/ece593fc9c00741b682869d3f3dc584d37b7c9df |
| https://git.kernel.org/stable/c/a3ff23f7c3f0e13f718900803e090fd3997d6bc9 |
| https://git.kernel.org/stable/c/07c9c26e37542486e34d767505e842f48f29c3f6 |
| https://git.kernel.org/stable/c/58d23d835eb498336716cca55b5714191a309286 |
| https://git.kernel.org/stable/c/66600fac7a984dea4ae095411f644770b2561ede |