Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mwifiex: Se corrige la advertencia de escritura que abarca el campo memcpy() en mwifiex_config_scan() Reemplace la matriz de un elemento con un miembro de matriz flexible en `struct mwifiex_ie_types_wildcard_ssid_params` para corregir la siguiente advertencia en una Chromebook MT8173 (mt8173-elm-hana): [ 356.775250] ------------[ cortar aquí ]------------ [ 356.784543] memcpy: se detectó escritura que abarca el campo (tamaño 6) del campo único "wildcard_ssid_tlv->ssid" en drivers/net/wireless/marvell/mwifiex/scan.c:904 (tamaño 1) [ 356.813403] ADVERTENCIA: CPU: 3 PID: 742 en drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex] El "(tamaño 6)" anterior es exactamente la longitud del SSID de la red a la que estaba conectado este dispositivo. La fuente de la advertencia se ve así: ssid_len = user_scan_in->ssid_list[i].ssid_len; [...] memcpy(wildcard_ssid_tlv->ssid, user_scan_in->ssid_list[i].ssid, ssid_len); Hay un #define WILDCARD_SSID_TLV_MAX_SIZE que usa sizeof() en esta estructura, pero ya no tenía en cuenta el tamaño de la matriz de un elemento, por lo que no es necesario cambiarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btmtk: ajuste la posición para inicializar el ancla de datos iso. La inicialización del ancla de datos iso de MediaTek debe moverse a donde MediaTek afirma que tiene interfaz de datos iso. Si hay una desconexión USB de BT inesperada durante el flujo de configuración, provocará un problema de bloqueo del puntero NULL al liberar el ancla iso, ya que el ancla aún no se había inicializado. Ajuste la posición para inicializar el ancla de datos iso. [ 17.137991] pc : usb_kill_anchored_urbs+0x60/0x168 [ 17.137998] lr : usb_kill_anchored_urbs+0x44/0x168 [ 17.137999] sp : ffffffc0890cb5f0 [ 17.138000] x29: ffffffc0890cb5f0 x28: ffffff80bb6c2e80 [ 17.144081] gpio gpiochip0: identificador chardev registrado para 1 líneas [ 17.148421] x27: 0000000000000000 [ 17.148422] x26: ffffffd301ff4298 x25: 00000000000000003 x24: 00000000000000f0 [ 17.148424] x23: 0000000000000000 x22: 00000000ffffffff x21: 0000000000000001 [ 17.148425] x20: ffffffffffffffd8 x19: ffffff80c0f25560 x18: 0000000000000000 [ 17.148427] x17: ffffffd33864e408 x16: ffffffd33808f7c8 x15: 0000000000200000 [ 17.232789] x14: e0cd73cf80ffffff x13: 50f2137c0a0338c9 x12: 0000000000000001 [ 17.239912] x11: 0000000080150011 x10: 0000000000000002 x9: 0000000000000001 [ 17.247035] x8: 0000000000000000 x7: 0000000000008080 x6: 8080000000000000 [ 17.254158] x5: ffffffd33808ebc0 x4 : fffffffe033dcf20 x3 : 0000000080150011 [ 17.261281] x2 : ffffff8087a91400 x1 : 0000000000000000 x0 : ffffff80c0f25588 [ 17.268404] Rastreo de llamadas: [ 17.270841] usb_kill_anchored_urbs+0x60/0x168 [ 17.275274] btusb_mtk_release_iso_intf+0x2c/0xd8 [btusb (HASH:5afe 6)] [ 17.284226] btusb_mtk_disconnect+0x14/0x28 [btusb (HASH:5afe 6)] [ 17.292652] btusb_disconnect+0x70/0x140 [btusb (HASH:5afe 6)] [ 17.300818] interfaz_desvinculación_usb+0xc4/0x240 [ 17.305079] controlador_liberación_dispositivo_interno+0x18c/0x258 [ 17.310296] controlador_liberación_dispositivo+0x1c/0x30 [ 17.314557] dispositivo_eliminación_bus+0x140/0x160 [ 17.318643] dispositivo_del+0x1c0/0x330 [ 17.322121] usb_disable_device+0x80/0x180 [ 17.326207] usb_disconnect+0xec/0x300 [ 17.329948] hub_quiesce+0x80/0xd0 [ 17.333339] hub_disconnect+0x44/0x190 [ 17.337078] usb_unbind_interface+0xc4/0x240 [ 17.341337] device_release_driver_internal+0x18c/0x258 [ 17.346551] device_release_driver+0x1c/0x30 [ 17.350810] usb_driver_release_interface+0x70/0x88 [ 17.355677] El0_svc_common+0x84/0xe0 [ 17.378030] El0_svc+0x20/0x30 [ 17.381334] El0_svc+0x34/0x60 [ 17.384382] el0t_64_sync_handler+0x88/0xf0 [ 17.388554] el0t_64_sync+0x180/0x188 [ 17.392208] Código: f9400677 f100a2f4 54fffea0 d503201f (b8350288) [ 17.398289] ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: isofs: evitar pérdida de memoria en iocharset Se encontró una pérdida de memoria como la siguiente: objeto sin referencia 0xffff0000d10164d8 (tamaño 8): comm "pool-udisksd", pid 108217, jiffies 4295408555 volcado hexadecimal (primeros 8 bytes): 75 74 66 38 00 cc cc cc utf8.... backtrace (crc de430d31): [] kmemleak_alloc+0xb8/0xc8 [] __kmalloc_node_track_caller_noprof+0x380/0x474 [] kstrdup+0x70/0xfc [] parámetro_parse_isofs+0x228/0x2c0 [isofs] [] parámetro_fs_parse_vfs+0xf4/0x164 [] cadena_fs_parse_vfs+0x8c/0xd4 [] sep_monolítico_vfs+0xb0/0xfc [] parámetro_monolítico_genérico+0x30/0x3c [] analizar_datos_de_montaje_monolítico+0x40/0x4c [] ruta_de_montaje+0x6c4/0x9ec [] hacer_montaje+0xac/0xc4 [] __arm64_montaje_del_sistema+0x16c/0x2b0 [] invocar_llamada_del_sistema+0x7c/0x104 [] el0_svc_common.constprop.1+0xe0/0x104 [] do_el0_svc+0x2c/0x38 [] el0_svc+0x3c/0x1b8 El opt->iocharset se libera dentro de la función isofs_fill_super, pero puede haber situaciones en las que no sea posible ingresar a esta función. Por ejemplo, en la función get_tree_bdev_flags, cuando se encuentra la situación en la que "No se puede montar, cambiaría el estado de RO", en tal caso, isofs_fill_super no tendrá la oportunidad de ser llamado, lo que significa que opt->iocharset no tendrá la oportunidad de ser liberado, lo que finalmente conduce a una pérdida de memoria. Pasemos la liberación de memoria de opt->iocharset a la función isofs_free_fc.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: liberar skb cuando las opciones de metadatos TX no son válidas Cuando se asigna un nuevo skb para transmitir un descriptor xsk, es decir, para cada descriptor que no sea multibuf o el primer fragmento de un descriptor multibuf, pero luego se descubre que el descriptor tiene opciones no válidas establecidas para los metadatos TX, el nuevo skb nunca se libera. Esto puede filtrar skbs hasta que el búfer de envío esté lleno, lo que hace imposible enviar más paquetes. Solucione esto liberando el skb en la ruta de error si actualmente estamos tratando con el primer fragmento, es decir, un skb asignado en esta iteración de xsk_build_skb.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: corrección de use-after-free en device_for_each_child() Syzbot ha informado del siguiente splat de KASAN: ERROR: KASAN: slab-use-after-free en device_for_each_child+0x18f/0x1a0 Lectura de tamaño 8 en la dirección ffff88801f605308 por la tarea kbnepd bnep0/4980 CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 No contaminado 6.12.0-rc4-00161-gae90f6a6170d #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 Rastreo de llamadas: dump_stack_lvl+0x100/0x190 ? dispositivo_para_cada_hijo+0x18f/0x1a0 imprimir_informe+0x13a/0x4cb ? __virt_addr_valid+0x5e/0x590 ? __phys_addr+0xc6/0x150 ? dispositivo_para_cada_hijo+0x18f/0x1a0 kasan_informe+0xda/0x110 ? dispositivo_para_cada_hijo+0x18f/0x1a0 ? __pfx_dev_memalloc_noio+0x10/0x10 dispositivo_para_cada_hijo+0x18f/0x1a0 ? __pfx_device_for_each_child+0x10/0x10 pm_runtime_set_memalloc_noio+0xf2/0x180 netdev_unregister_kobject+0x1ed/0x270 anular_registro_de_dispositivo_de_red_muchas_notificaciones+0x123c/0x1d80 ? __mutex_trylock_common+0xde/0x250 ? __pfx_unregister_netdevice_muchas_notificaciones+0x10/0x10 ? trace_contention_end+0xe6/0x140 ? __mutex_lock+0x4e7/0x8f0 ? __pfx_lock_acquire.part.0+0x10/0x10 ? rcu_is_watching+0x12/0xc0 ? anular el registro de_netdev+0x12/0x30 anular el registro de_netdevice_queue+0x30d/0x3f0 ? __pfx_anular el registro de_netdevice_queue+0x10/0x10 ? __pfx_down_write+0x10/0x10 anular el registro de_netdev+0x1c/0x30 bnep_session+0x1fb3/0x2ab0 ? __pfx_bnep_session+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? __pfx_woken_wake_function+0x10/0x10 ? __kthread_parkme+0x132/0x200 ? __pfx_bnep_session+0x10/0x10 ? kthread+0x13a/0x370 ? __pfx_bnep_session+0x10/0x10 kthread+0x2b7/0x370 ? __pfx_kthread+0x10/0x10 ret_de_la_bifurcación+0x48/0x80 ? Asignado por la tarea 4974: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x1d1/0x440 hci_alloc_dev_priv+0x1d/0x2820 __vhci_create_device+0xef/0x7d0 vhci_write+0x2c7/0x480 vfs_write+0x6a0/0xfc0 ksys_write+0x12f/0x260 do_syscall_64+0xc7/0x250 entrada_SYSCALL_64_after_hwframe+0x77/0x7f Liberado por la tarea 4979: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x4f/0x70 kfree+0x141/0x490 hci_release_dev+0x4d9/0x600 bt_host_release+0x6a/0xb0 device_release+0xa4/0x240 kobject_put+0x1ec/0x5a0 put_device+0x1f/0x30 vhci_release+0x81/0xf0 __fput+0x3f6/0xb30 En 'hci_conn_del_sysfs()', se puede llamar a 'device_unregister()' cuando un contador de referencia subyacente (kobject) es mayor que 1. Esto significa que la re-asignación de padres (que ocurre cuando el dispositivo se libera realmente) se demora y, durante esa demora, se puede eliminar el dispositivo controlador principal (hciX). Dado que esto último puede crear un puntero colgante al padre liberado, evite ese escenario cambiando el padre a NULL explícitamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: 6fire: Liberar recursos al liberar la tarjeta El código 6fire actual intenta liberar los recursos justo después de la llamada a usb6fire_chip_abort(). Pero en este momento, el objeto de la tarjeta podría estar todavía en uso (ya que estamos llamando a snd_card_free_when_closed()). Para evitar posibles UAF, mueva la liberación de recursos a private_free de la tarjeta en lugar de la llamada manual a usb6fire_chip_destroy() en la devolución de llamada de desconexión USB.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: caiaq: Usar snd_card_free_when_closed() en la desconexión Se supone que la devolución de llamada de desconexión USB es corta y no requiere una espera demasiado larga. Por otro lado, el código actual usa snd_card_free() en la desconexión, pero esto espera el cierre de todos los fds usados, por lo tanto, puede tomar mucho tiempo. Eventualmente bloquea los ioctl USB de la capa superior, lo que puede desencadenar un bloqueo suave. Una solución fácil es reemplazar snd_card_free() con snd_card_free_when_closed(). Esta variante regresa inmediatamente mientras que la liberación de recursos se realiza de forma asincrónica por la liberación del dispositivo de la tarjeta en el último cierre. Este parche también divide el código en las fases de desconexión y liberación; la primera se llama inmediatamente en la devolución de llamada de desconexión USB mientras que la segunda se llama desde el destructor de la tarjeta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: us122l: Usar snd_card_free_when_closed() en la desconexión Se supone que la devolución de llamada de desconexión USB es corta y no requiere una espera demasiado larga. Por otro lado, el código actual usa snd_card_free() en la desconexión, pero esto espera el cierre de todos los fds usados, por lo tanto, puede tomar mucho tiempo. Eventualmente bloquea los ioctl USB de la capa superior, lo que puede desencadenar un bloqueo suave. Una solución fácil es reemplazar snd_card_free() con snd_card_free_when_closed(). Esta variante regresa inmediatamente mientras que la liberación de recursos se realiza de forma asincrónica por la liberación del dispositivo de la tarjeta en el último cierre. El bucle de comprobación us122l->mmap_count también se elimina. La comprobación es inútil para la operación asincrónica con *_when_closed().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usx2y: Usar snd_card_free_when_closed() en la desconexión Se supone que la devolución de llamada de desconexión USB es corta y no requiere una espera demasiado larga. Por otro lado, el código actual usa snd_card_free() en la desconexión, pero esto espera el cierre de todos los fds usados, por lo tanto, puede tomar mucho tiempo. Eventualmente bloquea los ioctl USB de la capa superior, lo que puede desencadenar un bloqueo suave. Una solución fácil es reemplazar snd_card_free() con snd_card_free_when_closed(). Esta variante regresa inmediatamente mientras que la liberación de recursos se realiza de forma asincrónica por la liberación del dispositivo de la tarjeta en el último cierre.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: kvm: Fix out-of-bounds array access En kvm_riscv_vcpu_sbi_init(), entry->ext_idx puede contener un índice fuera de los límites. Esto se utiliza como un marcador especial para las extensiones base, que no se pueden deshabilitar. Sin embargo, al recorrer las extensiones, ese marcador especial no se verifica antes de indexar la matriz. Agregue una verificación fuera de los límites a la función.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/s390: Implementar dominio de bloqueo Esto corrige un fallo al desconectar en caliente por sorpresa un dispositivo PCI. Este fallo ocurre porque durante la desconexión en caliente __iommu_group_set_domain_nofail() la conexión del dominio predeterminado falla cuando la plataforma ya no reconoce el dispositivo porque ya se ha eliminado y terminamos con un puntero de dominio NULL y UAF. Este es exactamente el caso al que se hace referencia en el segundo comentario en __iommu_device_set_domain() y tal como se indica allí, si en su lugar podemos conectar el dominio de bloqueo, se evita el UAF ya que puede gestionar el dispositivo ya eliminado. Implemente el dominio de bloqueo para usar esta gestión. Con este cambio, el fallo se corrige, pero aún encontramos una advertencia al intentar cambiar la propiedad de DMA en un dispositivo bloqueado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: se corrigen los montajes respaldados por archivos sobre FUSE syzbot informó de un null-ptr-deref en fuse_read_args_fill: fuse_read_folio+0xb0/0x100 fs/fuse/file.c:905 filemap_read_folio+0xc6/0x2a0 mm/filemap.c:2367 do_read_cache_folio+0x263/0x5c0 mm/filemap.c:3825 read_mapping_folio include/linux/pagemap.h:1011 [en línea] erofs_bread+0x34d/0x7e0 fs/erofs/data.c:41 erofs_read_superblock fs/erofs/super.c:281 [en línea] erofs_fc_fill_super+0x2b9/0x2500 fs/erofs/super.c:625 A diferencia de la mayoría de los sistemas de archivos, algunos sistemas de archivos de red y FUSE necesitan punteros de `archivo` válidos e inevitables para sus E/S de lectura [1]. De todos modos, esos casos de uso también deben ser compatibles. [1] https://docs.kernel.org/filesystems/vfs.html