Vulnerabilidades

El sistema adolece de la ausencia de una verificación de firma de módulo del kernel. Si un atacante puede ejecutar comandos en nombre del usuario root (debido a vulnerabilidades adicionales), entonces también puede cargar módulos del kernel personalizados al espacio del kernel y ejecutar código en el contexto del kernel. Dicha falla puede llevar a tomar el control de todo el sistema.<br /> <br /> Identificado por primera vez en un Nissan Leaf ZE1 fabricado en 2020.

La falla específica existe dentro de la pila Bluetooth desarrollada por Alps Alpine de la ECU de infoentretenimiento fabricada por Bosch. El problema se debe a la falta de validación adecuada de límites de los datos proporcionados por el usuario, lo que puede resultar en un desbordamiento de búfer basado en pila al recibir un paquete específico en el canal L2CAP de capa superior establecido. Un atacante puede aprovechar esta vulnerabilidad para obtener ejecución remota de código en la ECU de infoentretenimiento con privilegios de root.<br /> <br /> Identificado por primera vez en Nissan Leaf ZE1 fabricado en 2020.

El fallo específico existe dentro de la pila Bluetooth desarrollada por Alps Alpine de la ECU de infoentretenimiento fabricada por Bosch. El problema resulta de la falta de validación adecuada de límites de los datos proporcionados por el usuario, lo que puede resultar en un desbordamiento de búfer basado en pila al recibir un paquete específico en el canal L2CAP de capa superior establecido. Un atacante puede aprovechar esta vulnerabilidad para obtener ejecución remota de código en la ECU de infoentretenimiento con privilegios de root.<br /> <br /> Identificado por primera vez en el Nissan Leaf ZE1 fabricado en 2020.

Hay una vulnerabilidad de configuración errónea dentro de la ECU de infoentretenimiento fabricada por BOSCH. La vulnerabilidad se produce durante la fase de inicio de un servicio systemd específico y, como resultado, se activarán las siguientes funciones de desarrollador: el cortafuegos deshabilitado y el servidor SSH iniciado.<br /> <br /> Identificada por primera vez en el Nissan Leaf ZE1 fabricado en 2020.

El protocolo de comunicación RF en el sistema de alarma de coche Micca KE700 no cifra sus tramas de datos. Un atacante con una herramienta de intercepción de radio (p. ej., SDR) puede capturar el número aleatorio y los contadores transmitidos en texto claro, lo cual es información sensible necesaria para la autenticación.

El fallo específico existe dentro de la pila Bluetooth desarrollada por Alps Alpine de la ECU de infoentretenimiento fabricada por Bosch. El problema se debe a la falta de validación adecuada de límites de los datos proporcionados por el usuario, lo que puede resultar en un desbordamiento de búfer basado en pila al recibir un paquete específico en el canal L2CAP de capa superior establecido. Un atacante puede aprovechar esta vulnerabilidad para obtener ejecución remota de código en la ECU de infoentretenimiento con privilegios de root.<br /> <br /> Identificado por primera vez en un Nissan Leaf ZE1 fabricado en 2020.

La ECU de infoentretenimiento fabricada por Bosch utiliza un módulo RH850 para la comunicación CAN. El RH850 está conectado al infoentretenimiento a través de la interfaz INC mediante un protocolo personalizado. Existe una vulnerabilidad durante el procesamiento de solicitudes de este protocolo en el lado V850 que permite a un atacante con ejecución de código en el SoC principal de infoentretenimiento realizar ejecución de código en el módulo RH850 y posteriormente enviar mensajes CAN arbitrarios a través del bus CAN conectado.<br /> <br /> Identificada por primera vez en el Nissan Leaf ZE1 fabricado en 2020.

El plugin Ecwid by Lightspeed Ecommerce Shopping Cart para WordPress es vulnerable a la escalada de privilegios en todas las versiones hasta la 7.0.7, inclusive. Esto se debe a una comprobación de capacidad faltante en la función &amp;#39;save_custom_user_profile_fields&amp;#39;. Esto permite que atacantes autenticados, con permisos mínimos como un suscriptor, suministren el parámetro &amp;#39;ec_store_admin_access&amp;#39; durante una actualización de perfil y obtengan acceso de administrador de tienda al sitio.

El plugin Element Pack Addons para Elementor para WordPress es vulnerable a lecturas de archivos arbitrarios en todas las versiones hasta, e incluyendo, 8.3.17 a través del widget SVG y una falta de validación suficiente de archivos en la función &amp;#39;render_svg&amp;#39;. Esto hace posible que atacantes autenticados, con acceso de nivel de colaborador y superior, lean el contenido de archivos arbitrarios en el servidor, que pueden contener información sensible.

