CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-53058 – net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data
https://notcve.org/view.php?id=CVE-2024-53058
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 • https://git.kernel.org/stable/c/f748be531d7012c456b97f66091d86b3675c5fef 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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-53057 – net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT
https://notcve.org/view.php?id=CVE-2024-53057
In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) • https://git.kernel.org/stable/c/066a3b5b2346febf9a655b444567b7138e3bb939 https://git.kernel.org/stable/c/e7f9a6f97eb067599a74f3bcb6761976b0ed303e https://git.kernel.org/stable/c/dbe778b08b5101df9e89bc06e0a3a7ecd2f4ef20 https://git.kernel.org/stable/c/ce691c814bc7a3c30c220ffb5b7422715458fd9b https://git.kernel.org/stable/c/05df1b1dff8f197f1c275b57ccb2ca33021df552 https://git.kernel.org/stable/c/580b3189c1972aff0f993837567d36392e9d981b https://git.kernel.org/stable/c/597cf9748c3477bf61bc35f0634129f56764ad24 https://git.kernel.org/stable/c/9995909615c3431a5304c1210face5f26 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-53056 – drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()
https://notcve.org/view.php?id=CVE-2024-53056
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the "mtk_crtc->cmdq_client.chan" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the "mtk_crtc->cmdq_client.chan" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference. • https://git.kernel.org/stable/c/7627122fd1c06800a1fe624e9fb3c269796115e8 https://git.kernel.org/stable/c/2c4396693698e876e559768d3d3a150c672ec384 https://git.kernel.org/stable/c/c60583a87cb4a85b69d1f448f0be5eb6ec62cbb2 https://git.kernel.org/stable/c/4018651ba5c409034149f297d3dd3328b91561fd •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-53055 – wifi: iwlwifi: mvm: fix 6 GHz scan construction
https://notcve.org/view.php?id=CVE-2024-53055
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32. • https://git.kernel.org/stable/c/eae94cf82d7456b57fa9fd55c1edb8a726dcc19c https://git.kernel.org/stable/c/2ac15e5a8f42fed5d90ed9e1197600913678c50f https://git.kernel.org/stable/c/cde8a7eb5c6762264ff0f4433358e0a0d250c875 https://git.kernel.org/stable/c/fc621e7a043de346c33bd7ae7e2e0c651d6152ef https://git.kernel.org/stable/c/2ccd5badadab2d586e91546bf5af3deda07fef1f https://git.kernel.org/stable/c/7245012f0f496162dd95d888ed2ceb5a35170f1a •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-53054 – cgroup/bpf: use a dedicated workqueue for cgroup bpf destruction
https://notcve.org/view.php?id=CVE-2024-53054
In the Linux kernel, the following vulnerability has been resolved: cgroup/bpf: use a dedicated workqueue for cgroup bpf destruction A hung_task problem shown below was found: INFO: task kworker/0:0:8 blocked for more than 327 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Workqueue: events cgroup_bpf_release Call Trace: <TASK> __schedule+0x5a2/0x2050 ? find_held_lock+0x33/0x100 ? wq_worker_sleeping+0x9e/0xe0 schedule+0x9f/0x180 schedule_preempt_disabled+0x25/0x50 __mutex_lock+0x512/0x740 ? cgroup_bpf_release+0x1e/0x4d0 ? cgroup_bpf_release+0xcf/0x4d0 ? • https://git.kernel.org/stable/c/4bfc0bb2c60e2f4cc8eb60f03cf8dfa72336272a https://git.kernel.org/stable/c/71f14a9f5c7db72fdbc56e667d4ed42a1a760494 https://git.kernel.org/stable/c/0d86cd70fc6a7ba18becb52ad8334d5ad3eca530 https://git.kernel.org/stable/c/6dab3331523ba73db1345d19e6f586dcd5f6efb4 https://git.kernel.org/stable/c/117932eea99b729ee5d12783601a4f7f5fd58a23 •