Vulnerabilidades

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: 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: 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---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: garantizar que el índice de matriz tg_inst no sea -1 [POR QUÉ Y CÓMO] tg_inst será negativo si timing_generator_count es igual a 0, lo que se debe comprobar antes de su uso. Esto soluciona 2 problemas de OVERRUN informados por Coverity.

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: reparar fugas de reserva de qgroup en cow_file_range En la ruta de escritura en búfer, la página sucia posee la reserva de qgroup hasta que crea una ordered_extent. Por lo tanto, cualquier error que ocurra antes de que se cree la ordered_extent debe liberar esa reserva, o de lo contrario se pierde el espacio. El fstest generic/475 ejercita varias rutas de error de E/S y puede desencadenar errores en cow_file_range donde no logramos asignar la extensión ordenada. Tenga en cuenta que debido a que *sí* borramos delalloc, es probable que eliminemos el inodo de la lista de delalloc, por lo que los inodos/páginas no tienen una llamada de invalidación/lavado en ellos en la ruta de aborto de confirmación. Esto genera fallas en la etapa de desmontaje de la prueba que se ven así: BTRFS: error (dispositivo dm-8 estado EA) en cleanup_transaction:2018: errno=-5 falla de E/S BTRFS: error (dispositivo dm-8 estado EA) en btrfs_replace_file_extents:2416: errno=-5 falla de E/S Advertencia de BTRFS (dispositivo dm-8 estado EA): qgroup 0/5 tiene espacio sin liberar, tipo 0 rsv 28672 ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 3 PID: 22588 en fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs] Módulos vinculados en: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq CPU: 3 PID: 22588 Comm: umount Kdump: cargado Tainted: GW 6.10.0-rc7-gab56fde445b8 #21 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 01/04/2014 RIP: 0010:close_ctree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Seguimiento de llamadas: ? close_ctree+0x222/0x4d0 [btrfs] ? __warn.cold+0x8e/0xea ? close_ctree+0x222/0x4d0 [btrfs] ? reportar_error+0xff/0x140 ? manejar_error+0x3b/0x70 ? exc_op_inválida+0x17/0x70 ? asm_exc_op_inválida+0x1a/0x20 ? cerrar_ctree+0x222/0x4d0 [btrfs] apagado_genérico_super+0x70/0x160 matar_anónimo_super+0x11/0x40 btrfs_kill_super+0x11/0x20 [btrfs] desactivar_bloqueado_super+0x2e/0xa0 limpieza_mnt+0xb5/0x150 ejecución_trabajo_tarea+0x57/0x80 salida_llamada_al_sistema_modo_usuario_+0x121/0x130 hacer_llamada_al_sistema_64+0xab/0x1a0 entrada_SYSCALL_64_después_de_hwframe+0x77/0x7f RIP: 0033:0x7f916847a887 ---[ fin de seguimiento 0000000000000000 ]--- Error BTRFS (estado del dispositivo dm-8 EA): se filtró el espacio reservado del qgroup Los casos 2 y 3 en la ruta out_reserve pertenecen a este tipo de fuga y deben liberar los datos reservados del qgroup. Debido a que ya es una ruta de error, opté por no manejar los posibles errores en btrfs_free_qgroup_data.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: se corrige la advertencia de lectura fuera de los límites al usar el índice i: 1U puede superar el índice del elemento para mc_data[] cuando i = 0.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Asignar linear_pitch_alignment incluso para VM [Descripción] Asignar linear_pitch_alignment para que no provoquemos un error de división por 0 en entornos de VM

La vulnerabilidad de inyección de comando del sistema operativo en múltiples grabadoras de video digitales proporcionadas por TAKENAKA ENGINEERING CO., LTD. permite que un atacante remoto autenticado ejecute un comando del sistema operativo arbitrario en el dispositivo o altere la configuración del dispositivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: No sobremapear la asignación de VRAM de identidad La sobremapeo de la asignación de VRAM de identidad está provocando errores de hardware en ciertas plataformas. Utilizar 2M de páginas para el último fragmento de VRAM no alineado (a 1G). v2: - Utilizar siempre 2M de páginas para el último fragmento (Fei Yang) - interrumpir el bucle cuando se utilizan 2M de páginas - Añadir afirmación para que usable_size esté alineado a 2M v3: - Corregir checkpatch