Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tun: Se corrige el use after free en tun_detach() syzbot informó use after free en tun_detach() [1]. Esto provoca un seguimiento de llamadas como el siguiente: ==================================================================== ERROR: KASAN: use after free en notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 Lectura de tamaño 8 en la dirección ffff88807324e2a8 por la tarea syz-executor.0/3673 CPU: 0 PID: 3673 Comm: syz-executor.0 No contaminado 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 26/10/2022 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [en línea] print_report+0x15e/0x461 mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942 call_netdevice_notifiers_extack net/core/dev.c:1983 [en línea] llamar_notificadores_dispositivos_de_red net/core/dev.c:1997 [en línea] netdev_wait_allrefs_any net/core/dev.c:10237 [en línea] netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351 tun_detach drivers/net/tun.c:704 [en línea] tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467 __fput+0x27c/0xa90 fs/file_table.c:320 tarea_trabajo_ejecutar+0x16f/0x270 kernel/tarea_trabajo.c:179 salir_tarea_trabajo incluir/linux/tarea_trabajo.h:38 [en línea] hacer_salir+0xb3d/0x2a30 kernel/exit.c:820 hacer_grupo_salir+0xd4/0x2a0 kernel/exit.c:950 obtener_señal+0x21b1/0x2440 kernel/señal.c:2858 arch_hacer_señal_o_reiniciar+0x86/0x2300 arch/x86/kernel/signal.c:869 bucle_salir_a_modo_usuario kernel/entry/common.c:168 [en línea] preparar_salir_a_modo_usuario+0x15f/0x250 kernel/entry/common.c:203 __syscall_salir_a_modo_usuario_trabajo kernel/entry/common.c:285 [en línea] syscall_salir_a_modo_usuario+0x1d/0x50 kernel/entry/common.c:296 La causa del problema es que sock_put() de __tun_detach() descarta el último recuento de referencias para struct net y luego notifier_call_chain() de netdev_state_change() accede a ese struct net. Este parche corrige el problema llamando a sock_put() desde tun_detach() después de que se hayan realizado todos los accesos necesarios para struct net.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net:hsr: Se corrige un posible use after free. El skb se entrega a netif_rx() que puede liberarlo; después de llamarlo, desreferenciar skb puede desencadenar un use after free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mdiobus: arregla el recuento de referencias de nodos desequilibrados Obtuve el siguiente informe mientras realizaba la prueba de carga del dispositivo (mscc-miim) con CONFIG_OF_UNITTEST y CONFIG_OF_DYNAMIC habilitados: OF: ERROR: pérdida de memoria, se esperaba un recuento de referencias 1 en lugar de 2, of_node_get()/of_node_put() desequilibrado - destruye la entrada cset: adjuntar un nodo superpuesto /spi/soc@0/mdio@7107009c/ethernet-phy@0 Si el 'fwnode' no es un nodo acpi, el recuento de referencias se obtiene en fwnode_mdiobus_phy_device_register(), pero nunca se ha colocado cuando el dispositivo se libera en la ruta normal. Entonces llama a fwnode_handle_put() en phy_device_release() para evitar la pérdida. Si es un nodo acpi, nunca se ha obtenido, pero se coloca en la ruta de error, por lo que se llama a fwnode_handle_get() antes de phy_device_register() para mantener equilibrada la operación de obtención/colocación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: volver a obtener el skb cb después de tipc_msg_validate Como muestra el seguimiento de la llamada, el skb original se liberó en tipc_msg_validate(), y desreferenciar el antiguo skb cb causaría un bloqueo por use after free. ERROR: KASAN: use after free en tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] Seguimiento de llamadas: tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc] ... Asignado por la tarea 47078: kmem_cache_alloc_node+0x158/0x4d0 __alloc_skb+0x1c1/0x270 tipc_buf_acquire+0x1e/0xe0 [tipc] tipc_msg_create+0x33/0x1c0 [tipc] tipc_link_build_proto_msg+0x38a/0x2100 [tipc] tipc_link_timeout+0x8b8/0xef0 [tipc] tipc_node_timeout+0x2a1/0x960 [tipc] call_timer_fn+0x2d/0x1c0 ... Liberado por la tarea 47078: tipc_msg_validate+0x7b/0x440 [tipc] tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc] Este parche lo corrige volviendo a obtener el cb skb del nuevo skb asignado después de llamar a tipc_msg_validate().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: se corrige la suspensión en atomic en el momento del cierre Matt informó un splat en el momento del cierre de msk: ERROR: función de suspensión llamada desde un contexto no válido en net/mptcp/protocol.c:2877 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 155, name: packetdrill preempt_count: 201, expected: 0 Profundidad de anidación de RCU: 0, expected: 0 4 bloqueos mantenidos por packetdrill/155: #0: ffff888001536990 (&sb->s_type->i_mutex_key#6){+.+.}-{3:3}, en: __sock_release (net/socket.c:650) #1: ffff88800b498130 (sk_lock-AF_INET){+.+.}-{0:0}, en: mptcp_close (net/mptcp/protocol.c:2973) #2: ffff88800b49a130 (sk_lock-AF_INET/1){+.+.}-{0:0}, en: __mptcp_close_ssk (net/mptcp/protocol.c:2363) #3: ffff88800b49a0b0 (slock-AF_INET){+...}-{2:2}, en: __lock_sock_fast (include/net/sock.h:1820) Preempción deshabilitada en: 0x0 CPU: 1 PID: 155 Comm: packetdrill No contaminado 6.1.0-rc5 #365 Nombre del hardware: QEMU PC estándar (i440FX + PIIX, 1996), BIOS 1.15.0-1 01/04/2014 Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:107 (discriminador 4)) __might_resched.cold (kernel/sched/core.c:9891) __mptcp_destroy_sock (include/linux/kernel.h:110) __mptcp_close (net/mptcp/protocol.c:2959) mptcp_subflow_queue_clean (include/net/sock.h:1777) __mptcp_close_ssk (net/mptcp/protocol.c:2363) mptcp_destroy_common (net/mptcp/protocol.c:3170) mptcp_destroy (include/net/sock.h:1495) __mptcp_destroy_sock (net/mptcp/protocol.c:2886) __mptcp_close (net/mptcp/protocol.c:2959) mptcp_close (net/mptcp/protocol.c:2974) inet_release (net/ipv4/af_inet.c:432) __sock_release (net/socket.c:651) sock_close (net/socket.c:1367) __fput (fs/file_table.c:320) task_work_run (kernel/task_work.c:181 (discriminador 1)) salir_a_modo_usuario_preparar (include/linux/reanudar_modo_usuario.h:49) No podemos llamar a mptcp_close bajo la variante de bloqueo de socket 'rápido', reemplácelo con sock_lock_nested() ya que el código relevante ya está bajo la protección de bloqueo de socket msk de escucha.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/khugepaged: invocar notificadores MMU en rutas de colapso de shmem/archivo Cualquier ruta de código que elimine las entradas de la tabla de páginas debe invocar notificadores MMU para garantizar que las MMU secundarias (como KVM) no sigan accediendo a páginas que ya no están asignadas. Las MMU secundarias no mantienen sus propias referencias a páginas que se reflejan, por lo que no notificarlas puede provocar el use-after-free de la página. Estoy marcando esto como una solución a un problema introducido en el commit f3f0e1d2150b ("khugepaged: agregar compatibilidad con el colapso para páginas tmpfs/shmem"), pero la mayor parte del impacto de seguridad de esto solo se produjo en el commit 27e1f8273113 ("khugepaged: habilitar el colapso pmd para THP asignado a pte"), que en realidad omitió los vaciados para la eliminación de PTE actuales, no solo para la eliminación de tablas de páginas vacías.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: soc-pcm: Agregar comprobación NULL en la reparentalización de BE Agregar comprobación NULL en la API dpcm_be_reparent para manejar el error de desreferencia de puntero NULL del kernel. El problema se produjo en la prueba de fuzzing.

