Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: musb: Reparar bloqueo de hardware en la primera solicitud de endpoint Rx Existe la posibilidad de que la devolución de llamada de una solicitud pueda invocarse desde usb_ep_queue() (rastreo de llamada a continuación, complementado con llamadas faltantes): req->complete desde usb_gadget_giveback_request (drivers/usb/gadget/udc/core.c:999) usb_gadget_giveback_request desde musb_g_giveback (drivers/usb/musb/musb_gadget.c:147) musb_g_giveback desde rxstate (drivers/usb/musb/musb_gadget.c:784) rxstate desde musb_ep_restart (drivers/usb/musb/musb_gadget.c:1169) musb_ep_restart desde Según la cadena de documentación de usb_ep_queue(), esto no debería suceder: "Tenga en cuenta que la devolución de llamada ->complete() de @req nunca debe llamarse desde usb_ep_queue() ya que eso puede crear situaciones de bloqueo". De hecho, un bloqueo de hardware podría ocurrir en la siguiente secuencia: 1. El gadget se inicializa usando musb_gadget_enable(). 2. Mientras tanto, llega un paquete y se activa el indicador RXPKTRDY, lo que genera una interrupción. 3. Si las IRQ están habilitadas, se gestiona la interrupción, pero musb_g_rx() encuentra una cola vacía (next_request() devuelve NULL). El indicador de interrupción ya ha sido borrado por el controlador de la capa de pegamento, pero el indicador RXPKTRDY permanece activado. 4. La primera solicitud se pone en cola usando usb_ep_queue(), lo que lleva a la llamada de req->complete(), como se muestra en el seguimiento de la llamada anterior. 5. Si la devolución de llamada habilita las IRQ y hay otro paquete en espera, se repite el paso (3). La cola de solicitudes está vacía porque usb_g_giveback() elimina la solicitud antes de invocar la devolución de llamada. 6. El endpoint permanece bloqueado, ya que se ha gestionado la interrupción provocada por la configuración del hardware del indicador RXPKTRDY, pero el indicador en sí permanece configurado. Para que se produzca este escenario, solo es necesario que las IRQ se habiliten en algún momento durante la devolución de llamada completa. Esto sucede con el dispositivo USB Ethernet, cuya devolución de llamada rx_complete() llama a netif_rx(). Si se llama en el contexto de la tarea, netif_rx() deshabilita las mitades inferiores (BH). Cuando se vuelven a habilitar las BH, también se habilitan las IRQ para permitir que se procesen las IRQ suaves. El dispositivo en sí se inicializa en la carga del módulo (o en el arranque si está integrado), pero la primera solicitud se pone en cola cuando se activa la interfaz de red, lo que activa rx_complete() en el contexto de la tarea a través de ioctl(). Si llega un paquete mientras la interfaz está inactiva, puede impedir que la interfaz reciba más paquetes del host USB. La situación es bastante complicada con muchas partes involucradas. Este problema en particular se puede resolver de varias maneras posibles: 1. Asegúrese de que las devoluciones de llamadas nunca habiliten las IRQ. Esto sería difícil de hacer cumplir, ya que descubrir cómo interactúa netif_rx() con las interrupciones ya era bastante desafiante y u_ether no es el único controlador de función. También podrían estar ocultos "errores" similares en otros controladores. 2. Desactive las interrupciones MUSB en musb_g_giveback() antes de llamar a la devolución de llamada y vuelva a habilitarlas después (llamando a musb_{dis,en}able_interrupts(), por ejemplo). Esto garantizaría que las interrupciones MUSB no se gestionen durante la devolución de llamada, incluso si las IRQ están habilitadas. De hecho, permitiría que las IRQ se habiliten al liberar el bloqueo. Sin embargo, esto parece un truco poco elegante. 3. Modifique el controlador de interrupciones para borrar el indicador RXPKTRDY si la cola de solicitudes está vacía. Si bien este enfoque también parece un truco, desperdicia tiempo de CPU al intentar gestionar paquetes entrantes cuando el software no está listo para procesarlos. ---trunqué---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sunrpc: borrar XPRT_SOCK_UPD_TIMEOUT al reiniciar el transporte Dado que transport->sock se ha establecido en NULL durante el reinicio del transporte, también es necesario borrar XPRT_SOCK_UPD_TIMEOUT. De lo contrario, xs_tcp_set_socket_timeouts() puede activarse en xs_tcp_send_request() para desreferenciar el transport->sock que se ha establecido en NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrección de ejecución en la inyección de error de lectura de buffer_head Cuando habilité la depuración de ext4 para las pruebas de inyección de errores, encontré la siguiente advertencia: Error de EXT4-fs (dispositivo sda): ext4_read_inode_bitmap:201: comm fsstress: No se puede leer el mapa de bits del inodo - block_group = 8, inode_bitmap = 1051 ADVERTENCIA: CPU: 0 PID: 511 en fs/buffer.c:1181 mark_buffer_dirty+0x1b3/0x1d0 La causa raíz del problema radica en la implementación incorrecta de la inyección de error de lectura de buffer_head de ext4. La finalización real de la lectura de buffer_head y la inyección de error de buffer_head no son atómicas, lo que puede provocar que el indicador de actualización se borre en los buffer_heads utilizados normalmente en condiciones de ejecución. [CPU0] [CPU1] [CPU2] ext4_read_inode_bitmap ext4_read_bh() ext4_read_inode_bitmap if (buffer_uptodate(bh)) return bh jbd2_journal_commit_transaction __jbd2_journal_refile_buffer __jbd2_journal_unfile_buffer __jbd2_journal_temp_unlink_buffer ext4_simulate_fail_bh() clear_buffer_uptodate mark_buffer_dirty WARN_ON_ONCE(!buffer_uptodate(bh)) El mejor enfoque sería realizar la inyección de fallas en la función de devolución de llamada de finalización de E/S, en lugar de después de la finalización de E/S. Sin embargo, la función de devolución de llamada de finalización de E/S no puede obtener el código de inyección de fallas en sb. Para solucionarlo, pasamos el resultado de la inyección de fallas a la función de lectura de bh. Simulamos fallas dentro de la función de lectura de bh. Esto requiere agregar un parámetro adicional a las funciones de lectura de bh que necesitan la inyección de fallas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: buzón: mtk-cmdq: corrige el uso incorrecto de sizeof en cmdq_get_clocks(). Debe ser el tamaño de la estructura clk_bulk_data, no el puntero de datos pasado a devm_kcalloc().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: comprobar que num_codecs no es cero para evitar el pánico durante el sondeo Después de el commit 13f58267cda3 ("ASoC: soc.h: no crear un componente ficticio mediante COMP_DUMMY()"), COMP_DUMMY() se convirtió en una matriz con longitud cero y solo se rellena con la estructura ficticia después de que se registra la tarjeta. Dado que el sondeo del controlador de la tarjeta de sonido ocurre antes del registro de la tarjeta, acceder a cualquiera de los miembros de un componente ficticio durante el sondeo dará como resultado un comportamiento indefinido. Esto se puede observar en los controladores de sonido de las máquinas mt8188 y mt8195. Al omitir un subnodo de enlace dai en el nodo de la tarjeta de sonido en Devicetree, se utiliza el códec ficticio no inicializado predeterminado y, cuando su puntero dai_name se pasa a strcmp(), da como resultado una desreferencia de puntero nulo y un pánico del kernel. Además de eso, set_card_codec_info() en el archivo de ayuda genérico, mtk-soundcard-driver.c, llenará un enlace dai con un códec ficticio cuando un nodo de enlace dai esté presente en DT pero sin ninguna propiedad de códec. El resultado es que en el momento de la prueba, un códec ficticio puede no estar inicializado con num_codecs = 0, o ser un códec ficticio inicializado, con num_codecs = 1 y dai_name = "snd-soc-dummy-dai". Para tener en cuenta ambas situaciones, verifique que num_codecs no sea cero antes de acceder a los campos de los códecs, pero aún así verifique el nombre dai del códec contra "snd-soc-dummy-dai" según sea necesario. Mientras tanto, también elimine la verificación de que dai_name no sea nulo en el controlador mt8192, introducida en el commit 4d4e1b6319e5 ("ASoC: mediatek: mt8192: Verificar la existencia de dai_name antes de desreferenciar"), ya que en realidad es redundante dada la verificación anterior de num_codecs != 0.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/riscv-aplic: evitar un bloqueo cuando falta el dominio MSI Si se prueba el controlador APLIC antes que el controlador IMSIC, faltará el dominio MSI principal, lo que provoca una desreferencia de puntero NULL en msi_create_device_irq_domain(). Evite esto aplazando la prueba hasta que el dominio MSI principal esté disponible. Utilice dev_err_probe() para evitar imprimir un mensaje de error al devolver -EPROBE_DEFER.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/vc4: hdmi: evitar el bloqueo con registros de depuración cuando está suspendido Intentar leer /sys/kernel/debug/dri/1/hdmi1_regs cuando el hdmi está desconectado da como resultado un bloqueo fatal del sistema. Esto se debe a que el código de suspensión pm deshabilita el reloj dvp. Eso es solo una compuerta del reloj de 108 MHz en DVP_HT_RPI_MISC_CONFIG, lo que da como resultado accesos que bloquean el bus AXI. Protéjase contra esto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-pf: gestionar errores otx2_mbox_get_rsp en otx2_common.c. Agregar verificación de puntero de error después de llamar a otx2_mbox_get_rsp().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: intel/ipu6: no gestionan interrupciones cuando el dispositivo está deshabilitado Algunos dispositivos IPU6 tienen interrupciones compartidas. Necesitamos gestionar adecuadamente el caso cuando la interrupción se activa desde otro dispositivo en la línea irq compartida y el propio IPU6 está deshabilitado. En tal caso, obtenemos 0xffffffff del registro ISR_STATUS y gestionamos todos los casos de irq, para lo cual no estamos preparados y generalmente colgamos todo el sistema. Para evitar el problema, use pm_runtime_get_if_active() para verificar si el dispositivo está habilitado y evitar suspenderlo cuando gestionamos irq hasta el final de irq. Además, usesynchronous_irq() en suspensión

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: bcm - añadir comprobación de errores en la función ahash_hmac_init Las funciones ahash_init pueden devolver errores. La función ahash_hmac_init no debería devolver ok cuando ahash_init devuelve un error. Por ejemplo, ahash_init devolverá -ENOMEM cuando la memoria de asignación sea errónea.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/fadump: mover fadump_cma_init a setup_arch() después de initmem_init() Durante la inicialización temprana, CMA_MIN_ALIGNMENT_BYTES puede ser PAGE_SIZE, ya que pageblock_order sigue siendo cero y se inicializa más tarde durante initmem_init(), por ejemplo, setup_arch() -> initmem_init() -> sparse_init() -> set_pageblock_order() Un caso de uso en el que esto causa problemas es: early_setup() -> early_init_devtree() -> fadump_reserve_mem() -> fadump_cma_init() Esto hace que la verificación de alineación de memoria de CMA se omita en cma_init_reserved_mem(). Luego, más adelante, cma_activate_area() puede generar un error VM_BUG_ON_PAGE(pfn & ((1 << order) - 1)) si el área de memoria reservada no estaba alineada con pageblock_order. Solucione este problema moviendo fadump_cma_init() después de initmem_init(), donde también se invocan otras reservas de cma similares. ============== página: refcount:0 mapcount:0 mapping:0000000000000000 índice:0x0 pfn:0x10010 indicadores: 0x13ffff800000000(nodo=1|zona=0|lastcpupid=0x7ffff) CMA sin procesar: 013ffff800000000 5deadbeef0000100 5deadbeef0000122 000000000000000 sin procesar: 000000000000000 00000000000000 000000000000 00000000ffffffff 0000000000000000 página volcada porque: VM_BUG_ON_PAGE(pfn & ((1 << orden) - 1)) ------------[ cortar aquí ]------------ ¡ERROR del kernel en mm/page_alloc.c:778! Seguimiento de llamadas: __free_one_page+0x57c/0x7b0 (no confiable) free_pcppages_bulk+0x1a8/0x2c8 free_unref_page_commit+0x3d4/0x4e4 free_unref_page+0x458/0x6d0 init_cma_reserved_pageblock+0x114/0x198 cma_init_reserved_areas+0x270/0x3e0 do_one_initcall+0x80/0x2f8 kernel_init_freeable+0x33c/0x530 kernel_init+0x34/0x26c ret_from_kernel_user_thread+0x14/0x1c

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/mm/fault: Arreglar el informe de fallos de página de kfence. Se puede llamar a copy_from_kernel_nofault() al realizar una lectura de /proc/kcore. /proc/kcore puede tener algunos objetos kfence no mapeados que, cuando se leen mediante copy_from_kernel_nofault(), pueden causar fallos de página. Dado que las funciones *_nofault() definen su propia tabla de correcciones para gestionar los fallos, utilícela en lugar de pedirle a kfence que se encargue de dichos fallos. Por lo tanto, buscamos en las tablas de excepciones el nip que generó el fallo. Si hay una entrada, dejamos que el controlador de la tabla de correcciones se encargue del fallo de página devolviendo un error desde dentro de ___do_page_fault(). Esto se puede activar fácilmente si alguien intenta hacer dd desde /proc/kcore. p. ej. dd if=/proc/kcore of=/dev/null bs=1M Algunos ejemplos de falsos negativos: ================================ ERROR: KFENCE: lectura no válida en copy_from_kernel_nofault+0x9c/0x1a0 Lectura no válida en 0xc0000000fdff0000: copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 ERROR: KFENCE: lectura de use-after-free en copy_from_kernel_nofault+0x9c/0x1a0 Lectura de use-after-free en 0xc0000000fe050000 (en kfence-#2): copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec