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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50057 – usb: typec: tipd: Free IRQ only if it was requested before
https://notcve.org/view.php?id=CVE-2024-50057
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194 • https://git.kernel.org/stable/c/b72bf5cade51ba4055c8a8998d275e72e6b521ce https://git.kernel.org/stable/c/4d4b23c119542fbaed2a16794d3801cb4806ea02 https://git.kernel.org/stable/c/db63d9868f7f310de44ba7bea584e2454f8b4ed0 •