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: 2EXPL: 0CVE-2024-56669 – iommu/vt-d: Remove cache tags before disabling ATS
https://notcve.org/view.php?id=CVE-2024-56669
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Remove cache tags before disabling ATS The current implementation removes cache tags after disabling ATS, leading to potential memory leaks and kernel crashes. Specifically, CACHE_TAG_DEVTLB type cache tags may still remain in the list even after the domain is freed, causing a use-after-free condition. This issue really shows up when multiple VFs from different PFs passed through to a single user-space process via vfio-pci. In such cases, the kernel may crash with kernel messages like: BUG: kernel NULL pointer dereference, address: 0000000000000014 PGD 19036a067 P4D 1940a3067 PUD 136c9b067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 74 UID: 0 PID: 3183 Comm: testCli Not tainted 6.11.9 #2 RIP: 0010:cache_tag_flush_range+0x9b/0x250 Call Trace: <TASK> ? __die+0x1f/0x60 ? page_fault_oops+0x163/0x590 ? • https://git.kernel.org/stable/c/3b1d9e2b2d6856eabf5faa12d20c97fef657999f https://git.kernel.org/stable/c/9a0a72d3ed919ebe6491f527630998be053151d8 https://git.kernel.org/stable/c/1f2557e08a617a4b5e92a48a1a9a6f86621def18 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-56667 – drm/i915: Fix NULL pointer dereference in capture_engine
https://notcve.org/view.php?id=CVE-2024-56667
In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix NULL pointer dereference in capture_engine When the intel_context structure contains NULL, it raises a NULL pointer dereference error in drm_info(). (cherry picked from commit 754302a5bc1bd8fd3b7d85c168b0a1af6d4bba4d) • https://git.kernel.org/stable/c/e8a3319c31a14aa9925418bc7813c2866903b2c6 https://git.kernel.org/stable/c/e07f9c92bd127f8835ac669d83b5e7ff59bbb40f https://git.kernel.org/stable/c/e6ebe4f14a267bc431d0eebab4f335c0ebd45977 https://git.kernel.org/stable/c/da0b986256ae9a78b0215214ff44f271bfe237c1 •
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 •