CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56672 – blk-cgroup: Fix UAF in blkcg_unpin_online()
https://notcve.org/view.php?id=CVE-2024-56672
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix UAF in blkcg_unpin_online() blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To walk up, it uses blkcg_parent(blkcg) but it was calling that after blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the following UAF: ================================================================== BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270 Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117 CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 Workqueue: cgwb_release cgwb_release_workfn Call Trace: <TASK> dump_stack_lvl+0x27/0x80 print_report+0x151/0x710 kasan_report+0xc0/0x100 blkcg_unpin_online+0x15a/0x270 cgwb_release_workfn+0x194/0x480 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> ... Freed by task 1944: kasan_save_track+0x2b/0x70 kasan_save_free_info+0x3c/0x50 __kasan_slab_free+0x33/0x50 kfree+0x10c/0x330 css_free_rwork_fn+0xe6/0xb30 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 Note that the UAF is not easy to trigger as the free path is indirected behind a couple RCU grace periods and a work item execution. I could only trigger it with artifical msleep() injected in blkcg_unpin_online(). Fix it by reading the parent pointer before destroying the blkcg's blkg's. • https://git.kernel.org/stable/c/4308a434e5e08c78676aa66bc626ef78cbef0883 https://git.kernel.org/stable/c/64afc6fe24c9896c0153e5a199bcea241ecb0d5c https://git.kernel.org/stable/c/5baa28569c924d9a90d036c2aaab79f791fedaf8 https://git.kernel.org/stable/c/29d1e06560f0f6179062ac638b4064deb637d1ad https://git.kernel.org/stable/c/86e6ca55b83c575ab0f2e105cf08f98e58d3d7af •
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 •