CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50155 – netdevsim: use cond_resched() in nsim_dev_trap_report_work()
https://notcve.org/view.php?id=CVE-2024-50155
In the Linux kernel, the following vulnerability has been resolved: netdevsim: use cond_resched() in nsim_dev_trap_report_work() I am still seeing many syzbot reports hinting that syzbot might fool nsim_dev_trap_report_work() with hundreds of ports [1] Lets use cond_resched(), and system_unbound_wq instead of implicit system_wq. [1] INFO: task syz-executor:20633 blocked for more than 143 seconds. Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor state:D stack:25856 pid:20633 tgid:20633 ppid:1 flags:0x00004006 ... NMI backtrace for cpu 1 CPU: 1 UID: 0 PID: 16760 Comm: kworker/1:0 Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events nsim_dev_trap_report_work RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:210 Code: 89 fb e8 23 00 00 00 48 8b 3d 04 fb 9c 0c 48 89 de 5b e9 c3 c7 5d 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <f3> 0f 1e fa 48 8b 04 24 65 48 8b 0c 25 c0 d7 03 00 65 8b 15 60 f0 RSP: 0018:ffffc90000a187e8 EFLAGS: 00000246 RAX: 0000000000000100 RBX: ffffc90000a188e0 RCX: ffff888027d3bc00 RDX: ffff888027d3bc00 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88804a2e6000 R08: ffffffff8a4bc495 R09: ffffffff89da3577 R10: 0000000000000004 R11: ffffffff8a4bc2b0 R12: dffffc0000000000 R13: ffff88806573b503 R14: dffffc0000000000 R15: ffff8880663cca00 FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc90a747f98 CR3: 000000000e734000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 000000000000002b DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 spin_unlock_bh include/linux/spinlock.h:396 [inline] nsim_dev_trap_report drivers/net/netdevsim/dev.c:820 [inline] nsim_dev_trap_report_work+0x75d/0xaa0 drivers/net/netdevsim/dev.c:850 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netdevsim: use cond_resched() en nsim_dev_trap_report_work() Todavía veo muchos informes de syzbot que insinúan que syzbot podría engañar a nsim_dev_trap_report_work() con cientos de puertos [1] Usemos cond_resched() y system_unbound_wq en lugar de system_wq implícito. [1] INFORMACIÓN: tarea syz-executor:20633 bloqueada durante más de 143 segundos. No contaminada 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deshabilita este mensaje. tarea:syz-executor estado:D pila:25856 pid:20633 tgid:20633 ppid:1 indicadores:0x00004006 ... Seguimiento NMI para CPU 1 CPU: 1 UID: 0 PID: 16760 Comm: kworker/1:0 No contaminado 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Cola de trabajo: eventos nsim_dev_trap_report_work RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:210 Código: 89 fb e8 23 00 00 00 48 8b 3d 04 fb 9c 0c 48 89 de 5b e9 c3 c7 5d 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1e fa 48 8b 04 24 65 48 8b 0c 25 c0 d7 03 00 65 8b 15 60 f0 RSP: 0018:ffffc90000a187e8 EFLAGS: 00000246 RAX: 00000000000000100 RBX: ffffc90000a188e0 RCX: ffff888027d3bc00 RDX: ffff888027d3bc00 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88804a2e6000 R08: ffffffff8a4bc495 R09: ffffffff89da3577 R10: 0000000000000004 R11: ffffffff8a4bc2b0 R12: dffffc0000000000 R13: ffff88806573b503 R14: dffffc0000000000 R15: ffff8880663cca00 FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc90a747f98 CR3: 000000000e734000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 000000000000002b DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Seguimiento de llamadas: __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 spin_unlock_bh include/linux/spinlock.h:396 [en línea] nsim_dev_trap_report drivers/net/netdevsim/dev.c:820 [en línea] nsim_dev_trap_report_work+0x75d/0xaa0 drivers/net/netdevsim/dev.c:850 process_one_work kernel/workqueue.c:3229 [en línea] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 subproceso de trabajo+0x870/0xd30 kernel/workqueue.c:3391 subproceso de trabajo+0x2f0/0x390 kernel/kthread.c:389 ret_de_la_bifurcación+0x4b/0x80 arch/x86/kernel/process.c:147 ret_de_la_bifurcación_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 • https://git.kernel.org/stable/c/0193e0660cc6689c794794b471492923cfd7bfbc https://git.kernel.org/stable/c/6eecddd9c3c8d6e3a097531cdc6d500335b35e46 https://git.kernel.org/stable/c/ba5e1272142d051dcc57ca1d3225ad8a089f9858 https://git.kernel.org/stable/c/d91964cdada76740811b7c621239f9c407820dbc https://git.kernel.org/stable/c/24973f4b64f93232a48fe78029385de762a2418d https://git.kernel.org/stable/c/681ce79ab6fba2f8d1c5ea60239f0086baebd0d3 https://git.kernel.org/stable/c/32f054f93937b548c61b3bf57d8f4aefc50f3b16 https://git.kernel.org/stable/c/a1494d532e28598bde7a5544892ef9c7d •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50154 – tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().
https://notcve.org/view.php?id=CVE-2024-50154
In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). """ We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. """ The commit 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp/dccp: No use timer_pending() en reqsk_queue_unlink(). Martin KaFai Lau informó de un use-after-free [0] en reqsk_timer_handler(). """ Estamos viendo un use-after-free de un programa bpf adjunto a trace_tcp_retransmit_synack. El programa pasa el req->sk al ayudante del kernel bpf_sk_storage_get_tracing que comprueba si hay valores nulos antes de usarlo. """ El commit 83fccfc3940c ("inet: soluciona un posible bloqueo en reqsk_queue_unlink()") agregó timer_pending() en reqsk_queue_unlink() para no llamar a del_timer_sync() desde reqsk_timer_handler(), pero introdujo una pequeña ventana de carrera. Antes de que se llame al temporizador, expire_timers() llama a detach_timer(timer, true) para borrar timer->entry.pprev y lo marca como no pendiente. • https://git.kernel.org/stable/c/83fccfc3940c4a2db90fd7e7079f5b465cd8c6af https://git.kernel.org/stable/c/d3a1196bfc462943694623412d8e03aaf172bdc1 https://git.kernel.org/stable/c/8459d61fbf24967839a70235165673148c7c7f17 https://git.kernel.org/stable/c/5071beb59ee416e8ab456ac8647a4dabcda823b1 https://git.kernel.org/stable/c/997ae8da14f1639ce6fb66a063dab54031cd61b3 https://git.kernel.org/stable/c/51e34db64f4e43c7b055ccf881b7f3e0c31bb26d https://git.kernel.org/stable/c/e8c526f2bdf1845bedaf6a478816a3d06fa78b8f •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50153 – scsi: target: core: Fix null-ptr-deref in target_alloc_device()
https://notcve.org/view.php?id=CVE-2024-50153
In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in target_alloc_device() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->free_device(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba->backend->ops->free_device(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: target: core: Corregir null-ptr-deref en target_alloc_device() KASAN ha informado de un problema de null-ptr-deref: ERROR: KASAN: null-ptr-deref en target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e En target_alloc_device(), si falla la asignación de memoria para las colas dev, dev se liberará mediante dev->transport->free_device(), pero dev->transport no se inicializa en ese momento, lo que generará un problema de referencia de puntero nulo. Se soluciona este error liberando dev con hba->backend->ops->free_device(). • https://git.kernel.org/stable/c/008b936bbde3e87a611b3828a0d5d2a4f99026a0 https://git.kernel.org/stable/c/1526d9f10c6184031e42afad0adbdde1213e8ad1 https://git.kernel.org/stable/c/8c1e6717f60d31f8af3937c23c4f1498529584e1 https://git.kernel.org/stable/c/39e02fa90323243187c91bb3e8f2f5f6a9aacfc7 https://git.kernel.org/stable/c/895ab729425ef9bf3b6d2f8d0853abe64896f314 https://git.kernel.org/stable/c/b80e9bc85bd9af378e7eac83e15dd129557bbdb6 https://git.kernel.org/stable/c/14a6a2adb440e4ae97bee73b2360946bd033dadd https://git.kernel.org/stable/c/fca6caeb4a61d240f031914413fcc6953 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50152 – smb: client: fix possible double free in smb2_set_ea()
https://notcve.org/view.php?id=CVE-2024-50152
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix possible double free in smb2_set_ea() Clang static checker(scan-build) warning： fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory. 1304 | kfree(ea); | ^~~~~~~~~ There is a double free in such case: 'ea is initialized to NULL' -> 'first successful memory allocation for ea' -> 'something failed, goto sea_exit' -> 'first memory release for ea' -> 'goto replay_again' -> 'second goto sea_exit before allocate memory for ea' -> 'second memory release for ea resulted in double free'. Re-initialie 'ea' to NULL near to the replay_again label, it can fix this double free problem. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: se corrige una posible doble liberación en smb2_set_ea() Advertencia del comprobador estático de Clang (scan-build): fs/smb/client/smb2ops.c:1304:2: Intento de liberar memoria liberada. 1304 | kfree(ea); | ^~~~~~~~~ Hay una doble liberación en tal caso: 'ea se inicializa a NULL' -> 'primera asignación de memoria exitosa para ea' -> 'algo falló, goto sea_exit' -> 'primera liberación de memoria para ea' -> 'goto replay_again' -> 'segundo goto sea_exit antes de asignar memoria para ea' -> 'la segunda liberación de memoria para ea resultó en una doble liberación'. Reinicialice 'ea' a NULL cerca de la etiqueta replay_again, puede solucionar este problema de doble liberación. • https://git.kernel.org/stable/c/433042a91f9373241307725b52de573933ffedbf https://git.kernel.org/stable/c/4f1fffa2376922f3d1d506e49c0fd445b023a28e https://git.kernel.org/stable/c/b1813c220b76f60b1727984794377c4aa849d4c1 https://git.kernel.org/stable/c/c9f758ecf2562dfdd4adf12c22921b5de8366123 https://git.kernel.org/stable/c/19ebc1e6cab334a8193398d4152deb76019b5d34 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50151 – smb: client: fix OOBs when building SMB2_IOCTL request
https://notcve.org/view.php?id=CVE-2024-50151
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOBs when building SMB2_IOCTL request When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2_set_next_command(). SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the SMB2_IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2_set_next_command() will end up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? • https://git.kernel.org/stable/c/e77fe73c7e38c36145825d84cfe385d400aba4fd https://git.kernel.org/stable/c/6f0516ef1290da24b85461ed08a0938af7415e49 https://git.kernel.org/stable/c/ed31aba8ce93472d9e16f5cff844ae7c94e9601d https://git.kernel.org/stable/c/e07d05b7f5ad9a503d9cab0afde2ab867bb65470 https://git.kernel.org/stable/c/2ef632bfb888d1a14f81c1703817951e0bec5531 https://git.kernel.org/stable/c/b209c3a0bc3ac172265c7fa8309e5d00654f2510 https://git.kernel.org/stable/c/fe92ddc1c32d4474e605e3a31a4afcd0e7d765ec https://git.kernel.org/stable/c/1ab60323c5201bef25f2a3dc0ccc404d9 •