CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-53060 – drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported
https://notcve.org/view.php?id=CVE-2024-53060
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported acpi_evaluate_object() may return AE_NOT_FOUND (failure), which would result in dereferencing buffer.pointer (obj) while being NULL. Although this case may be unrealistic for the current code, it is still better to protect against possible bugs. Bail out also when status is AE_NOT_FOUND. This fixes 1 FORWARD_NULL issue reported by Coverity Report: CID 1600951: Null pointer dereferences (FORWARD_NULL) (cherry picked from commit 91c9e221fe2553edf2db71627d8453f083de87a1) • https://git.kernel.org/stable/c/58556dcbd5606a5daccaee73b2130bc16b48e025 https://git.kernel.org/stable/c/43b4fa6e0e238c6e2662f4fb61d9f51c2785fb1d https://git.kernel.org/stable/c/234682910971732cd4da96fd95946e296e486b38 https://git.kernel.org/stable/c/6032287747f874b52dc8b9d7490e2799736e035f https://git.kernel.org/stable/c/cd67af3c1762de4c2483ae4dbdd98f9ea8fa56e3 https://git.kernel.org/stable/c/975ede2a7bec52b5da1428829b3439667c8a234b https://git.kernel.org/stable/c/1d7175f9c57b1abf9ecfbdfd53ea760761f52ffe https://git.kernel.org/stable/c/ce8a00a00e36f61f5a1e47734332420b6 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-53059 – wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()
https://notcve.org/view.php?id=CVE-2024-53059
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer. • https://git.kernel.org/stable/c/f130bb75d8817c560b48c4d1a0e5279968a0859d https://git.kernel.org/stable/c/9c98ee7ea463a838235e7a0e35851b38476364f2 https://git.kernel.org/stable/c/45a628911d3c68e024eed337054a0452b064f450 https://git.kernel.org/stable/c/3f45d590ccbae6dfd6faef54efe74c30bd85d3da https://git.kernel.org/stable/c/64d63557ded6ff3ce72b18ab87a6c4b1b652161c https://git.kernel.org/stable/c/3eb986c64c6bfb721950f9666a3b723cf65d043f https://git.kernel.org/stable/c/9480c3045f302f43f9910d2d556d6cf5a62c1822 https://git.kernel.org/stable/c/07a6e3b78a65f4b2796a8d0d4adb1a15a •
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: 7.8EPSS: 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 • CWE-416: Use After Free •
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 •