Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: return EIO on RAID1 block group write pointer mismatch Hubo un informe de error sobre una desreferencia de puntero NULL en __btrfs_add_free_space_zoned() que en última instancia ocurre debido a una conversión del perfil de metadatos predeterminado DUP a un perfil RAID1 en dos discos. El seguimiento de la pila tiene la siguiente firma: Error BTRFS (dispositivo sdc): zoned: desajuste del desplazamiento del puntero de escritura de las zonas en el perfil raid1 ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000058 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 RSP: 0018:ffffa236b6f3f6d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff96c8132f3400 RCX: 0000000000000001 RDX: 0000000010000000 RSI: 0000000000000000 RDI: ffff96c8132f3410 RBP: 0000000010000000 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000 R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000 FS: 00007fdab1cb2900(0000) GS:ffff96e60ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 00000001a05ae000 CR4: 0000000000350ef0 Seguimiento de llamadas: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15c/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 btrfs_add_free_space_async_trimmed+0x34/0x40 btrfs_add_new_free_space+0x107/0x120 btrfs_make_block_group+0x104/0x2b0 btrfs_create_chunk+0x977/0xf20 btrfs_chunk_alloc+0x174/0x510 ? srso_return_thunk+0x5/0x5f btrfs_inc_block_group_ro+0x1b1/0x230 btrfs_relocate_block_group+0x9e/0x410 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x8ac/0x12b0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? __kmalloc_cache_noprof+0x14c/0x3e0 btrfs_ioctl+0x2686/0x2a80 ? srso_return_thunk+0x5/0x5f ? ioctl_has_perm.constprop.0.isra.0+0xd2/0x120 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x82/0x160 ? srso_return_thunk+0x5/0x5f ? __memcg_slab_free_hook+0x11a/0x170 ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x3f0/0x450 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? sysfs_emit+0xaf/0xc0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? seq_read_iter+0x207/0x460 ? srso_return_thunk+0x5/0x5f ? vfs_read+0x29c/0x370 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? srso_return_thunk+0x5/0x5f ? exc_page_fault+0x7e/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdab1e0ca6d RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdab1e0ca6d RDX: 00007ffeb2b60d80 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 00007ffeb2b60cd0 R08: 0000000000000000 R09: 0000000000000013 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffeb2b6343b R14: 00007ffeb2b60d80 R15: 0000000000000001 CR2: 0000000000000058 ---[ fin del seguimiento 000000000000000 ]--- La primera línea es la más interesante aquí: Error BTRFS (dispositivo sdc): zoned: discrepancia en el desplazamiento del puntero de escritura de las zonas en el perfil RAID1. Cuando se crea un grupo de bloques RAID1 y se detecta una discrepancia en el desplazamiento del puntero de escritura entre los discos del conjunto RAID, btrfs establece el valor de alloc_offset en la longitud del grupo de bloques, marcándolo como lleno. Posteriormente, el código espera que una operación de balance evacue los datos de este grupo de bloques y solucione los problemas. Sin embargo, antes de que esto sea posible, el nuevo espacio de este grupo de bloques se contabilizará en la caché de espacio libre. ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/eevdf: Se soluciona que se->slice se establezca en U64_MAX y el bloqueo resultante Hay una ruta de código en dequeue_entities() que puede establecer el slice de un sched_entity en U64_MAX, lo que a veces resulta en un bloqueo. El caso ofensivo es cuando se llama a dequeue_entities() para sacar de la cola una entidad de grupo retrasada y luego se retrasa la salida de la cola del padre de la entidad. En ese caso: 1. En el bloque if (entity_is_task(se)) else al comienzo de dequeue_entities(), slice se establece en cfs_rq_min_slice(group_cfs_rq(se)). Si la entidad se retrasó, entonces no tiene tareas en cola, por lo que cfs_rq_min_slice() devuelve U64_MAX. 2. El primer bucle for_each_sched_entity() saca de la cola la entidad. 3. Si la entidad era la única hija de su padre, la siguiente iteración intenta sacar de la cola al padre. 4. Si es necesario retrasar la salida de la cola del padre, se interrumpe desde el primer bucle for_each_sched_entity() _sin actualizar la porción_. 5. El segundo bucle for_each_sched_entity() establece la porción -> del padre en la porción guardada, que sigue siendo U64_MAX. Esto altera los cálculos posteriores con resultados potencialmente catastróficos. Una manifestación que vimos en producción fue: 6. En update_entity_lag(), se->slice se usa para calcular el límite, que termina como un número negativo enorme. 7. limit se usa en se->vlag = clamp(vlag, -limit, limit). Como limit es negativo, vlag > limit, por lo que se->vlag se establece en el mismo número negativo enorme. 8. En place_entity(), se->vlag se escala, lo que se desborda y da como resultado otro número enorme (positivo o negativo). 9. El retardo ajustado se resta de se->vruntime, lo que aumenta o disminuye se->vruntime considerablemente. 10. pick_eevdf() llama a entity_eligible()/vruntime_eligible(), que devuelve incorrectamente "false" debido a la gran distancia entre el vruntime y los demás vruntimes de la cola, lo que provoca un desbordamiento del cálculo de carga (vruntime - cfs_rq->min_vruntime) *. 11. Nada parece ser elegible, por lo que pick_eevdf() devuelve NULL. 12. pick_next_entity() intenta desreferenciar el valor de retorno de pick_eevdf() y se bloquea. Volcar los estados de cfs_rq desde los volcados de núcleo con drgn mostró rangos de tiempo de ejecución virtuales enormes y valores de vlag falsos, y también rastreé que se->slice se configuraba en U64_MAX en sistemas en vivo (lo cual solía ser "benigno", ya que el resto de la cola de ejecución debía estar en un estado específico para fallar). Corríjalo en dequeue_entities() configurando siempre slice desde el primer cfs_rq no vacío.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen-netfront: manejador NULL devuelto por xdp_convert_buff_to_frame(). La función xdp_convert_buff_to_frame() puede devolver NULL si no convierte correctamente el búfer XDP en un marco XDP debido a limitaciones de memoria, errores internos o datos no válidos. No comprobar si hay NULL puede provocar una desreferencia de puntero NULL si el resultado se utiliza más adelante en el procesamiento, lo que puede causar fallos, corrupción de datos o un comportamiento indefinido. En caso de fallo en la redirección XDP, la página asociada debe liberarse explícitamente si se retuvo previamente mediante get_page(). No hacerlo puede provocar una fuga de memoria, ya que el recuento de referencias de páginas no se reduce.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/gic-v2m: Impedir el uso tras la liberación de gicv2m_get_fwnode() Con ACPI en su lugar, gicv2m_get_fwnode() se registra en el subsistema pci como pci_msi_get_fwnode_cb(), que puede invocarse en tiempo de ejecución durante un sondeo de puente de host PCI. Pero, la devolución de llamada se marca erróneamente como __init, lo que provoca que se libere, mientras se registra en el subsistema PCI y podría desencadenar: No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548 Esto es fácilmente reproducible en una placa Juno con arranque ACPI. Conserve la función para uso posterior.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Devuelve NULL desde huge_pte_offset() para PMD no válido. La función huge_pte_offset() de LoongArch actualmente devuelve un puntero a una ranura PMD incluso si la entrada subyacente apunta a invalid_pte_table (lo que indica que no hay asignación). Llamadores como smaps_hugetlb_range() obtienen este valor de entrada no válido (la dirección de invalid_pte_table) a través de este puntero. La comprobación genérica is_swap_pte() identifica incorrectamente esta dirección como una entrada de intercambio en LoongArch, ya que cumple las condiciones "!pte_present() && !pte_none()". Esta interpretación errónea, combinada con una coincidencia de is_migration_entry() en los bits de dirección, provoca fallos del kernel en pfn_swap_entry_to_page(). Solucione esto a nivel de arquitectura modificando huge_pte_offset() para comprobar el contenido de la entrada PMD mediante pmd_none() antes de regresar. Si la entrada no es válida (es decir, apunta a invalid_pte_table), devuelva NULL en lugar del puntero a la ranura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Añadir comprobación de valores nulos en ufshcd_mcq_compl_pending_transfer(). Añadir una comprobación de valores nulos para el puntero hwq devuelto por ufshcd_mcq_req_to_hwq(). Esto es similar a la corrección en el commit 74736103fb41 ("scsi: ufs: core: Corregir el problema de ejecuciones de ufshcd_abort_one").

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: uprobes: Añadir un archivo "fence.i" faltante tras la construcción del búfer XOL. El búfer XOL (ejecución fuera de línea) se utiliza para ejecutar paso a paso las instrucciones reemplazadas para uprobes. El puerto RISC-V carecía de un archivo "fence.i" adecuado (vaciado de i$) tras la construcción del búfer XOL, lo que puede provocar la ejecución incorrecta de instrucciones obsoletas o dañadas. Esto se detectó al ejecutar las pruebas automáticas de BPF "test_progs: uprobe_autoattach, attached_probe" en Spacemit K1/X60, donde las pruebas de uprobes fallaron aleatoriamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mcb: se corrige un error de doble liberación en chameleon_parse_gdd(). En chameleon_parse_gdd(), si mcb_device_register() falla, se libera 'mdev' en mcb_device_register() mediante put_device(). Por lo tanto, ir a la etiqueta 'err' y liberar 'mdev' de nuevo provoca una doble liberación. Simplemente retorne si mcb_device_register() falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mei: vsc: Se corrige el problema de fortify-panic causado por el uso no válido de counted_by() gcc 15 respeta el atributo __counted_by(len) en vsc_tp_packet.buf[] y el código vsc-tp.c lo usa de manera incorrecta. len no contiene el tamaño disponible en el búfer, contiene la longitud real del paquete *sin* el crc. Entonces, tan pronto como vsc_tp_xfer() intenta agregar el crc a buf[], se activa el controlador fortify-panic: [80.842193] memcpy: desbordamiento de búfer detectado: escritura de 4 bytes de tamaño de búfer 0 [80.842243] ADVERTENCIA: CPU: 4 PID: 272 en lib/string_helpers.c:1032 __fortify_report+0x45/0x50 ... [80.843175] __fortify_panic+0x9/0xb [80.843186] vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw] [80.843210] ? lockdep_hardirqs_on+0x7c/0x110 [ 80.843250] mei_vsc_hw_start+0x98/0x120 [mei_vsc] [ 80.843270] mei_reset+0x11d/0x420 [mei] La solución más fácil sería simplemente omitir el conteo, pero con la excepción del búfer de reconocimiento en vsc_tp_xfer_helper() que solo contiene suficiente espacio para el encabezado del paquete, todos los demás usos de vsc_tp_packet siempre usan un búfer de VSC_TP_MAX_XFER_SIZE bytes para el paquete. En lugar de simplemente eliminar el conteo, divida la definición de la estructura vsc_tp_packet en un encabezado y una definición de paquete completo y use un buf[] de tamaño fijo en la definición del paquete, de esta manera la verificación de desbordamiento del búfer de fortify-source aún funciona cuando está habilitada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: microchip: pci1xxxx: Se corrige el pánico del kernel durante el registro del controlador de IRQ. Se resuelve el pánico del kernel al acceder al controlador de IRQ asociado con la IRQ generada. Esto se logra adquiriendo el bloqueo de giro y almacenando el estado actual de la interrupción antes de procesar la solicitud de interrupción mediante generic_handle_irq. Se envió un parche de corrección anterior donde 'generic_handle_irq' se reemplazó por 'handle_nested_irq'. Sin embargo, este cambio también causa el pánico del kernel, que, tras determinar qué GPIO activó la interrupción e intentar llamar a handle_nested_irq con el número de IRQ asignado, provoca un error al localizar el controlador registrado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: Requerir CAP_SYS_ADMIN para todos los usos de TIOCL_SELMOUSEREPORT Este requisito se flexibilizó con mucho entusiasmo en el commit 2f83e38a095f ("tty: Permitir algunos modos TIOCL_SETSEL sin CAP_SYS_ADMIN"), pero resulta que (1) la lógica que implementé allí era inconsistente (¡disculpas!), (2) TIOCL_SELMOUSEREPORT en realidad puede ser un pequeño riesgo de seguridad después de todo, y (3) TIOCL_SELMOUSEREPORT solo está destinado a ser utilizado por el demonio del mouse (GPM o Consolation), que ya se ejecuta como CAP_SYS_ADMIN. Más detalles: 1. El parche anterior tiene una lógica inconsistente: En el commit 2f83e38a095f ("tty: Permitir algunos modos TIOCL_SETSEL sin CAP_SYS_ADMIN"), verificamos que sel_mode == TIOCL_SELMOUSEREPORT, pero pasamos por alto que los cuatro bits inferiores de este parámetro "mode" se usaban como una forma adicional de pasar un argumento. Por lo tanto, el parche seguía requiriendo CAP_SYS_ADMIN si alguno de los bits del botón del ratón estaba configurado, pero no lo requería si ninguno de los bits del botón del ratón estaba configurado. Esta lógica es inconsistente y no fue intencional. Deberíamos tener las mismas políticas para usar TIOCL_SELMOUSEREPORT, independientemente del valor del argumento "oculto" del botón del ratón. Envié un parche de documentación aparte a la lista de páginas del manual con más detalles sobre TIOCL_SELMOUSEREPORT: https://lore.kernel.org/all/20250223091342.35523-2-gnoack3000@gmail.com/ 2. TIOCL_SELMOUSEREPORT constituye un riesgo de seguridad potencial que puede permitir a un atacante simular la entrada de teclado en aplicaciones de línea de comandos en la misma terminal, como TIOCSTI y otras IOCTL de "modo de selección" de TIOCLINUX. Al habilitar los informes del ratón en una terminal y luego inyectarlos mediante TIOCL_SELMOUSEREPORT, un atacante puede simular los movimientos del ratón en la misma terminal, de forma similar a los ataques de inyección de pulsaciones de teclas de TIOCSTI que antes eran posibles con TIOCSTI y otros modos de selección de TIOCL_SETSEL. Muchos programas (incluidos libreadline/bash) tienden a malinterpretar estos informes del ratón como una entrada normal del teclado, ya que no esperan una entrada en el formato del protocolo X11. El atacante no tiene control total sobre la secuencia de escape, pero al menos puede controlar los valores de dos bytes consecutivos en la secuencia de escape binaria del informe del ratón. Entré en más detalles sobre eso en la discusión en https://lore.kernel.org/all/20250221.0a947528d8f3@gnoack.org/ No es igualmente trivial simular pulsaciones de teclas arbitrarias como lo fue con TIOCSTI (commit 83efeeeb3d04 ("tty: Permitir que TIOCSTI sea deshabilitado")), pero el mecanismo general está ahí, y junto con la pequeña cantidad de casos de uso legítimos existentes (ver a continuación), sería mejor volver a requerir CAP_SYS_ADMIN para TIOCL_SELMOUSEREPORT, como ya era el caso antes del commit 2f83e38a095f ("tty: Permitir algunos modos TIOCL_SETSEL sin CAP_SYS_ADMIN"). 3. TIOCL_SELMOUSEREPORT solo lo utilizan los daemons de ratón (GPM o Consolation), y son el único caso de uso legítimo: Para citar console_codes(4): La función de seguimiento del ratón está diseñada para devolver informes de estado del ratón compatibles con xterm(1). Dado que el controlador de consola no puede conocer el dispositivo ni el tipo de ratón, estos informes se devuelven en el flujo de entrada de la consola solo cuando el controlador del terminal virtual recibe una instrucción ioctl de actualización del ratón. Estas instrucciones ioctl deben ser generadas por una aplicación en modo usuario que admita el ratón, como el daemon gpm(8). Jared Finder también ha confirmado en https://lore.kernel.org/all/491f3df9de6593df8e70dbe77614b026@finder.org/ que Emacs no llama a TIOCL_SELMOUSEREPORT directamente, y sería difícil encontrar buenas razones para hacerlo, dado que interferiría con los ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: xhci: Corregir desreferencia de puntero no válida en el workaround de Etron Esta comprobación se realiza antes de prepare_transfer() y prepare_ring(), por lo que enqueue ya puede apuntar al TRB de enlace final de un segmento. Y de hecho lo hará, alrededor del 0,4% de las veces que se llama a este código. Entonces enqueue + 1 es un puntero no válido. Hará que el kernel se caiga de inmediato o cargará algo basura que puede parecer un TRB de enlace y hacer que el TRB de enlace real se reemplace con un NOOP. Esto no terminaría bien. Utilice una prueba funcionalmente equivalente que no desreferencia el puntero y siempre dé un resultado correcto. Algo ha hecho que mi máquina se caiga dos veces en los últimos días mientras jugaba con un Etron HC, y una prueba de estrés de transferencia de control ejecutada para confirmación la acaba de hacer caer de nuevo. La misma prueba pasa con este parche aplicado.