Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ASoC: amd: corrección de fuga de memoria en las operaciones DMA de pdm acp3x

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ALSA: aloop: Corrige el acceso con condiciones de carrera en el disparador PCM<br /> <br /> La función de devolución de llamada del disparador PCM del controlador aloop intenta verificar el estado de PCM y detener el flujo del subflujo vinculado en el cable correspondiente. Dado que tanto las operaciones de verificación como las de detención se realizan fuera del bloqueo del cable, esto puede resultar en UAF cuando un programa intenta disparar frecuentemente mientras abre/cierra el flujo vinculado, como detectaron los fuzzers.<br /> <br /> Para abordar el UAF, este parche cambia dos cosas:<br /> - Cubre la mayor parte del código en loopback_check_format() con el spinlock cable-&amp;gt;lock, y añade las comprobaciones de NULL adecuadas. Esto ya evita algunos accesos con condiciones de carrera.<br /> - Además, ahora intentamos verificar el estado del flujo PCM de captura que puede ser detenido en esta función, lo cual era el principal punto problemático que conducía al UAF.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nvme-pci: manejar los requisitos cambiantes del mapa dma del dispositivo<br /> <br /> El estado inicial de dma_needs_unmap puede ser falso, pero cambiar a verdadero mientras se mapea el iterador de datos. Habilitar swiotlb es uno de esos casos que puede cambiar el resultado. El controlador nvme necesita guardar los vectores dma mapeados para ser desmapeados más tarde, así que asignar según sea necesario durante la iteración en lugar de asumir que siempre fue asignado al principio. Esto corrige una desreferencia NULL al acceder a un dma_vecs no inicializado cuando los requisitos de desmapeo dma del dispositivo cambian a mitad de la iteración.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: cpsw: Ejecutar la devolución de llamada ndo_set_rx_mode en una cola de trabajo<br /> <br /> El commit 1767bb2d47b7 (&amp;#39;ipv6: mcast: No retener RTNL para IPV6_ADD_MEMBERSHIP y MCAST_JOIN_GROUP.&amp;#39;) eliminó el bloqueo RTNL para las operaciones IPV6_ADD_MEMBERSHIP y MCAST_JOIN_GROUP. Sin embargo, este cambio desencadenó el siguiente rastreo de llamadas en mi placa BeagleBone Black:<br /> WARNING: net/8021q/vlan_core.c:236 en vlan_for_each+0x120/0x124, CPU#0: rpcbind/481<br /> RTNL: aserción fallida en net/8021q/vlan_core.c (236)<br /> Módulos enlazados:<br /> CPU: 0 UID: 997 PID: 481 Comm: rpcbind No contaminado 6.19.0-rc7-next-20260130-yocto-standard+ #35 PREEMPT<br /> Nombre del hardware: Generic AM33XX (Flattened Device Tree)<br /> Rastreo de llamadas:<br /> unwind_backtrace desde show_stack+0x28/0x2c<br /> show_stack desde dump_stack_lvl+0x30/0x38<br /> dump_stack_lvl desde __warn+0xb8/0x11c<br /> __warn desde warn_slowpath_fmt+0x130/0x194<br /> warn_slowpath_fmt desde vlan_for_each+0x120/0x124<br /> vlan_for_each desde cpsw_add_mc_addr+0x54/0x98<br /> cpsw_add_mc_addr desde __hw_addr_ref_sync_dev+0xc4/0xec<br /> __hw_addr_ref_sync_dev desde __dev_mc_add+0x78/0x88<br /> __dev_mc_add desde igmp6_group_added+0x84/0xec<br /> igmp6_group_added desde __ipv6_dev_mc_inc+0x1fc/0x2f0<br /> __ipv6_dev_mc_inc desde __ipv6_sock_mc_join+0x124/0x1b4<br /> __ipv6_sock_mc_join desde do_ipv6_setsockopt+0x84c/0x1168<br /> do_ipv6_setsockopt desde ipv6_setsockopt+0x88/0xc8<br /> ipv6_setsockopt desde do_sock_setsockopt+0xe8/0x19c<br /> do_sock_setsockopt desde __sys_setsockopt+0x84/0xac<br /> __sys_setsockopt desde ret_fast_syscall+0x0/0x54<br /> <br /> Este rastreo ocurre porque se llama a vlan_for_each() dentro de cpsw_ndo_set_rx_mode(), que espera que el bloqueo RTNL esté retenido. Dado que modificar vlan_for_each() para operar sin el bloqueo RTNL no es sencillo, y debido a que ndo_set_rx_mode() se invoca tanto con como sin el bloqueo RTNL a través de diferentes rutas de código, simplemente añadir rtnl_lock() en cpsw_ndo_set_rx_mode() no es una solución viable.<br /> <br /> Para resolver este problema, optamos por ejecutar el procesamiento real dentro de una cola de trabajo, siguiendo el enfoque utilizado por el controlador icssg-prueth.<br /> <br /> Tenga en cuenta: Para reproducir este problema, revertí manualmente los cambios en am335x-bone-common.dtsi del commit c477358e66a3 (&amp;#39;ARM: dts: am335x-bone: cambiar a nuevo controlador de switch cpsw&amp;#39;) para revertir al controlador cpsw heredado.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> platform/x86: toshiba_haps: Corrige fugas de memoria en las rutinas de añadir/eliminar<br /> <br /> toshiba_haps_add() fuga el objeto haps asignado por ella si devuelve un error después de asignar ese objeto con éxito.<br /> <br /> toshiba_haps_remove() no libera el objeto apuntado por toshiba_haps antes de borrar ese puntero, por lo que se convierte en memoria asignada inalcanzable.<br /> <br /> Aborda estas fugas de memoria utilizando devm_kzalloc() para asignar la memoria en cuestión.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mm, shmem: evitar bucle infinito en una condición de carrera de truncamiento<br /> <br /> Al truncar una entrada de intercambio grande, shmem_free_swap() devuelve 0 cuando el índice de la entrada no coincide con el índice dado debido a la alineación de búsqueda. La ruta de retroceso en caso de fallo comprueba si la entrada cruza el borde final y aborta cuando esto ocurre, por lo que el truncamiento no borrará una entrada o rango inesperado. Pero un escenario fue ignorado.<br /> <br /> Cuando &amp;#39;index&amp;#39; apunta al medio de una entrada de intercambio grande, y la entrada de intercambio grande no cruza el borde final, find_get_entries() devolverá esa entrada de intercambio grande como el primer elemento en el lote con &amp;#39;indices[0]&amp;#39; igual a &amp;#39;index&amp;#39;. El índice base de la entrada será menor que &amp;#39;indices[0]&amp;#39;, por lo que shmem_free_swap() fallará y devolverá 0 debido a la comprobación "base &amp;lt; index". El código entonces llamará a shmem_confirm_swap(), obtendrá el orden, comprobará si cruza el límite END (lo cual no hace), y reintentará con el mismo índice.<br /> <br /> La siguiente iteración encontrará la misma entrada de nuevo en el mismo índice con los mismos índices, lo que lleva a un bucle infinito.<br /> <br /> Solucione esto reintentando con un índice redondeado a la baja, y abortar si el índice es menor que el rango de truncamiento.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> HID: i2c-hid: corrige un potencial desbordamiento de búfer en i2c_hid_get_report()<br /> <br /> &amp;#39;i2c_hid_xfer&amp;#39; se utiliza para leer &amp;#39;recv_len + sizeof(__le16)&amp;#39; bytes de datos en &amp;#39;ihid-&amp;gt;rawbuf&amp;#39;.<br /> <br /> El primero puede provenir del espacio de usuario en el controlador hidraw y está limitado únicamente por HID_MAX_BUFFER_SIZE(16384) por defecto (a menos que también configuremos el campo &amp;#39;max_buffer_size&amp;#39; de &amp;#39;struct hid_ll_driver&amp;#39;, lo cual no hacemos).<br /> <br /> El segundo tiene un tamaño determinado en tiempo de ejecución por el tamaño máximo de los diferentes tipos de informes que se podrían recibir en cualquier dispositivo particular y puede ser un valor mucho menor.<br /> <br /> Esto se soluciona truncando &amp;#39;recv_len&amp;#39; a &amp;#39;ihid-&amp;gt;bufsize - sizeof(__le16)&amp;#39;.<br /> <br /> El impacto es bajo ya que el acceso a los dispositivos hidraw requiere root.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nvmet-tcp: corregir cuelgue en nvmet_tcp_listen_data_ready()<br /> <br /> Cuando el socket se cierra mientras está en TCP_LISTEN, se ejecuta una devolución de llamada para vaciar todos los paquetes pendientes, lo que a su vez llama a nvmet_tcp_listen_data_ready() con el sk_callback_lock retenido. Así que necesitamos verificar si estamos en TCP_LISTEN antes de intentar obtener el sk_callback_lock() para evitar un interbloqueo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dpaa2-switch: añadir comprobación de límites para if_id en el manejador IRQ<br /> <br /> El manejador IRQ extrae if_id de los 16 bits superiores del registro de estado del hardware y lo utiliza para indexar en ethsw-&amp;gt;ports[] sin validación. Dado que if_id puede ser cualquier valor de 16 bits (0-65535) pero el array de puertos solo se asigna con elementos sw_attr.num_ifs, esto puede llevar a una posible lectura fuera de límites.<br /> <br /> Añadir una comprobación de límites antes de acceder al array, consistente con la validación existente en dpaa2_switch_rx().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> btrfs: sincronizar la lectura del superbloque del disco y establecer el tamaño de bloque<br /> <br /> Cuando el usuario realiza un montaje btrfs, el dispositivo de bloques no se configura correctamente. El usuario establece el tamaño de bloque del dispositivo de bloques a 0x4000 ejecutando el comando BLKBSZSET.<br /> Dado que el cambio de tamaño de bloque también modifica el valor de mapping-&amp;gt;flags, esto afecta aún más el resultado del cálculo de mapping_min_folio_order().<br /> <br /> Analicemos los dos escenarios siguientes:<br /> <br /> Escenario 1: Sin ejecutar el comando BLKBSZSET, el tamaño de bloque es 0x1000, y mapping_min_folio_order() devuelve 0;<br /> <br /> Escenario 2: Después de ejecutar el comando BLKBSZSET, el tamaño de bloque es 0x4000, y mapping_min_folio_order() devuelve 2.<br /> <br /> do_read_cache_folio() asigna un folio antes de que se ejecute el comando BLKBSZSET. Esto resulta en que el folio asignado tiene un valor de orden de 0. Posteriormente, después de ejecutar BLKBSZSET, el tamaño de bloque aumenta a 0x4000, y el resultado del cálculo de mapping_min_folio_order() se convierte en 2.<br /> <br /> Esto conduce a dos consecuencias indeseables:<br /> <br /> 1. filemap_add_folio() activa una aserción VM_BUG_ON_FOLIO(folio_order(folio) &amp;lt; mapping_min_folio_order(mapping)).<br /> <br /> 2. El informe de syzbot [1] muestra una desreferencia de puntero nulo en create_empty_buffers() debido a un fallo en la asignación de un buffer head.<br /> <br /> Se debe establecer una sincronización basada en el inodo entre el comando BLKBSZSET y la página de caché de lectura para evitar inconsistencias en el tamaño de bloque o las banderas de mapeo antes y después de la asignación de folio.<br /> <br /> [1]<br /> KASAN: desreferencia de puntero nulo en el rango [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:create_empty_buffers+0x4d/0x480 fs/buffer.c:1694<br /> Rastro de Llamada:<br /> folio_create_buffers+0x109/0x150 fs/buffer.c:1802<br /> block_read_full_folio+0x14c/0x850 fs/buffer.c:2403<br /> filemap_read_folio+0xc8/0x2a0 mm/filemap.c:2496<br /> do_read_cache_folio+0x266/0x5c0 mm/filemap.c:4096<br /> do_read_cache_page mm/filemap.c:4162 [inline]<br /> read_cache_page_gfp+0x29/0x120 mm/filemap.c:4195<br /> btrfs_read_disk_super+0x192/0x500 fs/btrfs/volumes.c:1367

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> spi: tegra: Corrección de una fuga de memoria en tegra_slink_probe()<br /> <br /> En tegra_slink_probe(), cuando platform_get_irq() falla, retorna directamente de la función con un código de error, lo que provoca una fuga de memoria.<br /> <br /> Reemplazarlo con una etiqueta goto para garantizar una limpieza adecuada.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> riscv: Sanitizar la indexación de la tabla de llamadas al sistema bajo especulación<br /> <br /> El número de llamada al sistema es un valor controlado por el usuario utilizado para indexar la tabla de llamadas al sistema. Usar array_index_nospec() para restringir este valor después de la comprobación de límites para prevenir el acceso especulativo fuera de límites y la posterior fuga de datos a través de canales laterales de caché.