Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> pmdomain: imx8m-blk-ctrl: corrige el acceso fuera de rango de bc-&amp;gt;domains<br /> <br /> Corrige el acceso fuera de rango de bc-&amp;gt;domains en imx8m_blk_ctrl_remove().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: usb: r8152: corregir interbloqueo de reinicio de reanudación<br /> <br /> rtl8152 puede desencadenar un reinicio del dispositivo durante el reinicio, lo que potencialmente puede resultar en un interbloqueo:<br /> <br /> ** Tiempo de espera agotado del dispositivo DPM después de 10 segundos; 15 segundos hasta el pánico **<br /> Rastreo de llamadas:<br /> <br /> schedule+0x483/0x1370<br /> schedule_preempt_disabled+0x15/0x30<br /> __mutex_lock_common+0x1fd/0x470<br /> __rtl8152_set_mac_address+0x80/0x1f0<br /> dev_set_mac_address+0x7f/0x150<br /> rtl8152_post_reset+0x72/0x150<br /> usb_reset_device+0x1d0/0x220<br /> rtl8152_resume+0x99/0xc0<br /> usb_resume_interface+0x3e/0xc0<br /> usb_resume_both+0x104/0x150<br /> usb_resume+0x22/0x110<br /> <br /> El problema es que la reanudación de rtl8152 llama a reset bajo el mutex tp-&amp;gt;control mientras que reset básicamente reingresa a rtl8152 e intenta adquirir el mismo bloqueo tp-&amp;gt;control una vez más.<br /> <br /> Reiniciar el dispositivo INACCESIBLE fuera del ámbito del mutex tp-&amp;gt;control para evitar el interbloqueo recursivo de mutex_lock().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ceph: soluciona la desreferencia de puntero NULL en ceph_mds_auth_match()<br /> <br /> El cliente del kernel de CephFS tiene una regresión a partir de 6.18-rc1.<br /> Tenemos un problema en ceph_mds_auth_match() si fs_name == NULL:<br /> <br /> const char fs_name = mdsc-&amp;gt;fsc-&amp;gt;mount_options-&amp;gt;mds_namespace;<br /> ...<br /> if (auth-&amp;gt;match.fs_name &amp;amp;&amp;amp; strcmp(auth-&amp;gt;match.fs_name, fs_name)) {<br /> / el nombre de sistema de archivos no coincide, intentar el siguiente */<br /> return 0;<br /> }<br /> <br /> Patrick Donnelly sugirió que: En resumen, definitivamente deberíamos empezar a decodificar &amp;#39;fs_name&amp;#39; del MDSMap y realizar controles de autorización estrictos contra él. Tenga en cuenta que &amp;#39;-o mds_namespace=foo&amp;#39; solo debe usarse para seleccionar el sistema de archivos a montar y nada más. Es posible que no se especifique ningún mds_namespace, pero el kernel montará el único sistema de archivos que existe, el cual puede tener el nombre &amp;#39;foo&amp;#39;.<br /> <br /> Este parche reelabora ceph_mdsmap_decode() y namespace_equals() con el objetivo de apoyar el concepto sugerido. Ahora la estructura ceph_mdsmap contiene el campo m_fs_name que recibe una copia del nombre de FS extraído por ceph_extract_encoded_string(). Para el caso de sistemas de archivos CephFS &amp;#39;antiguos&amp;#39;, se utiliza el nombre &amp;#39;cephfs&amp;#39;.<br /> <br /> [ idryomov: reemplazar el redundante %*pE con %s en ceph_mdsmap_decode(), eliminar una serie de llamadas a strlen() en ceph_namespace_match(), descartar cambios en el cuerpo de namespace_equals() para evitar tratar un mds_namespace vacío como igual, descartar cambios en ceph_mdsc_handle_fsmap() ya que namespace_equals() no es una sustitución equivalente allí ]

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().