CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50062 – RDMA/rtrs-srv: Avoid null pointer deref during path establishment
https://notcve.org/view.php?id=CVE-2024-50062
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref. • https://git.kernel.org/stable/c/394b2f4d5e014820455af3eb5859eb328eaafcfd https://git.kernel.org/stable/c/b5d4076664465487a9a3d226756995b12fb73d71 https://git.kernel.org/stable/c/ccb8e44ae3e2391235f80ffc6be59bec6b889ead https://git.kernel.org/stable/c/b720792d7e8515bc695752e0ed5884e2ea34d12a https://git.kernel.org/stable/c/d0e62bf7b575fbfe591f6f570e7595dd60a2f5eb •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50061 – i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition
https://notcve.org/view.php?id=CVE-2024-50061
In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove. • https://git.kernel.org/stable/c/ea0256e393e0072e8c80fd941547807f0c28108b https://git.kernel.org/stable/c/687016d6a1efbfacdd2af913e2108de6b75a28d5 https://git.kernel.org/stable/c/609366e7a06d035990df78f1562291c3bf0d4a12 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50060 – io_uring: check if we need to reschedule during overflow flush
https://notcve.org/view.php?id=CVE-2024-50060
In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop. • https://git.kernel.org/stable/c/a2493904e95ce94bbec819d8f7f03b99976eb25c https://git.kernel.org/stable/c/f4ce3b5d26ce149e77e6b8e8f2058aa80e5b034e https://git.kernel.org/stable/c/c2eadeafce2d385b3f6d26a7f31fee5aba2bbbb0 https://git.kernel.org/stable/c/eac2ca2d682f94f46b1973bdf5e77d85d77b8e53 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50059 – ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition
https://notcve.org/view.php?id=CVE-2024-50059
In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove. • https://git.kernel.org/stable/c/b650189687822b705711f0567a65a164a314d8df https://git.kernel.org/stable/c/92728fceefdaa2a0a3aae675f86193b006eeaa43 https://git.kernel.org/stable/c/3ae45be8492460a35b5aebf6acac1f1d32708946 https://git.kernel.org/stable/c/fa840ba4bd9f3bad7f104e5b32028ee73af8b3dd https://git.kernel.org/stable/c/177925d9c8715a897bb79eca62628862213ba956 https://git.kernel.org/stable/c/e51aded92d42784313ba16c12f4f88cc4f973bbb •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50058 – serial: protect uart_port_dtr_rts() in uart_shutdown() too
https://notcve.org/view.php?id=CVE-2024-50058
In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uart_port_dtr_rts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks. • https://git.kernel.org/stable/c/399927f0f875b93f3d5a0336d382ba48b8671eb2 https://git.kernel.org/stable/c/d7b5876a6e74cdf8468a478be6b23f2f5464ac7a https://git.kernel.org/stable/c/e418d91195d29d5f9c9685ff309b92b04b41dc40 https://git.kernel.org/stable/c/76ed24a34223bb2c6b6162e1d8389ec4e602a290 https://git.kernel.org/stable/c/602babaa84d627923713acaf5f7e9a4369e77473 •