Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: cdns3: Corrección de interbloqueo al usar el gadget NCM. El controlador cdns3 presenta el mismo interbloqueo NCM corregido en cdnsp mediante el commit 58f2fcb3a845 ("usb: cdnsp: Corrección de un problema de interbloqueo durante el uso del gadget NCM"). Bajo PREEMPT_RT, el interbloqueo puede activarse fácilmente por tráfico de red intenso, por ejemplo, al usar "iperf --bidir" a través de un enlace Ethernet NCM. El interbloqueo se produce porque el manejador de interrupciones en subprocesos es interrumpido por un softirq, pero ambos están protegidos por el mismo bloqueo de giro. Para evitar el interbloqueo, desactive el softirq durante el controlador de interrupciones en subprocesos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: chipidea: ci_hdrc_imx: corrección del manejo de usbmisc. usbmisc es una propiedad opcional del dispositivo, por lo que es totalmente válido que el valor correspondiente de data->usbmisc_data sea nulo. Verifique esto antes de desreferenciar el puntero. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con la herramienta de análisis estático Svace.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: gadget: comprobar que el recuento de eventos no supere la longitud del búfer de eventos. El recuento de eventos se lee del registro DWC3_GEVNTCOUNT. Se comprueba que el recuento sea cero, pero no que supere la longitud del búfer de eventos. Se comprueba que el recuento de eventos no supere la longitud del búfer de eventos, lo que evita un acceso fuera de los límites al copiar el evento a memoria. Registro de fallos: No se puede gestionar la solicitud de paginación del núcleo en la dirección virtual ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Rastreo de llamadas: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34