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: 2EXPL: 0CVE-2024-50293 – net/smc: do not leave a dangling sk pointer in __smc_create()
https://notcve.org/view.php?id=CVE-2024-50293
In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 ("socket: Print pf->create() when it does not clear sock->sk on failure."), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d ("Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'") • https://git.kernel.org/stable/c/d25a92ccae6bed02327b63d138e12e7806830f78 https://git.kernel.org/stable/c/d2cc492124e1f22daa1700f069bcc58788043381 https://git.kernel.org/stable/c/d293958a8595ba566fb90b99da4d6263e14fee15 •
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 •