El plugin de protección contra el correo no deseado, Antispam, Cortafuegos de CleanTalk para WordPress es vulnerable a la instalación arbitraria de plugins no autorizada debido a una omisión de autorización mediante suplantación de DNS inverso (registro PTR) en la función &amp;#39;checkWithoutToken&amp;#39; en todas las versiones hasta la 6.71, inclusive. Esto permite a atacantes no autenticados instalar y activar plugins arbitrarios, lo que puede aprovecharse para lograr la ejecución remota de código si otro plugin vulnerable está instalado y activado. Nota: Esto solo es explotable en sitios con una clave API no válida.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> spi: tegra210-quad: Proteger curr_xfer en tegra_qspi_combined_seq_xfer<br /> <br /> El campo curr_xfer es leído por el manejador IRQ sin mantener el bloqueo para verificar si una transferencia está en curso. Al limpiar curr_xfer en el bucle de transferencia de secuencia combinada, protegerlo con el spinlock para evitar una condición de carrera con el manejador de interrupciones.<br /> <br /> Proteger la limpieza de curr_xfer en la ruta de salida de tegra_qspi_combined_seq_xfer() con el spinlock para evitar una condición de carrera con el manejador de interrupciones que lee este campo.<br /> <br /> Sin esta protección, el manejador IRQ podría leer un valor curr_xfer parcialmente actualizado, lo que llevaría a una desreferencia de puntero NULL o uso después de liberación.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: cpsw_new: Ejecutar la devolución de llamada ndo_set_rx_mode en una cola de trabajo<br /> <br /> El commit 1767bb2d47b7 (&amp;#39;ipv6: mcast: No mantener RTNL para IPV6_ADD_MEMBERSHIP y MCAST_JOIN_GROUP.&amp;#39;) eliminó el bloqueo RTNL para las operaciones IPV6_ADD_MEMBERSHIP y MCAST_JOIN_GROUP. Sin embargo, este cambio desencadenó el siguiente rastreo de llamadas en mi placa BeagleBone Black:<br /> WARNING: net/8021q/vlan_core.c:236 en vlan_for_each+0x120/0x124, CPU#0: rpcbind/496<br /> RTNL: aserción fallida en net/8021q/vlan_core.c (236)<br /> Módulos enlazados:<br /> CPU: 0 UID: 997 PID: 496 Comm: rpcbind No contaminado 6.19.0-rc6-next-20260122-yocto-standard+ #8 PREEMPT<br /> Nombre del hardware: Generic AM33XX (Flattened Device Tree)<br /> Rastreo de llamadas:<br /> unwind_backtrace desde show_stack+0x28/0x2c<br /> show_stack desde dump_stack_lvl+0x30/0x38<br /> dump_stack_lvl desde __warn+0xb8/0x11c<br /> __warn desde warn_slowpath_fmt+0x130/0x194<br /> warn_slowpath_fmt desde vlan_for_each+0x120/0x124<br /> vlan_for_each desde cpsw_add_mc_addr+0x54/0xd8<br /> cpsw_add_mc_addr desde __hw_addr_ref_sync_dev+0xc4/0xec<br /> __hw_addr_ref_sync_dev desde __dev_mc_add+0x78/0x88<br /> __dev_mc_add desde igmp6_group_added+0x84/0xec<br /> igmp6_group_added desde __ipv6_dev_mc_inc+0x1fc/0x2f0<br /> __ipv6_dev_mc_inc desde __ipv6_sock_mc_join+0x124/0x1b4<br /> __ipv6_sock_mc_join desde do_ipv6_setsockopt+0x84c/0x1168<br /> do_ipv6_setsockopt desde ipv6_setsockopt+0x88/0xc8<br /> ipv6_setsockopt desde do_sock_setsockopt+0xe8/0x19c<br /> do_sock_setsockopt desde __sys_setsockopt+0x84/0xac<br /> __sys_setsockopt desde ret_fast_syscall+0x0/0x5<br /> <br /> Este rastreo ocurre porque se llama a vlan_for_each() dentro de cpsw_ndo_set_rx_mode(), que espera que el bloqueo RTNL esté mantenido. Dado que modificar vlan_for_each() para operar sin el bloqueo RTNL no es sencillo, y debido a que ndo_set_rx_mode() se invoca tanto con como sin el bloqueo RTNL a través de diferentes rutas de código, simplemente añadir rtnl_lock() en cpsw_ndo_set_rx_mode() no es una solución viable.<br /> <br /> Para resolver este problema, optamos por ejecutar el procesamiento real dentro de una cola de trabajo, siguiendo el enfoque utilizado por el controlador icssg-prueth.