Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: arregla la pérdida de inodo en btrfs_iget() [ERROR] Hay un informe de error que indica que un reproductor syzbot puede provocar el siguiente inodo ocupado en el momento del desmontaje: Información BTRFS (dispositivo loop1): último desmontaje del sistema de archivos 1680000e-3c1e-4c46-84b6-56bd3909af50 VFS: Inodos ocupados después del desmontaje de loop1 (btrfs) ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/super.c:650! Oops: código de operación no válido: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 48168 Comm: syz-executor No contaminado 6.15.0-rc2-00471-g119009db2674 #2 PREEMPT(full) Nombre del hardware: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 RIP: 0010:generic_shutdown_super+0x2e9/0x390 fs/super.c:650 Rastreo de llamadas: kill_anon_super+0x3a/0x60 fs/super.c:1237 btrfs_kill_super+0x3b/0x50 fs/btrfs/super.c:2099 deactivate_locked_super+0xbe/0x1a0 fs/super.c:473 deactivate_super fs/super.c:506 [inline] deactivate_super+0xe2/0x100 fs/super.c:502 cleanup_mnt+0x21f/0x440 fs/namespace.c:1435 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop kernel/entry/common.c:114 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x269/0x290 kernel/entry/common.c:218 do_syscall_64+0xd4/0x250 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSA] Cuando btrfs_alloc_path() fallaba, btrfs_iget() regresaba directamente sin liberar el inodo ya asignado por btrfs_iget_locked(). Esto genera el inodo ocupado mencionado anteriormente y activa el error del kernel. [SOLUCIÓN] Corríjalo llamando a iget_failed() si btrfs_alloc_path() fallaba. Si encontramos un error en btrfs_read_locked_inode(), se llamará correctamente a iget_failed(), así que no hay de qué preocuparse. Aunque la limpieza de iget_failed() dentro de btrfs_read_locked_inode() supone una ruptura del esquema normal de gestión de errores, primero corregiremos el error obvio y lo adaptaremos a la versión anterior, y luego reescribiremos la gestión de errores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scmi: Equilibrar el recuento de referencias de dispositivos al destruir dispositivos. El uso de device_find_child() para buscar el dispositivo SCMI adecuado para destruir provoca un desequilibrio en el recuento de referencias de dispositivos, ya que device_find_child() llama a un método get_device() implícito: esto, a su vez, inhibe la llamada a los métodos de liberación proporcionados tras la destrucción de dispositivos. Como consecuencia, una de las estructuras que no se libera correctamente tras la destrucción es la estructura interna device_private dev->p, rellenada por el núcleo del subsistema de controladores. KMemleak detecta esta situación, ya que la carga/descarga de algún controlador SCMI provoca que los dispositivos relacionados se creen/destruyan sin llamar a ningún método device_release. objeto sin referencia 0xffff00000f583800 (tamaño 512): comm "insmod", pid 227, jiffies 4294912190 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6...... seguimiento inverso (crc 114e2eed): kmemleak_alloc+0xbc/0xd8 __kmalloc_cache_noprof+0x2dc/0x398 device_add+0x954/0x12d0 device_register+0x28/0x40 __scmi_device_create.part.0+0x1bc/0x380 scmi_device_create+0x2d0/0x390 scmi_create_protocol_devices+0x74/0xf8 scmi_device_request_notifier+0x1f8/0x2a8 notifier_call_chain+0x110/0x3b0 blocking_notifier_call_chain+0x70/0xb0 scmi_driver_register+0x350/0x7f0 0xffff80000a3b3038 do_one_initcall+0x12c/0x730 do_init_module+0x1dc/0x640 load_module+0x4b20/0x5b70 init_module_from_file+0xec/0x158 $ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0 device_add+0x954/0x12d0: kmalloc_noprof en include/linux/slab.h:901 (en línea por) kzalloc_noprof en include/linux/slab.h:1037 (en línea por) device_private_init en drivers/base/core.c:3510 (en línea por) device_add en drivers/base/core.c:3561 Equilibre el recuento de dispositivos emitiendo un put_device() en los dispositivos encontrados a través de device_find_child().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: plfxlc: Eliminar aserción errónea en plfxlc_mac_release. plfxlc_mac_release() afirma que mac->lock se mantiene. Esta aserción es incorrecta, ya que, incluso si fuera posible, no sería el comportamiento válido. La función se utiliza cuando falla la sonda o después de desconectar el dispositivo. En ambos casos, mac->lock no se puede mantener, ya que el controlador no está trabajando con el dispositivo en ese momento. Todas las funciones que usan mac->lock lo desbloquean justo después de mantenerlo. Tampoco es necesario mantener mac->lock para plfxlc_mac_release(), ya que los datos de mac no se ven afectados, excepto mac->flags, que se modifica automáticamente. Este error genera la siguiente advertencia: ================================================================== ADVERTENCIA: CPU: 0 PID: 127 en drivers/net/wireless/purelifi/plfxlc/mac.c:106 plfxlc_mac_release+0x7d/0xa0 Módulos vinculados: CPU: 0 PID: 127 Comm: kworker/0:2 No contaminado 6.1.124-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Cola de trabajo: usb_hub_wq hub_event RIP: 0010:plfxlc_mac_release+0x7d/0xa0 controladores/red/inalámbrico/purelifi/plfxlc/mac.c:106 Rastreo de llamadas: probe+0x941/0xbd0 drivers/net/wireless/purelifi/plfxlc/usb.c:694 usb_probe_interface+0x5c0/0xaf0 drivers/usb/core/driver.c:396 really_probe+0x2ab/0xcb0 drivers/base/dd.c:639 __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785 driver_probe_device+0x50/0x420 drivers/base/dd.c:815 __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943 bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429 __device_attach+0x359/0x570 drivers/base/dd.c:1015 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489 device_add+0xb48/0xfd0 drivers/base/core.c:3696 usb_set_configuration+0x19dd/0x2020 drivers/usb/core/message.c:2165 usb_generic_driver_probe+0x84/0x140 drivers/usb/core/generic.c:238 usb_probe_device+0x130/0x260 drivers/usb/core/driver.c:293 really_probe+0x2ab/0xcb0 drivers/base/dd.c:639 __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785 driver_probe_device+0x50/0x420 drivers/base/dd.c:815 __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943 bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429 __device_attach+0x359/0x570 drivers/base/dd.c:1015 bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489 device_add+0xb48/0xfd0 drivers/base/core.c:3696 usb_new_device+0xbdd/0x18f0 drivers/usb/core/hub.c:2620 hub_port_connect drivers/usb/core/hub.c:5477 [inline] hub_port_connect_change drivers/usb/core/hub.c:5617 [inline] port_event drivers/usb/core/hub.c:5773 [inline] hub_event+0x2efe/0x5730 drivers/usb/core/hub.c:5855 process_one_work+0x8a9/0x11d0 kernel/workqueue.c:2292 worker_thread+0xa47/0x1200 kernel/workqueue.c:2439 kthread+0x28d/0x320 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 ================================================================ Encontrado por el Centro de verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc64/ftrace: se corrige la carga de módulos sin entradas de función parcheables. get_stubs_size asume que siempre debe haber al menos una entrada de función parcheable, lo cual no siempre ocurre (módulos que exportan datos, pero no código); de lo contrario, devuelve -ENOEXEC y, por lo tanto, el encabezado de sección sh_size se establece en ese valor. Durante module_memory_alloc(), el tamaño se pasa a execmem_alloc() tras la alineación de página y, por lo tanto, se establece en cero, lo que provocará un error en la asignación (y, por lo tanto, en la carga del módulo), ya que __vmalloc_node_range() busca asignaciones de tamaño cero y devuelve null: [115.466896] module_64: cast_common: no contiene __patchable_function_entries. [ 115.469189] ------------[ cortar aquí ]------------ [ 115.469496] ADVERTENCIA: CPU: 0 PID: 274 en mm/vmalloc.c:3778 __vmalloc_node_range_noprof+0x8b4/0x8f0 ... [ 115.478574] ---[ fin del seguimiento 0000000000000000 ]--- [ 115.479545] execmem: no se puede asignar memoria Solucione esto eliminando la verificación por completo, ya que de todos modos no es útil propagar esto como un error hacia arriba.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu: Se corrigen dos problemas en iommu_copy_struct_from_user() En la revisión del asistente iommu_copy_struct_to_user(), Matt señaló que se debe rechazar un puntero NULL antes de desreferenciarlo: https://lore.kernel.org/all/86881827-8E2D-461C-BDA3-FA8FD14C343C@nvidia.com Y Alok señaló un error tipográfico al mismo tiempo: https://lore.kernel.org/all/480536af-6830-43ce-a327-adbd13dc3f1d@oracle.com Dado que ambos problemas se copiaron de iommu_copy_struct_from_user(), corríjalos primero en el encabezado actual.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: corrección del problema "use-after-free" al cerrar sesión. El objeto sess->user puede estar siendo utilizado por otro hilo, por ejemplo, si otra conexión ha enviado una solicitud de configuración de sesión para enlazarse a la sesión que se está liberando. El controlador de esa conexión podría estar en la función smb2_sess_setup, que utiliza sess->user.

