Vulnerabilidades

El complemento AAWP Obfuscator para WordPress es vulnerable a Cross-Site Scripting Almacenado a través del parámetro 'data-aawp-web' en todas las versiones hasta la 1.0 incluida, debido a una depuración de entrada y al escape de salida insuficiente. Esto permite a atacantes autenticados, con acceso de autor o superior, inyectar scripts web arbitrarios en páginas que se ejecutarán al acceder un usuario a una página inyectada.

El complemento Advanced Advertising System para WordPress es vulnerable a Open Redirect en todas las versiones hasta la 1.3.1 incluida. Esto se debe a una validación insuficiente de la URL de redirección proporcionada mediante el parámetro 'redir'. Esto permite que atacantes no autenticados redirijan a los usuarios a sitios potencialmente maliciosos si logran engañarlos para que realicen una acción.

Se ha identificado una vulnerabilidad en Siemens License Server (SLS) (todas las versiones anteriores a la V4.3). La aplicación afectada busca archivos ejecutables en la carpeta de la aplicación sin la validación adecuada. Esto podría permitir que un atacante ejecute código arbitrario con privilegios administrativos colocando un ejecutable malicioso en el mismo directorio.

Se ha identificado una vulnerabilidad en Siemens License Server (SLS) (todas las versiones anteriores a la V4.3). La aplicación afectada no restringe correctamente los permisos de los usuarios. Esto podría permitir que un atacante con pocos privilegios aumente sus privilegios.

