CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56671 – gpio: graniterapids: Fix vGPIO driver crash
https://notcve.org/view.php?id=CVE-2024-56671
In the Linux kernel, the following vulnerability has been resolved: gpio: graniterapids: Fix vGPIO driver crash Move setting irq_chip.name from probe() function to the initialization of "irq_chip" struct in order to fix vGPIO driver crash during bootup. Crash was caused by unauthorized modification of irq_chip.name field where irq_chip struct was initialized as const. This behavior is a consequence of suboptimal implementation of gpio_irq_chip_set_chip(), which should be changed to avoid casting away const qualifier. Crash log: BUG: unable to handle page fault for address: ffffffffc0ba81c0 /#PF: supervisor write access in kernel mode /#PF: error_code(0x0003) - permissions violation CPU: 33 UID: 0 PID: 1075 Comm: systemd-udevd Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7 #1 Hardware name: Intel Corporation Kaseyville RP/Kaseyville RP, BIOS KVLDCRB1.PGS.0026.D73.2410081258 10/08/2024 RIP: 0010:gnr_gpio_probe+0x171/0x220 [gpio_graniterapids] • https://git.kernel.org/stable/c/e631cab10c6b287a33c35953e6dbda1f7f89bc1f https://git.kernel.org/stable/c/eb9640fd1ce666610b77f5997596e9570a36378f •
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: 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 •