Motivo del rechazo: esta autoridad de numeración CVE ha rechazado o retirado esta ID CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: seq: Fix function prototipo desajuste en snd_seq_expand_var_event Con la integridad del flujo de control del kernel de clang (kCFI, CONFIG_CFI_CLANG), los objetivos de llamada indirecta se validan contra el prototipo de puntero de función esperado para asegurarse de que el objetivo de llamada sea válido para ayudar a mitigar los ataques ROP. Si no son idénticos, hay un error en el tiempo de ejecución, que se manifiesta como un pánico del kernel o la muerte del hilo. seq_copy_in_user() y seq_copy_in_kernel() no tenían prototipos que coincidieran con snd_seq_dump_func_t. Ajústelo y elimine las conversiones. No hay diferencias de salida binaria resultantes. Esto se encontró como resultado del nuevo indicador -Wcast-function-type-strict de Clang, que es más sensible que el más simple -Wcast-function-type, que solo verifica los desajustes de ancho de tipo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: raydium_ts_i2c - arregla pérdida de memoria en raydium_i2c_send() Hay una pérdida de kmem cuando se prueba raydium_i2c_ts con bpf mock device: unreferenced object 0xffff88812d3675a0 (size 8): comm "python3", pid 349, jiffies 4294741067 (age 95.695s) hex dump (first 8 bytes): 11 0e 10 c0 01 00 04 00 ........ backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000006e631aee>] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] dispositivo_de_sonda_de_controlador+0x49/0x120 [<00000000264fe082>] __controlador_de_adjuntar_dispositivo+0xf7/0x150 [<00000000f919423c>] bus_para_cada_unidad+0x114/0x180 [<00000000e067feca>] __adjuntar_dispositivo+0x1e5/0x2d0 [<0000000054301fc2>] dispositivo_de_sonda_de_bus+0x126/0x140 [<00000000aad93b22>] dispositivo_agregar+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 objeto sin referencia 0xffff88812d3675c8 (tamaño 8): comm "python3", pid 349, jiffies 4294741070 (antigüedad 95,692 s) volcado hexadecimal (primeros 8 bytes): 22 00 36 2d 81 88 ff ff ".6-.... traza inversa: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000001d5c9620>] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] realmente_sondeo+0x17c/0x3f0 [<00000000096ba499>] __dispositivo_de_sonda_de_controlador+0xe3/0x170 [<00000000c5acb4d9>] dispositivo_de_sonda_de_controlador+0x49/0x120 [<00000000264fe082>] __dispositivo_adjunto_controlador+0xf7/0x150 [<00000000f919423c>] bus_para_cada_unidad+0x114/0x180 [<00000000e067feca>] __dispositivo_adjunto+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 Después del comando BANK_SWITCH del BUS i2c, sin importar si se produjo un éxito o un error, se debe liberar el tx_buf.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon/sysfs: se corrige la suposición incorrecta de esquemas vacíos durante el ajuste en línea en damon_sysfs_set_schemes(). el commit da87878010e5 ("mm/damon/sysfs: soporte para la actualización de entradas en línea") hizo que se llamara a 'damon_sysfs_set_schemes()' para ejecutar el contexto DAMON, que podría tener esquemas. En este caso, se supone que la interfaz sysfs de DAMON actualiza, elimina o agrega esquemas para reflejar los archivos sysfs. Sin embargo, el código asume que el contexto DAMON no tendría esquemas en absoluto y, por lo tanto, crea y agrega nuevos esquemas. Como resultado, el código no funciona como se esperaba para el ajuste de esquemas en línea y podría tener una huella de memoria mayor a la esperada. Todos los esquemas están en el contexto DAMON, por lo que no pierde memoria. Elimine la suposición incorrecta (el contexto DAMON no tendría esquemas) en 'damon_sysfs_set_schemes()' para corregir el error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: char: tpm: Proteger tpm_pm_suspend con bloqueos Actualmente, las transacciones tpm se ejecutan incondicionalmente en la función tpm_pm_suspend(), lo que puede generar ejecuciones con otros accesores tpm en el sistema. Específicamente, el controlador tpm hw_random hace uso de tpm_get_random(), y esta función se llama en un bucle desde un kthread, lo que significa que no está congelada junto con el espacio de usuario, y por lo tanto puede competir con el trabajo realizado durante la suspensión del sistema: tpm tpm0: tpm_transmit: tpm_recv: error -52 tpm tpm0: TPM_STS.x 0xff no válido, volcando pila para análisis forense CPU: 0 PID: 1 Comm: init No contaminado 6.1.0-rc5+ #135 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Rastreo de llamadas: tpm_tis_status.cold+0x19/0x20 tpm_transmit+0x13b/0x390 tpm_transmit_cmd+0x20/0x80 tpm1_pm_suspend+0xa6/0x110 tpm_pm_suspend+0x53/0x80 __pnp_bus_suspend+0x35/0xe0 __device_suspend+0x10f/0x350 Solucione este problema llamando a tpm_try_get_ops(), que es un contenedor de tpm_chip_start(), pero toma el mutex apropiado. [Jason: mensaje de confirmación rediseñado, metadatos agregados]