CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50297 – net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts
https://notcve.org/view.php?id=CVE-2024-50297
In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! <snip> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 <snip> Start dmaengine after enqueue in dql fixes the crash. • https://git.kernel.org/stable/c/6a91b846af85a24241decd686269e8e038eb13d1 https://git.kernel.org/stable/c/def3dee25cbd1c9b2ed443c3f6180e952563de77 https://git.kernel.org/stable/c/5ccdcdf186aec6b9111845fd37e1757e9b413e2f •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-50296 – net: hns3: fix kernel crash when uninstalling driver
https://notcve.org/view.php?id=CVE-2024-50296
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... • https://git.kernel.org/stable/c/b06ad258e01389ca3ff13bc180f3fcd6a608f1cd https://git.kernel.org/stable/c/c4b64011e458aa2b246cd4e42012cfd83d2d9a5c https://git.kernel.org/stable/c/d36b15e3e7b5937cb1f6ac590a85facc3a320642 https://git.kernel.org/stable/c/0dd8a25f355b4df2d41c08df1716340854c7d4c5 https://git.kernel.org/stable/c/9b5a29f0acefa3eb1dbe2fa302b393eeff64d933 https://git.kernel.org/stable/c/a0df055775f30850c0da8f7dab40d67c0fd63908 https://git.kernel.org/stable/c/7ae4e56de7dbd0999578246a536cf52a63f4056d https://git.kernel.org/stable/c/590a4b2d4e0b73586e88bce9b8135b593 •
CVSS: -EPSS: 0%CPEs: 13EXPL: 0CVE-2024-50295 – net: arc: fix the device for dma_map_single/dma_unmap_single
https://notcve.org/view.php?id=CVE-2024-50295
In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8 • https://git.kernel.org/stable/c/f959dcd6ddfd29235030e8026471ac1b022ad2b0 https://git.kernel.org/stable/c/209fcdad57061f30c5acaca4fe3eed36c28c2086 https://git.kernel.org/stable/c/7c4a0c1e82d2694baa39b1dac6057c5d32ecc842 https://git.kernel.org/stable/c/dd47d2fe06390cc0f6252aa5c4a58bd93a11d596 https://git.kernel.org/stable/c/c58022e95bd62435cb05a3a61c24905e3aa6280c https://git.kernel.org/stable/c/6c50a56d2bce24982694c3796de275a6ac0dcac5 https://git.kernel.org/stable/c/4e57482e8440fac7137832629109730ea4b267aa https://git.kernel.org/stable/c/f8763ab3fb866330681715259986abbab •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50294 – rxrpc: Fix missing locking causing hanging calls
https://notcve.org/view.php?id=CVE-2024-50294
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on. • https://git.kernel.org/stable/c/9d35d880e0e4a3ab32d8c12f9e4d76198aadd42d https://git.kernel.org/stable/c/996a7208dadbf2cdda8d51444d5ee1fdd1ccbc92 https://git.kernel.org/stable/c/b1fdb0bb3b6513f5bd26f92369fd6ac1a2422d8b https://git.kernel.org/stable/c/fc9de52de38f656399d2ce40f7349a6b5f86e787 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50292 – ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove
https://notcve.org/view.php?id=CVE-2024-50292
In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid. • https://git.kernel.org/stable/c/794df9448edb55978e50372f083aeedade1b2844 https://git.kernel.org/stable/c/3a977b554f668382dfba31fd62e4cce4fe5643db https://git.kernel.org/stable/c/0d75f887aabd80cf37ea48d28f159afa7850ea28 https://git.kernel.org/stable/c/4f1d74f74752eab8af6b8b28797dc6490d57374c https://git.kernel.org/stable/c/23bdbd1ef3e063e03d3c50c15a591b005ebbae39 https://git.kernel.org/stable/c/22ae9321054cf7f36c537702af133659f51a0b88 https://git.kernel.org/stable/c/9bb4af400c386374ab1047df44c508512c08c31f •