Vulnerabilidades

El complemento LA-Studio Element Kit para Elementor de WordPress es vulnerable a Cross Site Scripting almacenado a través del widget de tabla de contenido en todas las versiones hasta la 1.4.9 incluida, debido a una depuración de entrada y al escape de salida insuficiente en los atributos proporcionados por el usuario. Esto permite a atacantes autenticados, con acceso de colaborador o superior, inyectar scripts web arbitrarios en páginas que se ejecutarán al acceder un usuario a una página inyectada.

El complemento Download Manager para WordPress es vulnerable a Cross Site Scripting almacenado al subir archivos SVG en todas las versiones hasta la 3.3.12 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 al archivo SVG.

Se ha detectado una vulnerabilidad en D-Link DWR-M961 1.1.36, clasificada como crítica. Esta vulnerabilidad afecta al código desconocido del archivo /boafrm/formStaticDHCP del componente Interfaz de Autorización. La manipulación del argumento Hostname provoca un desbordamiento del búfer basado en la pila. El ataque puede iniciarse remotamente. Se ha hecho público el exploit y puede que sea utilizado. Actualizar a la versión 1.1.49 puede solucionar este problema. Se recomienda actualizar el componente afectado.

Se detectó una vulnerabilidad en Tenda AC15 hasta la versión 15.03.05.19, clasificada como crítica. Este problema afecta a la función fromSetWirelessRepeat del archivo /goform/WifiExtraSet. La manipulación del argumento "mac" provoca un desbordamiento del búfer. El ataque puede iniciarse remotamente. Se ha hecho público el exploit y puede que sea utilizado.

Existe una vulnerabilidad de control de autenticación inapropiada en AiCloud. Esta vulnerabilidad puede activarse mediante una solicitud manipulada, lo que podría provocar la ejecución no autorizada de funciones. Consulte la sección "Vulnerabilidad del router ASUS AiCloud" en el Aviso de seguridad de ASUS para obtener más información.

