Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: starfive: no liberar el búfer de pila Los datos de texto RSA utilizan un búfer de longitud variable asignado en la pila de software. Llamar a kfree provoca un comportamiento indefinido en operaciones posteriores.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: kdb: corrige el desbordamiento del búfer durante la finalización de tabulación Actualmente, cuando el usuario intenta completar el símbolo con la tecla Tab, kdb usará strncpy() para insertar el símbolo completado en el búfer de comando. Desafortunadamente, pasa el tamaño del búfer de origen en lugar del destino a strncpy() con resultados predeciblemente horribles. Lo más obvio es que si el búfer de comando ya está lleno pero cp, la posición del cursor, está en el medio del búfer, entonces escribiremos más allá del final del búfer proporcionado. Solucione este problema reemplazando las dudosas llamadas strncpy() con llamadas memmove()/memcpy() más comprobaciones explícitas de los límites para asegurarnos de que tenemos suficiente espacio antes de comenzar a mover los personajes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mc: corrige el recorrido del gráfico en media_pipeline_start El recorrido del gráfico intenta seguir todos los enlaces, incluso si no están entre pads. Esto provoca un bloqueo, por ejemplo, con un enlace MEDIA_LNK_FL_ANCILLARY_LINK. Solucione este problema permitiendo que la caminata continúe solo para los enlaces MEDIA_LNK_FL_DATA_LINK.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: SVM: WARN en la ventana vNMI + NMI si los NMI están completamente enmascarados Al solicitar una ventana NMI, WARN en la ventana de vNMI está habilitado si y solo si los NMI están realmente enmascarados, es decir, si la vCPU ya está manejando una NMI. La ABI de KVM para NMI que llegan simultáneamente (desde el punto de vista de KVM) es inyectar un NMI y esperar el otro. Cuando se usa vNMI, KVM suspende el segundo NMI simplemente configurando V_NMI_PENDING y deja que la CPU haga el resto (el hardware configura automáticamente V_NMI_BLOCKING cuando se inyecta un NMI). Sin embargo, si KVM no puede inyectar inmediatamente una NMI, por ejemplo, porque la vCPU está en una sombra STI o se está ejecutando con GIF=0, entonces KVM solicitará una ventana NMI y activará el WARN (pero seguirá funcionando correctamente). Es discutible si el caso GIF=0 tiene sentido o no, ya que la intención del comportamiento de KVM es proporcionar una funcionalidad lo más cercana posible al hardware real. Por ejemplo, si se envían dos NMI en rápida sucesión, la probabilidad de que ambos NMI lleguen a una sombra de STI es infinitamente baja en hardware real, pero significativamente mayor en un entorno virtual, por ejemplo, si la vCPU tiene prioridad en la sombra de STI. Para GIF=0, el argumento no es tan claro, porque la ventana donde dos NMI pueden colisionar es mucho mayor en el metal desnudo (aunque aún es pequeña). Dicho esto, KVM no debería tener un comportamiento divergente para el caso GIF=0 en función de si la compatibilidad con vNMI está habilitada o no. Y KVM ha permitido NMI simultáneas con GIF=0 durante más de una década, desde el commit 7460fb4a3400 ("KVM: Reparar NMI simultáneas"). Es decir, el manejo de GIF=0 de KVM no debe modificarse sin una *realmente* buena razón para hacerlo, y si se modifica el comportamiento de KVM, debe hacerse independientemente del soporte de vNMI.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: v4l: async: Reinicializar correctamente la entrada del notificador al cancelar el registro Notifier_entry de un notificador no se reinicializa después de cancelar el registro del notificador. Esto lleva a que se dejen punteros colgando allí, así que use list_del_init() para devolver notifier_entry una lista vacía.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: corrige el abuso de matriz de longitud variable en btree_iter btree_iter se usa de dos maneras: ya sea asignado en la pila con un tamaño fijo MAX_BSETS, o desde un mempool con un tamaño dinámico basado en el conjunto de caché específico. Anteriormente, la estructura tenía una matriz de longitud fija de tamaño MAX_BSETS que estaba indexada fuera de los límites para los iteradores de tamaño dinámico, lo que provoca que UBSAN se queje. Este parche utiliza el mismo enfoque que en sort_iter de bcachefs y divide el iterador en un btree_iter con un miembro de matriz flexible y un btree_iter_stack que incorpora un btree_iter así como una matriz de datos de longitud fija.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: davinci: no eliminar la función de eliminación cuando el controlador está integrado. El uso de __exit para la función de eliminación hace que la devolución de llamada de eliminación se descarte con CONFIG_MMC_DAVINCI=y. Cuando un dispositivo de este tipo se desvincula (por ejemplo, usando sysfs o hotplug), el controlador simplemente se elimina sin que se realice la limpieza. Esto da como resultado fugas de recursos. Solucionarlo compilando la devolución de llamada de eliminación incondicionalmente. Esto también corrige una advertencia de modpost W=1: ADVERTENCIA: modpost: drivers/mmc/host/davinci_mmc: falta de coincidencia de sección en referencia: davinci_mmcsd_driver+0x10 (sección: .data) -> davinci_mmcsd_remove (sección: .exit.text)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/hwmon: deshacerse de devm Cuando tanto hwmon como hwmon drvdata (del cual depende hwmon) son recursos administrados por el dispositivo, la expectativa, al desvincular el dispositivo, es que hwmon publicarse antes que drvdata. Sin embargo, en i915 hay dos rutas de código independientes, que liberan drvdata o hwmon y cualquiera de ellas puede publicarse antes que la otra. Estas rutas de código (para desvincular el dispositivo) son las siguientes (consulte también el error al que se hace referencia a continuación): Seguimiento de llamadas: release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 componente_unbind_all+0x8d/0xa0 componente_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915 ] intel_pxp_fini+0x33/0x80 [i915] i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0 dispositivo_release_driver_internal+0x19c/0x200 store+0x9c/0xb0 y seguimiento de llamadas: release_nodes+0x11/0x70 devres_release_all +0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200 unbind_store+0x9c/0xb0 Esto significa que en i915, si usa devm, no podemos garantizar que hwmon siempre se publicará antes que drvdata. Lo que significa que tenemos un uaf si se accede a hwmon sysfs cuando drvdata se lanzó pero hwmon no. La única forma de solucionar esto parece ser deshacerse de devm_ y liberar/liberar todo explícitamente durante la desvinculación del dispositivo. v2: Cambiar mensaje de confirmación y otros cambios menores de código v3: Limpieza de i915_hwmon_register en caso de error (Armin Wolf) v4: Eliminar posible advertencia del analizador estático (Rodrigo) Eliminar fetch_and_zero (Jani) v5: Restaurar la lógica anterior para el retorno de error ddat_gt->hwmon_dev (Andi )

