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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50290 – media: cx24116: prevent overflows on SNR calculus
https://notcve.org/view.php?id=CVE-2024-50290
In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that. • https://git.kernel.org/stable/c/8953db793d5bdeea5ac92c9e97f57d3ff8a7dccf https://git.kernel.org/stable/c/127b9076baeadd734b18ddc8f2cd93b47d5a3ea3 https://git.kernel.org/stable/c/cad97ca8cfd43a78a19b59949f33e3563d369247 https://git.kernel.org/stable/c/828047c70f4716fde4b1316f7b610e97a4e83824 https://git.kernel.org/stable/c/f2b4f277c41db8d548f38f1dd091bbdf6a5acb07 https://git.kernel.org/stable/c/fbefe31e4598cdb0889eee2e74c995b2212efb08 https://git.kernel.org/stable/c/83c152b55d88cbf6fc4685941fcb31333986774d https://git.kernel.org/stable/c/3a1ed994d9454132354b860321414955d •