Vulnerabilidades

Se descubrió un problema en UCI IDOL 2 (también conocido como uciIDOL o IDOL2) hasta 2.12. Los datos se envían entre el cliente y el servidor con cifrado. Sin embargo, la clave se deriva de la cadena "(c)2007 UCI Software GmbH B.Boll" (sin comillas). La clave es estática y está codificada. Con el acceso a los mensajes, esto da como resultado que un atacante descifre y cifre los mensajes. Por lo tanto, permite ataques de intermediario pasivos y activos.

Mirai botnet hasta el 19 de agosto de 2024 maneja mal las conexiones TCP simultáneas al servidor CNC (comando y control). Las sesiones no autenticadas permanecen abiertas, lo que provoca un consumo de recursos. Por ejemplo, un atacante puede enviar un nombre de usuario reconocido (como root) o puede enviar datos arbitrarios.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: x86/mmu: haga que el token apf sea distinto de cero para corregir el error En la lógica de error de página asíncrona actual, cuando una página está lista, KVM se basa en kvm_arch_can_dequeue_async_page_present() para determinar si se debe entregar un evento LISTO para el Invitado. Esta función prueba el valor del token de la estructura kvm_vcpu_pv_apf_data, que el kernel invitado debe restablecer a cero cuando el invitado finaliza un evento READY. Si el valor es cero, significa que se realizó un evento READY, por lo que el KVM puede entregar otro. Pero kvm_arch_setup_async_pf() puede producir un token válido con valor cero, lo que se confunde con la mención anterior y puede provocar la pérdida de este evento READY. Este error puede causar que la tarea se bloquee para siempre en Guest: INFORMACIÓN: tarea de estrés:7532 bloqueada durante más de 1254 segundos. Not tainted 5.10.0 #16 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:estrés estado:D pila: 0 pid: 7532 ppid: 1409 banderas:0x00000080 Seguimiento de llamadas: __schedule+0x1e7/0x650 Schedule+0x46/0xb0 kvm_async_pf_task_wait_schedule+0xad/0xe0 ? exit_to_user_mode_prepare+0x60/0x70 __kvm_handle_async_pf+0x4f/0xb0 ? asm_exc_page_fault+0x8/0x30 exc_page_fault+0x6f/0x110? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x402d00 RSP: 002b:00007ffd31912500 EFLAGS: 00010206 RAX: 0000000000071000 RBX: ffffffff RCX: 00000000021a32b0 RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0 RBP: 00000000021262b0 R08: 03 R09: 0000000000000086 R10: 000000000000000000EB R11: 00007FEFBDF2BAA0 R12: 00000000000000000000 R13: 0000000000000002 R14: 000000000007D000 R15: 00000000001000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: Maneja la falla al registrar correctamente el sensor con zona térmica. Si se intenta acceder a un sensor con zona térmica y falla, la llamada a devm_thermal_zone_of_sensor_register() puede devolver -ENODEV. Esto puede provocar fallos similares a los siguientes. No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000003cd... Error interno: Ups: 96000021 [#1] PREEMPT SMP... pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: mutex_lock+0x18/0x60 lr: Thermal_zone_device_update+0x40/0x2e0 sp: ffff800014c4fc60 x29: ffff800014c4fc60 x28: ffff365ee3f6e000 x27: ffffdde218426790 x26: f6e000 x25: 0000000000000000 x24: ffff365ee3f6e000 x23: ffffdde218426870 x22: ffff365ee3f6e000 x21: 00000000000003cd x20: ffff365ee8bf3308 ffffffffffffffff x18: 0000000000000000 x17: ffffdde21842689c x16: ffffdde1cb7a0b7c x15: 0000000000000040 x14: ffffdde21a4889a0 x13: 0000000000000228 x12: 00000000000000 x11: 0000000000000000 x10: 0000000000000000 x9: 0000000000000000 x8: 0000000001120000 x7: 0000000000000001 x6: 0000 000000000000 x5: 0068000878e20f07 x4: 0000000000000000 x3: 00000000000003cd x2: ffff365ee3f6e000 x1: 0000000000000000 x0: 00000000000003cd Rastreo de llamadas: mutex_lock+0x18/0x60 hwmon_notify_event+0xfc/0x110 0xffffdde1cb7a0a90 0xffffdde1cb7a0b7c thread_fn+0x2c/0xa0 irq_thread+0x134/0x240 kthread+0x178/0x190 ret_from_fork+0x10/0x20 Código: d503201f d503201f d2800001 aa0103e4 (c8e47c02 ) Jon Hunter informa que la secuencia de llamada exacta es: hwmon_notify_event() --> hwmon_thermal_notify() --> Thermal_zone_device_update() --> update_temperature() --> mutex_lock() El núcleo de hwmon necesita manejar todos los errores devueltos por las llamadas a devm_thermal_zone_of_sensor_register(). Si la llamada falla con -ENODEV, informe que el sensor no estaba conectado a una zona térmica pero continúe registrando el dispositivo hwmon.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: io_uring: agregue un punto de programación en io_add_buffers() Realizar bucles ~65535 veces al realizar llamadas kmalloc() puede desencadenar bloqueos suaves, especialmente con funciones DEBUG (como KASAN). [253.536212] perro guardián: ERROR: bloqueo suave - ¡CPU#64 bloqueada durante 26 segundos! [b219417889:12575] [253.544433] Módulos vinculados en: vfat fat i2c_mux_pca954x i2c_mux spidev cdc_acm xhci_pci xhci_hcd sha3_generic gq(O) [253.544451] CPU: 64 PID: 12575 Comm: 417889 Contaminado: GSO 5.17.0-smp-DEV #801 [ 253.544457] RIP: 0010:kernel_text_address (./include/asm-generic/sections.h:192 ./include/linux/kallsyms.h:29 kernel/extable.c:67 kernel/extable.c:98) [ 253.544464] Código: 0f 93 c0 48 c7 c1 e0 63 d7 a4 48 39 cb 0f 92 c1 20 c1 0f b6 c1 5b 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 48 89 fb <48> c7 c0 00 00 80 a0 41 be 01 00 00 00 48 39 c7 72 0c 48 c7 c0 40 [ 253.544468] RSP: 0018:ffff8882d8baf4c0 EFLAGS: 00000246 [ 253.544471] RAX: 1ffff1105b1 75e00 RBX: fffffffa13ef09a RCX: 00000000a13ef001 [ 253.544474] RDX: fffffffa13ef09a RSI: ffff8882d8baf558 RDI: fffffffa13ef09a [ 253.544476] RBP: ffff8882d8baf4d8 R08: ffff8882d8baf5e0 R09: 00000000000000004 [ 253.544479] R10: ffff8882d8baf5e8 R11: 0d59a50 R12: ffff8882eab20380 [ 253.544481] R13: fffffffa0d59a50 R14: dffffc0000000000 R15: 1ffff1105b175eb0 [ 253.544483] FS: 00000000016d3380( 0000) GS: ffff88af48c00000(0000) knlGS:00000000000000000 [ 253.544486] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 253.544488] CR2: af0f0 CR3: 00000002eabfa004 CR4: 00000000003706e0 [ 253.544491] DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 253.544 492] DR3 : 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 253.544494] Seguimiento de llamadas: [ 253.544496] [ 253.544498] ? io_queue_sqe (fs/io_uring.c:7143) [ 253.544505] __kernel_text_address (kernel/extable.c:78) [ 253.544508] unwind_get_return_address (arch/x86/kernel/unwind_frame.c:19) [ 253.544514] arch_stack_walk (arch/ x86/núcleo /stacktrace.c:27) [253.544517]? io_queue_sqe (fs/io_uring.c:7143) [ 253.544521] stack_trace_save (kernel/stacktrace.c:123) [ 253.544527] ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/ common.c:436 mm/kasan/common.c:515) [ 253.544531] ? ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515) [ 253.544533] ? __kasan_kmalloc (mm/kasan/common.c:524) [253.544535]? kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567) [ 253.544541] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828) [253.544544]? __io_queue_sqe (fs/io_uring.c:?) [ 253.544551] __kasan_kmalloc (mm/kasan/common.c:524) [ 253.544553] kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567) [ 253.544556] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828) [ 253.544560] io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828 ) [253.544564] ? __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) [ 253.544567] ? __kasan_slab_alloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) [ 253.544569] ? kmem_cache_alloc_bulk (mm/slab.h:732 mm/slab.c:3546) [ 253.544573] ? __io_alloc_req_refill (fs/io_uring.c:2078) [253.544578]? io_submit_sqes (fs/io_uring.c:7441) [253.544581]? __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uring.c:10096) [253.544584]? __x64_sys_io_uring_enter (fs/io_uring.c:10096) [253.544587]? do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) [253.544590]? entrada_SYSCALL_64_after_hwframe (??:?) [ 253.544596] __io_queue_sqe (fs/io_uring.c:?) [ 253.544600] io_queue_sqe (fs/io_uring.c:7143) [ 253.544603] io_submit_sqe (fs/io_uring.c :?) [ 253.544608] io_submit_sqes (fs/io_uring.c:?) [ 253.544612] __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uri ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: CDC-NCM: evitar desbordamiento en la comprobación de cordura Un dispositivo roto puede dar un desplazamiento extremo como 0xFFF0 y una longitud razonable para un fragmento. En la verificación de cordura tal como está formulada ahora, esto creará un desbordamiento de enteros, anulando la verificación de cordura. Tanto el desplazamiento como el desplazamiento + len deben comprobarse de tal manera que no pueda producirse un desbordamiento. Y esas cantidades deberían estar sin firmar.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: agregar puntos de programación en operaciones por lotes syzbot informó varios bloqueos suaves causados por operaciones por lotes de bpf. INFORMACIÓN: tarea kworker/1:1:27 bloqueada durante más de 140 segundos. INFORMACIÓN: tarea colgada en rcu_barrier Nada impide que las operaciones por lotes procesen una gran cantidad de datos, necesitamos agregar puntos de programación en ellas. Tenga en cuenta que las llamadas de Maybe_wait_bpf_programs(map) desde generic_map_delete_batch() se pueden factorizar moviendo la llamada después del ciclo. Esto se hará más adelante en el árbol siguiente una vez que combinemos esta solución, a menos que haya una opinión firme sobre realizar esta optimización antes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: soluciona el fallo debido a copy_map_value incorrecto Cuando tanto bpf_spin_lock como bpf_timer están presentes en un valor de mapa BPF, copy_map_value necesita eludir ambos objetos al copiar un valor dentro y fuera del mapa. Sin embargo, el código actual no establece s_off y t_off en copy_map_value, lo que provoca un bloqueo cuando, por ejemplo, bpf_spin_lock se coloca en el valor del mapa con bpf_timer, ya que la llamada a bpf_map_update_elem podrá sobrescribir el otro objeto de temporizador. Cuando el problema no se soluciona, una sobrescritura puede producir el siguiente símbolo: [root@(none) bpf]# ./test_progs -t timer_crash [15.930339] bpf_testmod: cargando el núcleo de contaminación del módulo fuera del árbol. [16.037849] ================================================= =================== [16.038458] ERROR: KASAN: acceso a memoria de usuario en __pv_queued_spin_lock_slowpath+0x32b/0x520 [16.038944] Escritura de tamaño 8 en la dirección 0000000000043ec0 por tarea test_progs /325 [ 16.039399] [ 16.039514] CPU: 0 PID: 325 Comm: test_progs Contaminado: G OE 5.16.0+ #278 [ 16.039983] Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS ArchLinux 1.15.0- 1 01/04/2014 [ 16.040485] Seguimiento de llamadas: [ 16.040645] [ 16.040805] dump_stack_lvl+0x59/0x73 [ 16.041069] ? __pv_queued_spin_lock_slowpath+0x32b/0x520 [ 16.041427] kasan_report.cold+0x116/0x11b [ 16.041673] ? __pv_queued_spin_lock_slowpath+0x32b/0x520 [16.042040] __pv_queued_spin_lock_slowpath+0x32b/0x520 [16.042328] ? memcpy+0x39/0x60 [16.042552]? pv_hash+0xd0/0xd0 [16.042785]? lockdep_hardirqs_off+0x95/0xd0 [ 16.043079] __bpf_spin_lock_irqsave+0xdf/0xf0 [ 16.043366] ? bpf_get_current_comm+0x50/0x50 [16.043608]? jhash+0x11a/0x270 [ 16.043848] bpf_timer_cancel+0x34/0xe0 [ 16.044119] bpf_prog_c4ea1c0f7449940d_sys_enter+0x7c/0x81 [ 16.044500] 7838_0+0x36/0x1000 [ 16.044836] __x64_sys_nanosleep+0x5/0x140 [ 16.045119] do_syscall_64+0x59/0x80 [ 16.045377] ? lock_is_held_type+0xe4/0x140 [16.045670]? irqentry_exit_to_user_mode+0xa/0x40 [16.046001]? mark_held_locks+0x24/0x90 [16.046287]? asm_exc_page_fault+0x1e/0x30 [16.046569]? asm_exc_page_fault+0x8/0x30 [16.046851]? lockdep_hardirqs_on+0x7e/0x100 [16.047137] Entry_SYSCALL_64_after_hwframe+0x44/0xae [16.047405] RIP: 0033:0x7f9e4831718d [16.047602] Código: b4 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b3 6c 0c 00 f7 d8 64 89 01 48 [ 16.048764] : 002b:00007fff488086b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000023 [ 16.049275] RAX: ffffffffffffffda RBX: 00007f9e48683740 RCX: 00007f9e4831718d [ 16.049747] RDX: 000000000000 RSI: 0000000000000000 RDI: 00007fff488086d0 [ 16.050225] RBP: 00007fff488086f0 R08: 00007fff488085d7 R09: 00007f9e4cb594a0 [ 16.050648] R10: 0000000000000000 R11: 0000000000000206 R12: 00007f9e484cde30 [ 16.051124] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 16.051608 ] [ 16.051762] ========================= ============================================

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrige el restablecimiento y la eliminación simultáneos de VF. El commit c503e63200c6 ("ice: deja de procesar mensajes VF durante el desmontaje") introdujo un indicador de estado del controlador, ICE_VF_DEINIT_IN_PROGRESS, cuyo objetivo es evitar algunos problemas con el manejo simultáneo de mensajes de VF mientras se derriban los VF. Este cambio fue motivado por accidentes causados al derribar y levantar VF en rápida sucesión. Resulta que la solución en realidad introduce problemas con el controlador VF causados porque el PF ya no responde a ningún mensaje enviado por el VF durante su rutina .remove. Esto da como resultado que el VF elimine potencialmente su memoria DMA antes de que el PF haya cerrado las colas de dispositivos. Además, la solución en realidad no resuelve los problemas de concurrencia dentro del controlador Ice. Es posible que un VF inicie un reinicio justo antes de que el driver de hielo elimine los VF. Esto puede provocar que la tarea de eliminación funcione simultáneamente mientras se restablece el VF. Esto da como resultado una corrupción de memoria similar y pánicos supuestamente solucionados por esa confirmación. Corrija esta simultaneidad desde la raíz protegiendo los flujos de reinicio y eliminación utilizando el VF cfg_lock existente. Esto garantiza que no podamos eliminar el VF mientras se estén realizando tareas críticas pendientes, como un mensaje virtchnl o un reinicio. Este cambio de bloqueo también soluciona la causa raíz solucionada originalmente mediante el commit c503e63200c6 ("ice: Detener el procesamiento de mensajes VF durante el desmontaje"), por lo que simplemente podemos revertirlo. Tenga en cuenta que mantuve estos dos cambios juntos porque simplemente revertir el compromiso original dejaría al driver vulnerable a peores condiciones de ejecución.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: configfs: arregla una ejecución en configfs_{,un}register_subsystem() Cuando configfs_register_subsystem() o configfs_unregister_subsystem() está ejecutando link_group() o unlink_group(), es posible que dos procesos agregar o eliminar la lista al mismo tiempo. Algunas intercalaciones desafortunadas de ellos pueden causar pánico en el kernel. Uno de los casos es: A --> B --> C --> DA <-- B <-- C <-- D eliminar list_head *B | eliminar list_head *C --------------------------------|------------- ---------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | desvincular_grupo desvincular_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // siguiente == C | siguiente->anterior = anterior | | siguiente->anterior = anterior anterior->siguiente = siguiente | | // anterior == B | prev->next = next Solucione esto agregando mutex al llamar a link_group() o unlink_group(), pero el configfs_subsystem principal es NULL cuando config_item es root. Entonces creo un mutex configfs_subsystem_mutex.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5: DR, corrigió slab-out-of-bounds en mlx5_cmd_dr_create_fte Al agregar una regla con 32 destinos, encontramos el siguiente problema de acceso fuera de banda: ERROR: KASAN: slab-out-of-bounds en mlx5_cmd_dr_create_fte+0x18ee/0x1e70 Este parche soluciona el problema aumentando los búferes asignados para acomodar las acciones necesarias y verificando la cantidad de acciones para evitar este problema cuando una regla con demasiadas acciones se proporciona.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: corrige la pérdida de memoria durante la actualización de objetos con estado. Los objetos con estado se pueden actualizar desde el plano de control. La lógica de transacción asigna un objeto temporal para este propósito. La función ->init fue llamada para este objeto, por lo que kfree() simple pierde recursos. Debemos llamar a la función ->destruir del objeto. nft_obj_destroy hace esto, pero también disminuye el recuento del módulo, pero la ruta de actualización no lo incrementa. Para evitar usar mayúsculas y minúsculas especiales en la versión del objeto de actualización, utilice module_get para el caso de actualización también y libérela mediante nft_obj_destroy().