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 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50056 – usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c
https://notcve.org/view.php?id=CVE-2024-50056
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR(). • https://git.kernel.org/stable/c/cedeb36c3ff4acd0f3d09918dfd8ed1df05efdd6 https://git.kernel.org/stable/c/a7bb96b18864225a694e3887ac2733159489e4b0 •