Vulnerabilidades

Los productos afectados podrían permitir que un atacante no autenticado acceda a información del sistema que podría permitir mayor acceso a archivos confidenciales y obtener credenciales administrativas.

Langroid es un framework de Python para crear aplicaciones basadas en modelos de lenguaje grandes (LLM). Antes de la versión 0.53.15, `TableChatAgent` utiliza `pandas eval()`. Si se alimenta con información de usuario no confiable, como en el caso de una aplicación LLM pública, puede ser vulnerable a la inyección de código. Langroid 0.53.15 depura la información de `TableChatAgent` por defecto para abordar los vectores de ataque más comunes y añadió varias advertencias sobre este comportamiento riesgoso en la documentación del proyecto.

Langroid es un framework de Python para crear aplicaciones basadas en modelos de lenguaje grandes (LLM). Antes de la versión 0.53.15, `LanceDocChatAgent` utilizaba la función eval() de Pandas mediante `compute_from_docs()`. Como resultado, un atacante podría hacer que el agente ejecute comandos maliciosos a través de `QueryPlan.dataframe_calc]`, comprometiendo así el sistema host. Langroid 0.53.15 depura la entrada a la función afectada de forma predeterminada para abordar los vectores de ataque más comunes y añadió varias advertencias sobre este comportamiento riesgoso en la documentación del proyecto.

vLLM, un motor de inferencia y servicio para modelos de lenguaje grandes (LLM), presenta un problema en las versiones 0.6.5 a 0.8.4 que SOLO afecta a entornos que utilizan la integración de transferencia de caché KV `PyNcclPipe` con el motor V0. Ninguna otra configuración se ve afectada. vLLM admite el uso de la clase `PyNcclPipe` para establecer un dominio de comunicación punto a punto para la transmisión de datos entre nodos distribuidos. La transmisión de caché KV del lado de la GPU se implementa mediante la clase `PyNcclCommunicator`, mientras que el paso de mensajes de control del lado de la CPU se gestiona mediante los métodos `send_obj` y `recv_obj` en el lado de la CPU. El objetivo era que esta interfaz solo se expusiera a una red privada utilizando la dirección IP especificada por el parámetro de CLI `--kv-ip`. La documentación de vLLM explica cómo esto debe limitarse a una red segura. El comportamiento predeterminado e intencional de PyTorch es que la interfaz `TCPStore` escucha en TODAS las interfaces, independientemente de la dirección IP proporcionada. La dirección IP proporcionada solo se usaba como dirección del cliente. vLLM se corrigió para usar una solución alternativa que obligaba a la instancia `TCPStore` a vincular su socket a una interfaz privada específica. A partir de la versión 0.8.5, vLLM limita el socket `TCPStore` a la interfaz privada configurada.

