Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Squashfs: comprobación de la integridad del tamaño del enlace simbólico Syzkiller informa de un error "KMSAN: uninit-value in pick_link". Esto se debe a una página no inicializada, que en última instancia se debe a un tamaño de enlace simbólico dañado leído desde el disco. La razón por la que el tamaño de enlace simbólico dañado provoca una página no inicializada se debe a la siguiente secuencia de eventos: 1. Se llama a squashfs_read_inode() para leer el enlace simbólico desde el disco. Esto asigna el valor dañado 3875536935 a inode->i_size. 2. Más tarde se llama a squashfs_symlink_read_folio(), que asigna este valor dañado a la variable length, que, al ser un int con signo, se desborda produciendo un número negativo. 3. El siguiente bucle que rellena el contenido de la página comprueba que los bytes copiados sean menores que length, que, al ser negativo, significa que se omite el bucle, lo que produce una página no inicializada. Este parche agrega una verificación de cordura que verifica que el tamaño del enlace simbólico no sea mayor al esperado. -- V2: corrige error ortográfico.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: uinput - rechazar solicitudes con un número irrazonable de ranuras Al ejercitar la interfaz uinput, syzkaller puede intentar configurar el dispositivo con un número realmente grande de ranuras, lo que provoca un error de asignación de memoria en input_mt_init_slots(). Si bien este error de asignación se maneja correctamente y la solicitud se rechaza, da como resultado informes de syzkaller. Además, dicha solicitud puede poner una carga indebida en el sistema que intentará liberar una gran cantidad de memoria para una solicitud falsa. Arréglelo limitando el número permitido de ranuras a 100. Esto se puede ampliar fácilmente si vemos dispositivos que pueden rastrear más de 100 contactos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: amd_sfh: liberar driver_data después de destruir el dispositivo HID Las devoluciones de llamadas del controlador HID ya no se invocan una vez que se ha invocado hid_destroy_device(). Por lo tanto, hid driver_data debería liberarse solo después de que la función hid_destroy_device() devuelta como driver_data se use en varias devoluciones de llamadas. Observé un fallo con el kernel 6.10.0 en mi T14s Gen 3, después de habilitar KASAN para depurar la asignación de memoria, obtuve este resultado: [ 13.050438] ======================================================================= [ 13.054060] ERROR: KASAN: slab-use-after-free en amd_sfh_get_report+0x3ec/0x530 [amd_sfh] [ 13.054809] psmouse serio1: trackpoint: firmware Synaptics TrackPoint: 0x02, botones: 3/3 [ 13.056432] Lectura de tamaño 8 en addr ffff88813152f408 por tarea (udev-worker)/479 [ 13.060970] CPU: 5 PID: 479 Comm: (udev-worker) No contaminado 6.10.0-arch1-2 #1 893bb55d7f0073f25c46adbb49eb3785fefd74b0 [ 13.063978] Nombre del hardware: LENOVO 21CQCTO1WW/21CQCTO1WW, BIOS R22ET70W (1.40 ) 21/03/2024 [ 13.067860] Seguimiento de llamadas: [ 13.069383] entrada: TPPS/2 Synaptics TrackPoint como /devices/platform/i8042/serio1/input/input8 [ [13.071486] [13.071492] dump_stack_lvl+0x5d/0x80 [13.074870] snd_hda_intel 0000:33:00.6: habilitando dispositivo (0000 -> 0002) [13.078296] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [13.082199] print_report+0x174/0x505 [13.085776] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 13.089367] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.093255] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.097464] kasan_report+0xc8/0x150 [ 13.101461] ? es: amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.105802] amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.110303] amdtp_hid_request+0xb8/0x110 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.114879] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.119450] sensor_hub_get_feature+0x1d3/0x540 [hid_sensor_hub 3f13be3016ff415bea03008d45d99da837ee3082] [ 13.124097] hid_sensor_parse_common_attributes+0x4d0/0xad0 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5] [ 13.127404] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [13.143602] ? __devm_add_action+0x167/0x1d0 [13.155061] hid_gyro_3d_probe+0x120/0x7f0 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172] [13.158581] ? __driver_probe_device+0x18c/0x370 [ 13.171500] driver_probe_device+0x4a/0x120 [ 13.175000] __driver_attach+0x190/0x4a0 [ 13.178521] ? __pfx___driver_attach+0x10/0x10 [ 13.181771] bus_para_cada_dispositivo+0x106/0x180 [ 13.185033] ? __pfx__raw_spin_lock+0x10/0x10 [ 13.188229] ? __pfx_bus_para_cada_dispositivo+0x10/0x10 [ 13.191446] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.194382] bus_add_driver+0x29e/0x4d0 [ 13.197328] driver_register+0x1a5/0x360 [ 13.200283] ? __pfx_hid_gyro_3d_platform_driver_init+0x10/0x10 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172] [ 13.203362] hacer_una_initcall+0xa7/0x380 [ 13.206432] ? __pfx_do_one_initcall+0x10/0x10 [ 13.210175] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.213211] ? kasan_unpoison+0x44/0x70 [ 13.216688] do_init_module+0x238/0x750 [ 13.2196 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: cougar: fix slab-out-of-bounds La lectura en cougar_report_fixup report_fixup para el teclado para juegos Cougar 500k no verificaba que el tamaño del descriptor del informe fuera correcto antes de acceder a él.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: Establezca el tamaño máximo de subsolicitud para escrituras de caché en MAX_RW_COUNT Establezca el tamaño máximo de una subsolicitud que escribe en cachefiles en MAX_RW_COUNT para que no sobrepasemos la escritura máxima que podemos realizar en el sistema de archivos de respaldo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btnxpuart: corrige la desreferencia de puntero nulo en btnxpuart_flush() Esto agrega una verificación antes de liberar rx->skb en las funciones flush y close para manejar el bloqueo del kernel observado al eliminar el controlador después de que falla la descarga de FW o antes de que se complete la descarga de FW. dmesg log: [ 54.634586] No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000080 [ 54.643398] Información de aborto de memoria: [ 54.646204] ESR = 0x0000000096000004 [ 54.649964] EC = 0x25: DABT (EL actual), IL = 32 bits [ 54.655286] SET = 0, FnV = 0 [ 54.658348] EA = 0, S1PTW = 0 [ 54.661498] FSC = 0x04: error de traducción de nivel 0 [ 54.666391] Información de aborto de datos: [ 54.669273] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 54.674768] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 54.674771] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 54.674775] pgtable del usuario: páginas de 4k, VA de 48 bits, pgdp=0000000048860000 [ 54.674780] [0000000000000080] pgd=000000000000000, p4d=0000000000000000 [ 54.703880] Error interno: Ups: 0000000096000004 [#1] PREEMPT SMP [ 54.710152] Módulos vinculados en: btnxpuart(-) superposición fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 error de seguridad de caam snd_soc_fsl_micfil snd_soc_fsl_spdif snd_soc_fsl_sai snd_soc_fsl_utils imx_pcm_dma gpio_ir_recv rc_core Fusible sch_fq_codel [ 54.744357] CPU: 3 PID: 72 Comm: kworker/u9:0 No contaminado 6.6.3-otbr-g128004619037 #2 [ 54.744364] Nombre del hardware: Placa EVK FSL i.MX8MM (DT) [ 54.744368] Cola de trabajo: hci0 hci_power_on [ 54.757244] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 54.757249] pc : kfree_skb_reason+0x18/0xb0 [ 54.772299] lr : btnxpuart_flush+0x40/0x58 [btnxpuart] [54.782921] sp: ffff8000805ebca0 [54.782923] x29: ffff8000805ebca0 x28: ffffa5c6cf1869c0 x27: ffffa5c6cf186000 [54.782931] x26: 852400 x25: ffff377b848523c0 x24: ffff377b845e7230 [ 54.782938] x23: ffffa5c6ce8dbe08 x22: ffffa5c6ceb65410 x21: 00000000ffffff92 [ 54.782945] ffffa5c6ce8dbe98 x19: ffffffffffffffac x18: ffffffffffffffff [ 54.807651] x17: 0000000000000000 x16: ffffa5c6ce2824ec x15: ffff8001005eb857 [ 54.821917] x14: 0000000000000000 x13: ffffa5c6cf1a02e0 x12: 0000000000000642 [ 54.821924] x11: 0000000000000040 x10: ffffa5c6cf19d690 x9: ffffa5c6cf19d688 [ 54.821931] x8 : ffff377b86000028 x7 : 0000000000000000 x6 : 0000000000000000 [ 54.821938] x5 : ffff377b86000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 54.843331] x2 : 0000000000000000 x1 : 0000000000000002 x0 : ffffffffffffffac [ 54.857599] Rastreo de llamadas: [ 54.857601] kfree_skb_reason+0x18/0xb0 [ 54.863878] btnxpuart_flush+0x40/0x58 [ 54.863888] hci_dev_open_sync+0x3a8/0xa04 [ 54.872773] hci_power_on+0x54/0x2e4 [ 54.881832] proceso_uno_trabajo+0x138/0x260 [ 54.881842] subproceso_trabajador+0x32c/0x438 [ 54.881847] kthread+0x118/0x11c [ 54.881853] ret_from_fork+0x10/0x20 [ 54.896406] Código: a9be7bfd 910003fd f9000bf3 aa0003f3 (b940d400) [ 54.896410] ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: Agregar bloqueo de puente faltante a pci_bus_lock() Uno de los verdaderos positivos que identificó el esfuerzo de cfg_access_lock lockdep es esta secuencia: ADVERTENCIA: CPU: 14 PID: 1 en drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70 RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70 Rastreo de llamada: ? __warn+0x8c/0x190 ? pci_bridge_secondary_bus_reset+0x5d/0x70 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? pci_bridge_secondary_bus_reset+0x5d/0x70 pci_reset_bus+0x1d8/0x270 vmd_probe+0x778/0xa10 pci_device_probe+0x95/0x120 Donde los usuarios de pci_reset_bus() están activando reinicios de bus secundario desbloqueados. Irónicamente, pci_bus_reset(), varias llamadas después de pci_reset_bus(), usa pci_bus_lock() antes de emitir el reinicio que bloquea todo *excepto* el puente mismo. Por la misma motivación que agregar: bridge = pci_upstream_bridge(dev); if (bridge) pci_dev_lock(bridge); Para pci_reset_function() en los casos de reinicio de "bus" y "cxl_bus", agregue pci_dev_lock() para @bus->self a pci_bus_lock(). [bhelgaas: solución de bloqueo recursivo de squash de Keith Busch: https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: fix UAF caused by offsets overwrite Los objetos Binder se procesan y copian individualmente en el búfer de destino durante las transacciones. También se copian todos los datos sin procesar entre estos objetos. Sin embargo, esta copia de datos sin procesar carece de una comprobación de fuera de los límites. Si los datos sin procesar superan el tamaño de la sección de datos, la copia sobrescribe la sección de compensaciones. Esto finalmente desencadena un error que intenta desenrollar los objetos procesados. Sin embargo, en este punto, las compensaciones utilizadas para indexar estos objetos ahora están dañadas. El desenrollado con compensaciones dañadas puede resultar en disminuciones de nodos arbitrarios y conducir a su liberación prematura. Otros usuarios de dichos nodos se quedan con un puntero colgante que activa un use after free. Este problema se hace evidente en el siguiente informe de KASAN (recortado): ===================================================================== ERROR: KASAN: slab-use-after-free en _raw_spin_lock+0xe4/0x19c Escritura de tamaño 4 en la dirección ffff47fc91598f04 por la tarea binder-util/743 CPU: 9 UID: 0 PID: 743 Comm: binder-util No contaminado 6.11.0-rc4 #1 Nombre del hardware: linux,dummy-virt (DT) Rastreo de llamadas: _raw_spin_lock+0xe4/0x19c binder_free_buf+0x128/0x434 binder_thread_write+0x8a4/0x3260 binder_ioctl+0x18f0/0x258c [...] Asignado por la tarea 743: __kmalloc_cache_noprof+0x110/0x270 binder_new_node+0x50/0x700 binder_transaction+0x413c/0x6da8 binder_thread_write+0x978/0x3260 binder_ioctl+0x18f0/0x258c [...] Liberado por la tarea 745: kfree+0xbc/0x208 binder_thread_read+0x1c5c/0x37d4 binder_ioctl+0x16d8/0x258c [...] ======================================================================= Para evitar este problema, verifiquemos que la copia de datos sin procesar esté dentro de los límites de la sección de datos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb/server: se corrige la posible eliminación de referencia nula de lease_ctx_info en smb2_open(). La eliminación de referencia nula de lease_ctx_info ocurrirá cuando (req_op_level == SMB2_OPLOCK_LEVEL_LEASE) y parse_lease_state() devuelvan NULL. Corrija esto verificando si 'lease_ctx_info' es NULL. Además, elimine los paréntesis redundantes en parse_durable_handle_context().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: arregla la ejecución entre la escritura de E/S directa y fsync cuando se usa el mismo fd Si tenemos 2 subprocesos que usan el mismo descriptor de archivo y uno de ellos está haciendo escrituras de E/S directas mientras que el otro está haciendo fsync, tenemos una ejecución en la que podemos terminar: 1) Intentar un fsync sin mantener el bloqueo del inodo, lo que desencadena fallas de aserción cuando las aserciones están habilitadas; 2) Hacer un acceso a memoria no válido desde la tarea fsync porque el archivo privado apunta a la memoria asignada en la pila por la tarea de E/S directa y puede ser utilizada por la tarea fsync después de que la pila se haya destruido. La ejecución sucede así: 1) Un programa de espacio de usuario abre un descriptor de archivo con O_DIRECT; 2) El programa genera 2 subprocesos usando libpthread, por ejemplo; 3) Uno de los subprocesos usa el descriptor de archivo para hacer escrituras de E/S directas, mientras que el otro llama a fsync usando el mismo descriptor de archivo. 4) Llama a la tarea A, el hilo que realiza las escrituras de E/S directas, y a la tarea B, el hilo que realiza las fsyncs; 5) La tarea A realiza una escritura de E/S directa y, en btrfs_direct_write(), establece el privado del archivo en un privado asignado en la pila con el miembro 'fsync_skip_inode_lock' establecido en verdadero; 6) La tarea B ingresa a btrfs_sync_file() y ve que hay una estructura privada asociada al archivo que tiene 'fsync_skip_inode_lock' establecido en verdadero, por lo que omite el bloqueo del bloqueo VFS del inodo; 7) La tarea A completa la escritura de E/S directa y restablece el privado del archivo a NULL, ya que no tenía ningún privado anterior y nuestro privado estaba asignado en la pila. Luego, desbloquea el bloqueo VFS del inodo; 8) La tarea B ingresa a btrfs_get_ordered_extents_for_logging(), luego la aserción que verifica que el bloqueo VFS del inodo se mantenga falla, ya que la tarea B nunca lo bloqueó y la tarea A ya lo desbloqueó. El seguimiento de la pila producido es el siguiente: aserción fallida: inode_is_locked(&inode->vfs_inode), en fs/btrfs/ordered-data.c:983 ------------[ corte aquí ]------------ ¡ERROR del kernel en fs/btrfs/ordered-data.c:983! Ups: código de operación no válido: 0000 [#1] PREEMPT SMP PTI CPU: 9 PID: 5072 Comm: worker Contaminado: GU OE 6.10.5-1-default #1 openSUSE Tumbleweed 69f48d427608e1c09e60ea24c6c55e2ca1b049e8 Nombre del hardware: Acer Predator PH315-52/Covini_CFS, BIOS V1.12 28/07/2020 RIP: 0010:btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs] Código: 50 d6 86 c0 e8 (...) RSP: 0018:ffff9e4a03dcfc78 EFLAGS: 00010246 RAX: 0000000000000054 RBX: ffff9078a9868e98 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff907dce4a7800 RDI: ffff907dce4a7800 RBP: ffff907805518800 R08: 0000000000000000 R09: ffff9e4a03dcfb38 R10: ffff9e4a03dcfb30 R11: 0000000000000003 R12: ffff907684ae7800 R13: 0000000000000001 R14: ffff90774646b600 R15: 0000000000000000 FS: 00007f04b96006c0(0000) GS:ffff907dce480000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f32acbfc000 CR3: 00000001fd4fa005 CR4: 00000000003726f0 Seguimiento de llamadas: ? btrfs_obtener_extensiones_ordenadas_para_registro.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? exc_op_inválida+0x50/0x70 ? btrfs_obtener_extensiones_ordenadas_para_registro.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? btrfs_obtener_extensiones_ordenadas_para_registro.cold+0x1f/0x42 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] btrfs_archivo_de_sincronización+0x21a/0x4d0 [btrfs bb26272d49b4cdc847cf3f7faadd459b62caee9a] ? __seccomp_filter+0x31d/0x4f0 __x64_sys_fdatasync+0x4f/0x90 do_syscall_64+0x82/0x160 ? do_futex+0xcb/0x190 ? __x64_sys_futex+0x10e/0x1d0 ? switch_fpu_return+0x4f/0xd0 ? syscall_salir_al_modo_usuario+0x72/0x220 ? do_syscall_64+0x8e/0x160 ? syscall_salir_al_modo_usuario ---truncado---

Un problema de funcionalidad oculta en varias grabadoras de video digitales proporcionadas por TAKENAKA ENGINEERING CO., LTD. permite que un atacante remoto autenticado ejecute un comando de sistema operativo arbitrario en el dispositivo o altere la configuración del dispositivo.

OMFLOW de The SYSCOM Group tiene una vulnerabilidad que implica la exposición de datos confidenciales. Esto permite a atacantes remotos que hayan iniciado sesión en el sistema obtener hashes de contraseñas de todos los usuarios y administradores.