Vulnerabilidades

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]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regulator: dummy: force synchronous sondeo a veces obtengo una desreferencia de puntero NULL en el momento del arranque en kobject_get() con la siguiente pila de llamadas: anatop_regulator_probe() devm_regulator_register() regulator_register() regulator_resolve_supply() kobject_get() Colocando algunas sentencias BUG_ON() adicionales pude verificar que esto se genera porque el sondeo del controlador del regulador 'dummy' no se completa ('dummy_regulator_rdev' sigue siendo NULL). En el depurador JTAG puedo ver que dummy_regulator_probe() y anatop_regulator_probe() pueden ser ejecutados por diferentes subprocesos del kernel (kworker/u4:*). No he investigado más si esto se puede cambiar o si hay otras posibilidades de forzar la sincronización entre estas dos rutinas de sondeo. Por otro lado, no espero mucha penalización en el tiempo de arranque al sondear el regulador 'dummy' sincrónicamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hns: Se corrige el bloqueo suave durante el bucle de páginas bt. El controlador ejecuta un bucle for al asignar páginas bt y mapearlas con páginas de búfer. Al asignar un búfer grande (por ejemplo, un MR de más de 100 GB), puede requerirse un número considerable de bucles. Esto provocará un bloqueo suave: watchdog: BUG: bloqueo suave - ¡CPU n.º 27 bloqueada durante 22 s! ... Rastreo de llamadas: hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2] hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2] hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2] alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2] hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x118/0x290 perro guardián: ERROR: bloqueo suave - ¡CPU n.º 35 bloqueada durante 23 s! ... Seguimiento de llamadas: hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2] mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2] hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2] alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2] hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x120/0x2bc Agregue un cond_resched() para corregir el bloqueo suave durante estos bucles. Para no afectar el rendimiento de asignación de un búfer de tamaño normal, establezca el recuento de bucles de un MR de 100 GB como el umbral para llamar a cond_resched().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regulador: comprobar que el regulador ficticio haya sido probado antes de usarlo Debido al sondeo asincrónico del controlador existe la posibilidad de que el regulador ficticio no haya sido probado ya cuando se accede a él por primera vez.