Razón rechazado: no se usa

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: objtool, spi: amd: Se corrige el acceso a la pila fuera de los límites en amd_set_spi_freq(). Si speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() itera sobre toda la matriz amd_spi_freq sin interrumpir la ejecución antes de tiempo, lo que provoca que 'i' supere los límites de la matriz. Para solucionar esto, se detiene el bucle al llegar a la última entrada, de modo que el valor bajo de speed_hz se limite a AMD_SPI_MIN_HZ. Se corrige la siguiente advertencia con un kernel UBSAN: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falla a la siguiente función amd_spi_set_opcode().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: gpib: Fix cb7210 pcmcia Oops. La estructura pcmcia_driver seguía usando únicamente la inicialización anterior de .name en el campo drv. Esto provocaba un puntero nulo deref Oops en strcmp llamado desde pcmcia_register_driver. Inicialice el campo name de la estructura pcmcia_driver.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: objtool, nvmet: Se corrige el acceso a la pila fuera de los límites en nvmet_ctrl_state_show(). La matriz csts_state_names[] solo tiene seis entradas dispersas, pero el código de iteración en nvmet_ctrl_state_show() itera siete, lo que resulta en una posible lectura de la pila fuera de los límites. Se soluciona. Se corrige la siguiente advertencia con un kernel UBSAN: vmlinux.o: advertencia: objtool: .text.nvmet_ctrl_state_show: final inesperado de sección.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: light: Agregar comprobación de los límites de matriz en veml6075_read_int_time_ms La matriz contiene solo 5 elementos, pero el índice calculado por veml6075_read_int_time_index puede variar de 0 a 7, lo que podría provocar un acceso fuera de los límites. La comprobación evita este problema. Coverity Issue CID 1574309: (#1 de 1): Lectura fuera de los límites (OVERRUN) overrun-local: Desbordamiento de la matriz veml6075_it_ms de 5 elementos de 4 bytes en el índice de elemento 7 (desplazamiento de byte 31) utilizando el índice int_index (que evalúa a 7) Esto es endurecimiento contra hardware potencialmente dañado. Es bueno tenerlo, pero no es necesario retroportarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mce: usar is_copy_from_user() para determinar el contexto de copia del usuario. Serie de parches "mm/hwpoison: Corregir regresiones en la gestión de fallos de memoria", v4. ## 1. ¿Qué intento hacer?: Este conjunto de parches resuelve dos regresiones críticas relacionadas con la gestión de fallos de memoria que han aparecido en el kernel original desde la versión 5.17, en comparación con la 5.10 LTS. - caso de copyin: se encontró un error en la página de usuario mientras el kernel copiaba desde el espacio de usuario. - caso de instr: se encontró un error al obtener instrucciones en el espacio de usuario. ## 2. ¿Cuál es el resultado esperado y por qué? - Para el caso de copyin: el kernel puede recuperarse del error encontrado donde el kernel ejecuta get_user() o copy_from_user() si en esos lugares se obtiene un error y el kernel devuelve -EFAULT al proceso en lugar de bloquearse. Más específicamente, el controlador de MCE comprueba el tipo de controlador de corrección para decidir si se puede recuperar un #MC en el kernel. Cuando se encuentra EX_TYPE_UACCESS, el PC salta al código de recuperación especificado en _ASM_EXTABLE_FAULT() y devuelve un -EFAULT al espacio de usuario. - En el caso de instr: Si se encuentra un error durante la obtención de instrucciones en el espacio de usuario, es posible una recuperación completa. El proceso de usuario toma #PF, Linux asigna una nueva página y la completa leyendo del almacenamiento. ## 3. Qué sucede realmente y por qué - En el caso de copyin: Pánico del kernel desde la v5.17. El commit 4c132d1d844a ("x86/futex: Eliminar el uso de .fixup") introdujo un nuevo tipo de corrección extable, EX_TYPE_EFAULT_REG, y parches posteriores actualizaron el tipo de corrección extable para operaciones de copia desde el usuario, cambiándolo de EX_TYPE_UACCESS a EX_TYPE_EFAULT_REG. Esto interrumpe la gestión previo de EX_TYPE_UACCESS cuando se encuentra error en get_user() o copy_from_user(). - Para el caso instr: el proceso del usuario es eliminado por una señal SIGBUS debido a la ejecución #CMCI y #MCE Cuando se consume un error de memoria sin corregir, hay una ejecución entre el CMCI del controlador de memoria que informa un error sin corregir con una firma UCNA y el informe del núcleo y la comprobación de la máquina con firma SRAR cuando los datos están a punto de consumirse. ### Antecedentes: por qué los errores *UN*corregidos están vinculados a *C*MCI en la plataforma Intel [1] Antes de Icelake, los controladores de memoria informaban de eventos de depuración de patrullaje que detectaban un error sin corregir no visto previamente en la memoria mediante la señalización de una comprobación de la máquina de difusión con una firma SRAO (Acción recuperable de software opcional) en el banco de comprobación de la máquina. Esto era excesivo porque no es un problema urgente que ningún núcleo esté a punto de consumir esos datos erróneos. También se ha descubierto que varias UCE SRAO pueden causar interrupciones MCE anidadas y, finalmente, convertirse en una IERR. Por lo tanto, Intel degrada la firma del banco de verificación de la máquina de la limpieza de patrullaje de SRAO a UCNA (sin corregir, no se requiere acción) y la señal cambia a #CMCI. Para aumentar la confusión, Linux realiza una acción (en uc_decode_notifier()) para intentar desconectar la página a pesar del nombre de la firma UC*NA*. ### Antecedentes: ¿por qué #CMCI y #MCE compiten cuando el veneno consume datos en la plataforma Intel? [1] Tras decidir que CMCI/UCNA es la mejor acción para los errores de limpieza de patrullaje, el controlador de memoria también la utiliza para las lecturas. Sin embargo, el controlador de memoria se ejecuta de forma asíncrona desde el núcleo y no puede distinguir entre una lectura "real" y una lectura especulativa. Por lo tanto, ejecutará CMCI/UCNA si se encuentra un error en cualquier lectura. Por lo tanto: 1) El núcleo es inteligente y cree que ----truncada---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: simple-card-utils: No usar __free(device_node) en el commit 419d1918105e de graph_util_parse_dai() ("ASoC: simple-card-utils: usar __free(device_node) para el nodo de dispositivo") usa __free(device_node) para dlc->of_node, pero es necesario mantenerlo mientras se usa el controlador. No usar __free(device_node) en graph_util_parse_dai().