Se ha identificado una vulnerabilidad en Mendix Runtime V10 (todas las versiones anteriores a la V10.21.0), Mendix Runtime V10.12 (todas las versiones), Mendix Runtime V10.18 (todas las versiones), Mendix Runtime V10.6 (todas las versiones), Mendix Runtime V8 (todas las versiones) y Mendix Runtime V9 (todas las versiones anteriores a la V9.24.34). Las aplicaciones afectadas permiten la enumeración de entidades debido a respuestas distinguibles en ciertas acciones del cliente. Esto podría permitir que un atacante remoto no autenticado liste todas las entidades y nombres de atributos válidos de una aplicación basada en Mendix Runtime.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: devlink: corrección de la gestión de errores de xa_alloc_cyclic(). Si se devuelve 1 desde xa_alloc_cyclic() (wrapping), se devolverá ERR_PTR(1), lo que hará que IS_ERR() sea falso. Esto puede provocar la desreferenciación de un puntero no asignado (rel). Se corrige comprobando si err es menor que cero. Esto no se detectó en un caso práctico real, solo se detectó. Gracias a Pierre.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dpll: corrección de la gestión de errores de xa_alloc_cyclic(). Si se devuelve 1 desde xa_alloc_cyclic() (encapsulamiento), se devolverá ERR_PTR(1), lo que hará que IS_ERR() sea falso. Esto puede provocar la desreferencia de un puntero no asignado (pin). Se corrige comprobando si err es menor que cero. Esto no se detectó en un caso práctico real, solo se detectó. Gracias a Pierre.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/migrate: arregla la actualización de xarray de shmem durante la migración un folio de shmem puede estar en la caché de página o en la caché de intercambio, pero no al mismo tiempo. Es decir, una vez que está en la caché de intercambio, folio->mapping debe ser NULL y el folio ya no está en una asignación de shmem. En __folio_migrate_mapping(), para determinar el número de entradas de xarray a actualizar, se usa folio_test_swapbacked(), pero eso combina shmem en el caso de la caché de página y shmem en el caso de la caché de intercambio. Lleva a la corrupción de entradas de múltiples índices de xarray, ya que convierte una entrada hermana en una entrada normal durante xas_store() (vea [1] para una reproducción del espacio de usuario). Arréglelo usando solo folio_test_swapcache() para determinar si xarray está almacenando entradas de caché de intercambio o no para elegir el número correcto de entradas de xarray para actualizar. [1] https://lore.kernel.org/linux-mm/Z8idPCkaJW1IChjT@casper.infradead.org/ Nota: En __split_huge_page(), se usan folio_test_anon() y folio_test_swapcache() para obtener el espacio de direcciones de la caché de intercambio, pero esto ignora el folio shmem en el caso de la caché de intercambio. Esto podría provocar la desreferenciación de punteros nulos cuando un folio shmem en la caché de intercambio se divide en __xa_store(), ya que !folio_test_anon() es verdadero y folio->mapping es nulo. Afortunadamente, su llamador, split_huge_page_to_list_to_order(), se detiene antes de tiempo con EBUSY cuando folio->mapping es nulo. Por lo tanto, no es necesario ocuparse de ello aquí.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: arm64: Guardar y vaciar incondicionalmente el estado FPSIMD/SVE/SME del host Hay varios problemas con la forma en que el código hyp guarda de forma diferida el estado FPSIMD/SVE del host, incluidos: * El SVE del host se descarta inesperadamente debido a una configuración inconsistente de TIF_SVE y CPACR_ELx.ZEN. Se ha visto que esto da como resultado fallos de QEMU donde memmove() usa SVE, como lo informó Eric Auger: https://issues.redhat.com/browse/RHEL-68997 * El estado SVE del host se descarta *después* de la modificación por ptrace, que fue un cambio de ABI de ptrace no intencionado introducido con el descarte diferido del estado SVE. * El valor FPMR del host se puede descartar cuando se ejecuta una VM no protegida, donde la compatibilidad con FPMR no está expuesta a una VM y esa VM usa FPSIMD/SVE. En estos casos, el código hyp no guarda el FPMR del host antes de desvincular su estado FPSIMD/SVE/SME, lo que deja un valor obsoleto en memoria. Para evitar esto, guarde y vacíe el estado FPSIMD/SVE/SME del host al cargar una vCPU, de modo que KVM no tenga que guardar ninguno de sus estados. Para mayor claridad, se ha eliminado fpsimd_kvm_prepare() y la llamada necesaria a fpsimd_save_and_flush_cpu_state() se ha ubicado en kvm_arch_vcpu_load_fp(). Dado que 'fpsimd_state' y 'fpmr_ptr' no deben usarse, se establecen en NULL; todos sus usos se eliminarán en parches posteriores. Los problemas históricos se remontan al menos a la versión v5.17, por ejemplo, suposiciones erróneas acerca de que TIF_SVE está claro en el commit: 8383741ab2e773a9 ("KVM: arm64: deshacerse del seguimiento/guardado de SVE del host")... y por eso, este ansioso guardado y vaciado probablemente deba ser retrotraído a TODOS los árboles estables.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: dts: bcm2711: Reparar xHCI power-domain Durante las pruebas s2idle en Raspberry CM4, el firmware de la VPU siempre falla en xHCI power-domain resume: root@raspberrypi:/sys/power# echo freeze > state [ 70.724347] xhci_suspend finished [ 70.727730] xhci_plat_suspend finished [ 70.755624] bcm2835-power bcm2835-power: Apagar grafx [ 70.761127] USB: Establecer la energía en 0 [ 74.653040] USB: No se pudo establecer la energía en 1 (-110) Esto parece deberse al uso mixto de raspberrypi-power y bcm2835-power al mismo tiempo. Por lo tanto, evite el uso del controlador de dominio de energía del firmware VPU, lo que evita el bloqueo de la VPU.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "arm64: dts: qcom: sdm845: Affirm IDR0.CCTW en apps_smmu". Hay informes de que la coherencia de la caché del pagetable walker no es constante en todos los dispositivos SDM845/850, lo que provoca bloqueos y reinicios. Funciona correctamente en algunos dispositivos (como el Dragonboard 845c, pero no tanto en el Lenovo Yoga C630). Lamentablemente, esto parece ser un fallo en el desarrollo del firmware, ya que, probablemente en algún lugar de la vasta pila de hipervisores, se introdujo un cambio para adaptarlo después del lanzamiento inicial del software (que suele servir como base para los productos). Revertir el cambio para evitar conjeturas adicionales sobre fallos. Esto revierte el commit 6b31a9744b8726c69bb0af290f8475a368a4b805.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: pdr: Corrige el posible bloqueo cuando algún proceso de cliente A llama a pdr_add_lookup() para agregar la búsqueda para el servicio y realiza el trabajo del localizador de programación, más tarde un proceso B obtiene un nuevo paquete de servidor que indica que el localizador está activo y llama a pdr_locator_new_server() que finalmente establece pdr->locator_init_complete en verdadero, lo que hace que el proceso A vea y tome el bloqueo de lista y consulte la lista de dominios, pero se agotará el tiempo de espera debido al bloqueo, ya que la respuesta se pondrá en cola en el mismo qmi->wq y se ordenará workqueue y el proceso B no puede completar el nuevo trabajo de solicitud del servidor debido al bloqueo en el bloqueo de lista. Arréglelo eliminando la iteración de lista innecesaria, ya que la iteración de lista ya se está realizando dentro del trabajo del localizador, así que evítelo aquí y simplemente llame a schedule_work() aquí. Proceso A Proceso B process_scheduled_works() pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s error en la espera de la transacción para obtener la lista de dominios: %d\n", req->service_name, ret); Registro de errores de tiempo de espera debido a un bloqueo: "PDR: tms/servreg get domain list txn wait fallo: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110" Gracias a Bjorn y Johan por informarme que esta confirmación también corrige una regresión de audio al usar el pd-mapper dentro del kernel, ya que eso hace que sea más fácil alcanzar esta ejecución. [1]