IBM Security ReaQta EDR 3.12 podría permitir que un atacante realice acciones no autorizadas debido a una validación incorrecta del certificado SSL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: usar sock_gen_put() cuando sk_state es TCP_TIME_WAIT Es posible que un puntero de tipo struct inet_timewait_sock sea devuelto desde las funciones __inet_lookup_established() y __inet6_lookup_established(). Esto puede causar un bloqueo cuando el puntero devuelto es de tipo struct inet_timewait_sock y se llama a sock_put() en él. La siguiente es una pila de llamadas de bloqueo que muestra que se accede a sk->sk_wmem_alloc en sk_free() durante la llamada a sock_put() en un puntero struct inet_timewait_sock. Para evitar este problema, use sock_gen_put() en lugar de sock_put() cuando sk->sk_state es TCP_TIME_WAIT. mrdump.ko ipanic() + 120 vmlinux notifier_call_chain(nr_to_call=-1, nr_calls=0) + 132 vmlinux atomic_notifier_call_chain(val=0) + 56 vmlinux panic() + 344 vmlinux add_taint() + 164 vmlinux end_report() + 136 vmlinux kasan_report(size=0) + 236 vmlinux report_tag_fault() + 16 vmlinux do_tag_recovery() + 16 vmlinux __do_kernel_fault() + 88 vmlinux do_bad_area() + 28 vmlinux do_tag_check_fault() + 60 vmlinux do_mem_abort() + 80 vmlinux el1_abort() + 56 vmlinux el1h_64_sync_handler() + 124 vmlinux > 0xFFFFFFC080011294() vmlinux __lse_atomic_fetch_add_release(v=0xF2FFFF82A896087C) vmlinux __lse_atomic_fetch_sub_release(v=0xF2FFFF82A896087C) vmlinux arch_atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C) + 8 vmlinux raw_atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C) + 8 vmlinux atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C) + 8 vmlinux __refcount_sub_and_test(i=1, r=0xF2FFFF82A896087C, p anterior=0) + 8 vmlinux __refcount_dec_and_test(r=0xF2FFFF82A896087C, p anterior=0) + 8 vmlinux refcount_dec_and_test(r=0xF2FFFF82A896087C) + 8 vmlinux sk_free(sk=0xF2FFFF82A8960700) + 28 vmlinux sock_put() + 48 vmlinux tcp6_check_fraglist_gro() + 236 vmlinux tcp6_gro_receive() + 624 vmlinux ipv6_gro_receive() + 912 vmlinux dev_gro_receive() + 1116 vmlinux napi_gro_receive() + 196 ccmni.ko ccmni_rx_callback() + 208 ccmni.ko ccmni_queue_recv_skb() + 388 ccci_dpmaif.ko dpmaif_rxq_push_thread() + 1088 vmlinux kthread() + 268 vmlinux 0xFFFFFFC08001F30C()

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: spi-mem: Agregar corrección para evitar el error de división Para algunas operaciones de memoria flash SPI, los bytes ficticios no son obligatorios. Por ejemplo, en dispositivos de memoria flash Winbond SPINAND, las variantes de operación `write_cache` y `update_cache` tienen cero bytes ficticios. Calcular la duración de las operaciones de memoria SPI con cero bytes ficticios causa un error de división cuando se calcula `ncycles` en spi_mem_calc_op_duration(). Agregar cambios para omitir el cálculo de 'ncylcles' para cero bytes ficticios. El siguiente error de división se corrige con este cambio: Oops: error de división: 0000 [#1] PREEMPT SMP NOPTI ... ? do_trap+0xdb/0x100 ? do_error_trap+0x75/0xb0 ? spi_mem_calc_op_duration+0x56/0xb0 ? Error de división de error de exc. +0x3b/0x70 ? Duración de operación de cálculo de memoria spi +0x56/0xb0 ? Error de división de error de asm de exc. +0x1b/0x20 ? Duración de operación de cálculo de memoria spi +0x56/0xb0 ? Variante de operación de selección de spinand +0xee/0x190 [spinand] Coincidencia de spinand e inicialización +0x13e/0x1a0 [spinand] Coincidencia de fabricante de spinand +0x6e/0xa0 [spinand] Sonda de spinand +0x357/0x7f0 [spinand] ? Activación de Kernfs +0x87/0xd0 Sonda de memoria spi +0x7a/0xb0 Sonda spi +0x7d/0x130

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_en: Corregir la ruta de manejo de errores en bnxt_init_chip() WARN_ON() se activa en __flush_work() si bnxt_init_chip() falla porque llamamos a cancel_work_sync() en el trabajo de atenuación que no se ha inicializado. ADVERTENCIA: CPU: 37 PID: 5223 en kernel/workqueue.c:4201 __flush_work.isra.0+0x212/0x230 El controlador se basa en el bit BNXT_STATE_NAPI_DISABLED para comprobar si el trabajo de atenuación ya se ha cancelado. Pero en la ruta bnxt_open(), BNXT_STATE_NAPI_DISABLED no está configurado y esto hace que la ruta de error piense que necesita cancelar el trabajo de atenuación no inicializado. Corríjalo configurando BNXT_STATE_NAPI_DISABLED durante la inicialización. El bit se borrará cuando habilitemos NAPI e inicialicemos el trabajo de atenuación.

Existe una vulnerabilidad de inyección SQL ciega no autenticada en RSI Queue Management System v3.0 dentro del parámetro TaskID del controlador de solicitudes GET. Los atacantes pueden inyectar remotamente payloads SQL con retardo temporal para inducir retrasos en la respuesta del servidor, lo que permite la inferencia basada en el tiempo y la extracción iterativa de contenido confidencial de la base de datos sin autenticación.

vCenter Server presenta una vulnerabilidad de ejecución de comandos autenticados. Un agente malicioso con privilegios para crear o modificar alarmas y ejecutar scripts podría aprovechar esta vulnerabilidad para ejecutar comandos arbitrarios en vCenter Server.