CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-40901 – scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory
https://notcve.org/view.php?id=CVE-2024-40901
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory There is a potential out-of-bounds access when using test_bit() on a single word. The test_bit() and set_bit() functions operate on long values, and when testing or setting a single word, they can exceed the word boundary. KASAN detects this issue and produces a dump: BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965 For full log, please look at [1]. Make the allocation at least the size of sizeof(unsigned long) so that set_bit() and test_bit() have sufficient room for read/write operations without overwriting unallocated memory. [1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/ • https://git.kernel.org/stable/c/c696f7b83edeac804e898952058089143f49ca0a https://git.kernel.org/stable/c/e9bce7c751f6d6c7be88c0bc081a66aaf61a23ee https://git.kernel.org/stable/c/19649e49a6df07cd2e03e0a11396fd3a99485ec2 https://git.kernel.org/stable/c/0081d2b3ae0a17a86b8cc0fa3c8bdc54e233ba16 https://git.kernel.org/stable/c/521f333e644c4246ca04a4fc4772edc53dd2a801 https://git.kernel.org/stable/c/46bab2bcd771e725ff5ca3a68ba68cfeac45676c https://git.kernel.org/stable/c/9079338c5a0d1f1fee34fb1c9e99b754efe414c5 https://git.kernel.org/stable/c/18abb5db0aa9b2d48f7037a88b41af2ee •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39509 – HID: core: remove unnecessary WARN_ON() in implement()
https://notcve.org/view.php?id=CVE-2024-39509
In the Linux kernel, the following vulnerability has been resolved: HID: core: remove unnecessary WARN_ON() in implement() Syzkaller hit a warning [1] in a call to implement() when trying to write a value into a field of smaller size in an output report. Since implement() already has a warn message printed out with the help of hid_warn() and value in question gets trimmed with: ... value &= m; ... WARN_ON may be considered superfluous. Remove it to suppress future syzkaller triggers. [1] WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline] WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 Modules linked in: CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline] RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 ... Call Trace: <TASK> __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline] usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... • https://git.kernel.org/stable/c/95d1c8951e5bd50bb89654a99a7012b1e75646bd https://git.kernel.org/stable/c/955b3764671f3f157215194972d9c01a3a4bd316 https://git.kernel.org/stable/c/f9db5fbeffb951cac3f0fb1c2eeffb79785399ca https://git.kernel.org/stable/c/33f6832798dd3297317901cc1db556ac3ae80c24 https://git.kernel.org/stable/c/8bac61934cd563b073cd30b8cf6d5c758ab5ab26 https://git.kernel.org/stable/c/bfd546fc7fd76076f81bf41b85b51ceda30949fd https://git.kernel.org/stable/c/30f76bc468b9b2cbbd5d3eb482661e3e4798893f https://git.kernel.org/stable/c/655c6de2f215b61d0708db6b06305eee9 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39508 – io_uring/io-wq: Use set_bit() and test_bit() at worker->flags
https://notcve.org/view.php?id=CVE-2024-39508
In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: Use set_bit() and test_bit() at worker->flags Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq to address potential data races. The structure io_worker->flags may be accessed through various data paths, leading to concurrency issues. When KCSAN is enabled, it reveals data races occurring in io_worker_handle_work and io_wq_activate_free_worker functions. BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28: io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569) io_wq_worker (io_uring/io-wq.c:?) <snip> read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5: io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285) io_wq_enqueue (io_uring/io-wq.c:947) io_queue_iowq (io_uring/io_uring.c:524) io_req_task_submit (io_uring/io_uring.c:1511) io_handle_tw_list (io_uring/io_uring.c:1198) <snip> Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm"). These races involve writes and reads to the same memory location by different tasks running on different CPUs. To mitigate this, refactor the code to use atomic operations such as set_bit(), test_bit(), and clear_bit() instead of basic "and" and "or" operations. • https://git.kernel.org/stable/c/ab702c3483db9046bab9f40306f1a28b22dbbdc0 https://git.kernel.org/stable/c/1cbb0affb15470a9621267fe0a8568007553a4bf https://git.kernel.org/stable/c/8a565304927fbd28c9f028c492b5c1714002cbab •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39506 – liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
https://notcve.org/view.php?id=CVE-2024-39506
In the Linux kernel, the following vulnerability has been resolved: liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value, but then it is unconditionally passed to skb_add_rx_frag() which looks strange and could lead to null pointer dereference. lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...) In this path there is no code which sets pg_info->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidio_push_packet() in liquidio/lio_core.c does exactly the same. Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skb_add_rx_frag() into conditional scope. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/1f233f327913f3dee0602cba9c64df1903772b55 https://git.kernel.org/stable/c/87d6bdc006f0cbf297a3b2ad6e40ede4c3ee5dc2 https://git.kernel.org/stable/c/dcc7440f32c7a26b067aff6e7d931ec593024a79 https://git.kernel.org/stable/c/cbf18d8128a753cb632bef39470d19befd9c7347 https://git.kernel.org/stable/c/a86490a3712cc513113440a606a0e77130abd47c https://git.kernel.org/stable/c/f1ab15a09492a5ae8ab1e2c35ba2cf9e150d25ee https://git.kernel.org/stable/c/fd2b613bc4c508e55c1221c6595bb889812a4fea https://git.kernel.org/stable/c/a6f4d0ec170a46b5f453cacf55dff5989 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39501 – drivers: core: synchronize really_probe() and dev_uevent()
https://notcve.org/view.php?id=CVE-2024-39501
In the Linux kernel, the following vulnerability has been resolved: drivers: core: synchronize really_probe() and dev_uevent() Synchronize the dev->driver usage in really_probe() and dev_uevent(). These can run in different threads, what can result in the following race condition for dev->driver uninitialization: Thread #1: ========== really_probe() { ... probe_failed: ... device_unbind_cleanup(dev) { ... dev->driver = NULL; // <= Failed probe sets dev->driver to NULL ... } ... } Thread #2: ========== dev_uevent() { ... if (dev->driver) // If dev->driver is NULLed from really_probe() from here on, // after above check, the system crashes add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... } really_probe() holds the lock, already. So nothing needs to be done there. dev_uevent() is called with lock held, often, too. But not always. What implies that we can't add any locking in dev_uevent() itself. So fix this race by adding the lock to the non-protected path. • https://git.kernel.org/stable/c/239378f16aa1ab5c502e42a06359d2de4f88ebb4 https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080 https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721 https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69 https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90 https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea •