CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56670 – usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer
https://notcve.org/view.php?id=CVE-2024-56670
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer Considering that in some extreme cases, when u_serial driver is accessed by multiple threads, Thread A is executing the open operation and calling the gs_open, Thread B is executing the disconnect operation and calling the gserial_disconnect function,The port->port_usb pointer will be set to NULL. E.g. Thread A Thread B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) Crash This causes thread A to access a null pointer (port->port_usb is null) when calling the gs_free_requests function, causing a crash. If port_usb is NULL, the release request will be skipped as it will be done by gserial_disconnect. So add a null pointer check to gs_start_io before attempting to access the value of the pointer port->port_usb. Call trace: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invoke_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68 • https://git.kernel.org/stable/c/c1dca562be8ada614ef193aa246c6f8705bcd6b9 https://git.kernel.org/stable/c/4efdfdc32d8d6307f968cd99f1db64468471bab1 https://git.kernel.org/stable/c/28b3c03a6790de1f6f2683919ad657840f0f0f58 https://git.kernel.org/stable/c/1247e1df086aa6c17ab53cd1bedce70dd7132765 https://git.kernel.org/stable/c/c83213b6649d22656b3a4e92544ceeea8a2c6c07 https://git.kernel.org/stable/c/8ca07a3d18f39b1669927ef536e485787e856df6 https://git.kernel.org/stable/c/dd6b0ca6025f64ccb465a6a3460c5b0307ed9c44 https://git.kernel.org/stable/c/4cfbca86f6a8b801f3254e0e3c8f2b1d2 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-56665 – bpf,perf: Fix invalid prog_array access in perf_event_detach_bpf_prog
https://notcve.org/view.php?id=CVE-2024-56665
In the Linux kernel, the following vulnerability has been resolved: bpf,perf: Fix invalid prog_array access in perf_event_detach_bpf_prog Syzbot reported [1] crash that happens for following tracing scenario: - create tracepoint perf event with attr.inherit=1, attach it to the process and set bpf program to it - attached process forks -> chid creates inherited event the new child event shares the parent's bpf program and tp_event (hence prog_array) which is global for tracepoint - exit both process and its child -> release both events - first perf_event_detach_bpf_prog call will release tp_event->prog_array and second perf_event_detach_bpf_prog will crash, because tp_event->prog_array is NULL The fix makes sure the perf_event_detach_bpf_prog checks prog_array is valid before it tries to remove the bpf program from it. [1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc95e896a7ef9ff93b0b8ad • https://git.kernel.org/stable/c/7a5c653ede645693422e43cccaa3e8f905d21c74 https://git.kernel.org/stable/c/21db2f35fa97e4a3447f2edeb7b2569a8bfdc83b https://git.kernel.org/stable/c/0ee288e69d033850bc87abe0f9cc3ada24763d7f https://git.kernel.org/stable/c/b4007d5fe38625b8a1b8edc0f385d86527651238 https://git.kernel.org/stable/c/585674b9d0d80bd7f428b1f88be13cf6d5d6f739 https://git.kernel.org/stable/c/842e5af282453983586e2eae3c8eaf252de5f22f https://git.kernel.org/stable/c/c2b6b47662d5f2dfce92e5ffbdcac8229f321d9d https://git.kernel.org/stable/c/dfb15ddf3b65e0df2129f9756d1b4fa78 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56664 – bpf, sockmap: Fix race between element replace and close()
https://notcve.org/view.php?id=CVE-2024-56664
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix race between element replace and close() Element replace (with a socket different from the one stored) may race with socket's close() link popping & unlinking. __sock_map_delete() unconditionally unrefs the (wrong) element: // set map[0] = s0 map_update_elem(map, 0, s0) // drop fd of s0 close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // replace map[0] with s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) if (refcount_dec_and_test(&psock)) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) unlock_sock(sk) __sock_map_delete spin_lock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sk_test || sk_test == sk) // sk_test (s0) ! • https://git.kernel.org/stable/c/604326b41a6fb9b4a78b6179335decee0365cd8c https://git.kernel.org/stable/c/b015f19fedd2e12283a8450dd0aefce49ec57015 https://git.kernel.org/stable/c/bf2318e288f636a882eea39f7e1015623629f168 https://git.kernel.org/stable/c/ed1fc5d76b81a4d681211333c026202cad4d5649 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-56662 – acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl
https://notcve.org/view.php?id=CVE-2024-56662
In the Linux kernel, the following vulnerability has been resolved: acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl Fix an issue detected by syzbot with KASAN: BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/ core.c:416 [inline] BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0 drivers/acpi/nfit/core.c:459 The issue occurs in cmd_to_func when the call_pkg->nd_reserved2 array is accessed without verifying that call_pkg points to a buffer that is appropriately sized as a struct nd_cmd_pkg. This can lead to out-of-bounds access and undefined behavior if the buffer does not have sufficient space. To address this, a check was added in acpi_nfit_ctl() to ensure that buf is not NULL and that buf_len is less than sizeof(*call_pkg) before accessing it. This ensures safe access to the members of call_pkg, including the nd_reserved2 array. • https://git.kernel.org/stable/c/ebe9f6f19d80d8978d16078dff3d5bd93ad8d102 https://git.kernel.org/stable/c/63108f2a408abea7ecab063efa0f398da4d0d14b https://git.kernel.org/stable/c/f5878c4f084dc6b1386dad03970bb61ad5e9dc4b https://git.kernel.org/stable/c/0c79794474895dbbc3c52225f7e9f73cfecbb7dd https://git.kernel.org/stable/c/616aa5f3c86e0479bcbb81e41c08c43ff32af637 https://git.kernel.org/stable/c/bbdb3307f609ec4dc9558770f464ede01fe52aed https://git.kernel.org/stable/c/143f723e9eb4f0302ffb7adfdc7ef77eab3f68e0 https://git.kernel.org/stable/c/e08dc2dc3c3f7938df0e4476fe3e6fdec •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56661 – tipc: fix NULL deref in cleanup_bearer()
https://notcve.org/view.php?id=CVE-2024-56661
In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL deref in cleanup_bearer() syzbot found [1] that after blamed commit, ub->ubsock->sk was NULL when attempting the atomic_dec() : atomic_dec(&tipc_net(sock_net(ub->ubsock->sk))->wq_count); Fix this by caching the tipc_net pointer. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] CPU: 0 UID: 0 PID: 5896 Comm: kworker/0:3 Not tainted 6.13.0-rc1-next-20241203-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events cleanup_bearer RIP: 0010:read_pnet include/net/net_namespace.h:387 [inline] RIP: 0010:sock_net include/net/sock.h:655 [inline] RIP: 0010:cleanup_bearer+0x1f7/0x280 net/tipc/udp_media.c:820 Code: 18 48 89 d8 48 c1 e8 03 42 80 3c 28 00 74 08 48 89 df e8 3c f7 99 f6 48 8b 1b 48 83 c3 30 e8 f0 e4 60 00 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 df e8 1a f7 99 f6 49 83 c7 e8 48 8b 1b RSP: 0018:ffffc9000410fb70 EFLAGS: 00010206 RAX: 0000000000000006 RBX: 0000000000000030 RCX: ffff88802fe45a00 RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffc9000410f900 RBP: ffff88807e1f0908 R08: ffffc9000410f907 R09: 1ffff92000821f20 R10: dffffc0000000000 R11: fffff52000821f21 R12: ffff888031d19980 R13: dffffc0000000000 R14: dffffc0000000000 R15: ffff88807e1f0918 FS: 0000000000000000(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556ca050b000 CR3: 0000000031c0c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 • https://git.kernel.org/stable/c/4e69457f9dfae67435f3ccf29008768eae860415 https://git.kernel.org/stable/c/650ee9a22d7a2de8999fac2d45983597a0c22359 https://git.kernel.org/stable/c/d2a4894f238551eae178904e7f45af87577074fd https://git.kernel.org/stable/c/d62d5180c036eeac09f80660edc7a602b369125f https://git.kernel.org/stable/c/d00d4470bf8c4282617a3a10e76b20a9c7e4cffa https://git.kernel.org/stable/c/e48b211c4c59062cb6dd6c2c37c51a7cc235a464 https://git.kernel.org/stable/c/6a2fa13312e51a621f652d522d7e2df7066330b6 https://git.kernel.org/stable/c/d1d4dfb189a115734bff81c411bc58d9e •