KSmserver en KDE Plasma Workspace (también conocido como plasma-workspace) anterior a 5.27.11.1 y 6.x anterior a 6.0.5.1 permite conexiones a través de ICE basadas exclusivamente en el host, es decir, se aceptan todas las conexiones locales. Esto permite que otro usuario en la misma máquina obtenga acceso al administrador de sesión, por ejemplo, use la función de restauración de sesión para ejecutar código arbitrario como víctima (en el siguiente inicio) mediante el uso anterior del directorio /tmp.

Se descubrió un problema en OpenStack Cinder hasta 24.0.0, Glance antes de 28.0.2 y Nova antes de 29.0.3. El acceso arbitrario a archivos puede ocurrir a través de datos externos QCOW2 personalizados. Al proporcionar una imagen QCOW2 manipulada que hace referencia a una ruta de archivo de datos específica, un usuario autenticado puede convencer a los sistemas para que devuelvan una copia del contenido de ese archivo desde el servidor, lo que resulta en un acceso no autorizado a datos potencialmente confidenciales. Todas las implementaciones de Cinder y Nova se ven afectadas; solo se ven afectadas las implementaciones de Glance con la conversión de imágenes habilitada.

drupal-wiki.com Drupal Wiki anterior a 8.31.1 permite XSS a través de comentarios, leyendas y títulos de imágenes de una página Wiki.

La implementación de IPv6 en el kernel de Linux anterior a 6.3 tiene un umbral net/ipv6/route.c max_size que se puede consumir fácilmente, por ejemplo, provocando una denegación de servicio (errores de red inaccesible) cuando los paquetes IPv6 se envían en un bucle a través de un enchufe crudo.