En JetBrains YouTrack antes de 2025.1.74704, los archivos adjuntos restringidos podrían volverse visibles después de la clonación de problemas

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: corrige un par de ejecucións en el manejo de MNT_TREE_BENEATH por do_move_mount() Normalmente do_lock_mount(path, _) está bloqueando un punto de montaje fijado por *path y en el momento en que la coincidencia de unlock_mount() desbloquea esa ubicación, todavía está fijado por la misma cosa. Desafortunadamente, para el caso 'debajo' ya no es tan simple: el objeto que se bloquea no es el que *path apunta. Es el punto de montaje de path->mnt. El problema es que, sin un bloqueo suficiente, ->mnt_parent puede cambiar debajo de nosotros y ninguno de los bloqueos se mantiene en ese punto. Las reglas son * mount_lock estabiliza m->mnt_parent para cualquier montaje m. * namespace_sem estabiliza m->mnt_parent, siempre que m esté montado. * si se cumple alguna de las anteriores y refcount de m es positivo, se nos garantiza lo mismo para refcount de m->mnt_parent. namespace_sem se anida dentro de inode_lock(), por lo que do_lock_mount() debe tomar inode_lock() antes de obtener namespace_sem. Vuelve a comprobar que path->mnt siga montado en el mismo lugar después de obtener namespace_sem y se encarga de fijar el dentry. Esto es necesario, ya que, de lo contrario, podríamos terminar con una ejecución de mount --move (o umount) mientras obteníamos bloqueos; en ese caso, el dentry dejaría de ser un punto de montaje y podría haber sido expulsado por presión de memoria junto con su inodo, algo que no se desea al obtener el bloqueo de ese inodo. Sin embargo, fijar un dentry no es suficiente; el montaje correspondiente también está fijado solo por el hecho de que path->mnt está montado sobre él y, en ese momento, no tenemos ningún bloqueo. Por lo tanto, el mismo tipo de ejecución podría terminar con todas las referencias a ese montaje eliminadas justo cuando estamos a punto de entrar en inode_lock(). Si esto ocurre, el sistema de archivos se apaga mientras mantenemos una referencia dentry; los resultados no son muy alentadores. Necesitamos obtener dentry y mount simultáneamente; esto hace que inode_lock() sea seguro *y* evita el problema de que el sistema de archivos se apague bajo nuestra supervisión. Después de obtener namespace_sem, verificamos que path->mnt siga montado (lo que estabiliza su ->mnt_parent) y comprobamos que siga montado en el mismo lugar. Desde ese punto hasta la ejecución correspondiente de namespace_unlock(), tenemos la garantía de que el par mount/dentry que obtuvimos también está fijado al ser el punto de montaje de path->mnt, por lo que podemos eliminar discretamente tanto la referencia dentry (como hace el código actual) como la de mnt; esto es correcto en namespace_sem, ya que no eliminamos las referencias finales. Esto resuelve el problema en do_lock_mount(); unlock_mount() también tiene uno, ya que se garantiza que dentry permanecerá fijado solo hasta la ejecución de namespace_unlock(). Esto es fácil de solucionar: solo hay que hacer inode_unlock() antes, mientras todavía está fijado por mp->m_dentry.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pds_core: Prevenir posible condición de desbordamiento/atascamiento de adminq El adminq de pds_core está protegido por adminq_lock, que impide que se le envíe más de 1 comando a la vez. Esto hace que los controladores del cliente no puedan enviar comandos adminq simultáneamente. Sin embargo, las finalizaciones ocurren en un contexto diferente, lo que significa que se pueden enviar múltiples comandos adminq secuencialmente y todos esperando a ser completados. En el lado del FW, la cola de solicitudes adminq de respaldo solo tiene 16 entradas y falta el mecanismo de reintento o la prevención de desbordamiento/atascamiento. Esto puede provocar que adminq se atasque, por lo que el FW ya no procesa los comandos y ya no envía las finalizaciones. Como solución inicial, evite que haya más de 16 comandos adminq pendientes para que no haya forma de provocar que adminq se atasque. Esto funciona porque la cola de solicitudes adminq de respaldo nunca tendrá más de 16 comandos adminq pendientes, por lo que nunca se desbordará. Esto se hace reduciendo la profundidad de adminq a 16.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: class: Invalidación de punteros de dispositivos USB al cancelar el registro del socio. Para evitar el uso de punteros de dispositivos USB no válidos tras la desconexión de un socio de tipo C, este parche borra los punteros al cancelar el registro del socio. Esto garantiza un estado limpio para futuras conexiones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: ecdsa - Protección contra desbordamientos de enteros en DIV_ROUND_UP(). Herbert señala que DIV_ROUND_UP() puede desbordarse innecesariamente si la función de retorno ->key_size() de una implementación de ecdsa devuelve un valor inusualmente grande. En su lugar, Herbert sugiere (para una división entre 8): X / 8 + !!(X y 7). Con base en esta fórmula, introduzca una macro genérica DIV_ROUND_UP_POW2() y úsela en lugar de DIV_ROUND_UP() para los valores de retorno de ->key_size(). Además, utilice la macro en ecc_digits_from_bytes(), cuyo parámetro "nbytes" es un valor de retorno de ->key_size() en algunos casos, o una longitud ASN.1 especificada por el usuario en el caso de ecdsa_get_signature_rs().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: wdm: ejecución cerrada entre wdm_open y wdm_wwan_port_stop Borrar WDM_WWAN_IN_USE debe ser la última acción o podemos abrir un chardev cuyos URB todavía estén envenenados

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: leds: fix memory leakage Una prueba de reinicio de red en un enrutador provocó una condición de falta de memoria, que se rastreó hasta una fuga de memoria en el código de activación del LED PHY. La causa raíz es el uso indebido de la API devm. La función de registro (phy_led_triggers_register) se llama desde phy_attach_direct, no desde phy_probe, y la función de anulación del registro (phy_led_triggers_unregister) se llama desde phy_detach, no desde phy_remove. Esto significa que las funciones de registro y anulación del registro se pueden llamar varias veces para el mismo dispositivo PHY, pero la memoria asignada por devm no se libera hasta que se desvincula el controlador. Esto también evita que kmemleak detecte la fuga, ya que la API devm almacena internamente el puntero asignado. Solucione esto reemplazando devm_kzalloc/devm_kcalloc con kzalloc/kcalloc estándar y agregue las llamadas kfree correspondientes en la ruta de anulación de registro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: brcm80211: fmac: Añadir gestión de errores para brcmf_usb_dl_writeimage() La función brcmf_usb_dl_writeimage() llama a la función brcmf_usb_dl_cmd() pero no comprueba su valor de retorno. 'state.state' y 'state.bytes' no se inicializan si la función brcmf_usb_dl_cmd() falla. Es peligroso utilizar variables no inicializadas en las condiciones. Añadir gestión de errores para brcmf_usb_dl_cmd() para saltar a la ruta de gestión de errores si brcmf_usb_dl_cmd() falla y 'state.state' y 'state.bytes' no se inicializan. Mejorar el mensaje de error para informar de errores más detallados.