Vulnerabilidades

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 'save_custom_user_profile_fields'. Esto permite que atacantes autenticados, con permisos mínimos como un suscriptor, suministren el parámetro 'ec_store_admin_access' 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 'render_svg'. 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 'checkWithoutToken' 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.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: cls_u32: usar skb_header_pointer_careful()<br /> <br /> skb_header_pointer() no valida completamente los valores negativos de @offset.<br /> <br /> Usar skb_header_pointer_careful() en su lugar.<br /> <br /> GangMin Kim proporcionó un informe y una reproducción engañando a u32_classify():<br /> <br /> BUG: KASAN: slab-out-of-bounds en u32_classify+0x1180/0x11b0<br /> net/sched/cls_u32.c:221

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> smb/cliente: corrige una fuga de memoria en smb2_open_file()<br /> <br /> Reproductor:<br /> <br /> 1. servidor: los directorios se exportan de solo lectura<br /> 2. cliente: mount -t cifs //${server_ip}/export /mnt<br /> 3. cliente: dd if=/dev/zero of=/mnt/file bs=512 count=1000 oflag=direct<br /> 4. cliente: umount /mnt<br /> 5. cliente: sleep 1<br /> 6. cliente: modprobe -r cifs<br /> <br /> El mensaje de error es el siguiente:<br /> <br /> =============================================================================<br /> BUG cifs_small_rq (No contaminado): Objetos restantes en __kmem_cache_shutdown()<br /> -----------------------------------------------------------------------------<br /> <br /> Object 0x00000000d47521be @offset=14336<br /> ...<br /> ADVERTENCIA: mm/slub.c:1251 en __kmem_cache_shutdown+0x34e/0x440, CPU#0: modprobe/1577<br /> ...<br /> Traza de Llamada:<br /> <br /> kmem_cache_destroy+0x94/0x190<br /> cifs_destroy_request_bufs+0x3e/0x50 [cifs]<br /> cleanup_module+0x4e/0x540 [cifs]<br /> __se_sys_delete_module+0x278/0x400<br /> __x64_sys_delete_module+0x5f/0x70<br /> x64_sys_call+0x2299/0x2ff0<br /> do_syscall_64+0x89/0x350<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ...<br /> kmem_cache_destroy cifs_small_rq: La caché de slab aún tiene objetos cuando se llama desde cifs_destroy_request_bufs+0x3e/0x50 [cifs]<br /> ADVERTENCIA: mm/slab_common.c:532 en kmem_cache_destroy+0x16b/0x190, CPU#0: modprobe/1577

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dpaa2-switch: evitar la desreferencia de ZERO_SIZE_PTR cuando num_ifs es cero<br /> <br /> El controlador asigna arreglos para puertos, FDBs y bloques de filtro usando kcalloc() con ethsw-&amp;gt;sw_attr.num_ifs como el recuento de elementos. Cuando el dispositivo reporta cero interfaces (ya sea debido a la configuración del hardware o a problemas de firmware), kcalloc(0, ...) devuelve ZERO_SIZE_PTR (0x10) en lugar de NULL.<br /> <br /> Más tarde en dpaa2_switch_probe(), la inicialización de NAPI accede incondicionalmente a ethsw-&amp;gt;ports[0]-&amp;gt;netdev, lo que intenta desreferenciar ZERO_SIZE_PTR (dirección 0x10), resultando en un pánico del kernel.<br /> <br /> Añadir una verificación para asegurar que num_ifs sea mayor que cero después de recuperar los atributos del dispositivo. Esto evita las asignaciones de tamaño cero y la subsiguiente desreferencia de puntero inválido.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> spi: tegra210-quad: Proteger la comprobación de curr_xfer en el manejador IRQ<br /> <br /> Ahora que todos los demás accesos a curr_xfer se realizan bajo el bloqueo, proteger la comprobación de NULL de curr_xfer en tegra_qspi_isr_thread() con el spinlock. Sin esta protección, la siguiente condición de carrera puede ocurrir:<br /> <br /> CPU0 (hilo ISR) CPU1 (ruta de tiempo de espera)<br /> ---------------- -------------------<br /> if (!tqspi-&amp;gt;curr_xfer)<br /> // ve no-NULL<br /> spin_lock()<br /> tqspi-&amp;gt;curr_xfer = NULL<br /> spin_unlock()<br /> handle_*_xfer()<br /> spin_lock()<br /> t = tqspi-&amp;gt;curr_xfer // ¡NULL!<br /> ... t-&amp;gt;len ... // ¡Desreferencia de NULL!<br /> <br /> Con este parche, todos los accesos a curr_xfer están ahora correctamente sincronizados.<br /> <br /> Aunque todos los accesos a curr_xfer se realizan bajo el bloqueo, en tegra_qspi_isr_thread() comprueba si es NULL, libera el bloqueo y lo vuelve a adquirir más tarde en handle_cpu_based_xfer()/handle_dma_based_xfer(). Existe la posibilidad de una actualización intermedia, lo que podría causar una desreferencia de puntero NULL.<br /> <br /> Para manejar esto, añadir una comprobación de NULL dentro de los manejadores después de adquirir el bloqueo. Esto asegura que si la ruta de tiempo de espera ya ha limpiado curr_xfer, el manejador regresará de forma segura sin desreferenciar el puntero NULL.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ALSA: usb-audio: Prevenir un número excesivo de tramas<br /> <br /> En este caso, el usuario construyó los parámetros con maxpacksize 40 para una tasa de 22050 / pps 1000, y packsize[0] 22 packsize[1] 23. El tamaño del búfer para cada URB de datos es maxpacksize * paquetes, que en este ejemplo es 40 * 6 = 240; Cuando el usuario realiza una operación de escritura para enviar datos de audio al flujo de reproducción ALSA PCM, el número calculado de tramas es packsize[0] * paquetes = 264, lo que excede el tamaño del búfer URB asignado, desencadenando el problema de fuera de límites (OOB) reportado por syzbot [1].<br /> <br /> Se añadió una comprobación para el número de tramas URB de datos individuales al calcular el número de tramas para prevenir [1].<br /> <br /> [1]<br /> BUG: KASAN: slab-out-of-bounds en copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487<br /> Escritura de tamaño 264 en la dirección ffff88804337e800 por la tarea syz.0.17/5506<br /> Traza de Llamada:<br /> copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487<br /> prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611<br /> prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> macvlan: arreglar la recuperación de errores en macvlan_common_newlink()<br /> <br /> valis proporcionó una buena reproducción para colapsar el kernel:<br /> <br /> ip link add p1 type veth peer p2<br /> ip link set address 00:00:00:00:00:20 dev p1<br /> ip link set up dev p1<br /> ip link set up dev p2<br /> <br /> ip link add mv0 link p2 type macvlan mode source<br /> ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20<br /> <br /> ping -c1 -I p1 1.2.3.4<br /> <br /> También proporcionó un análisis muy detallado:<br /> <br /> &amp;#39;El problema se activa cuando se crea un nuevo enlace macvlan con el modo MACVLAN_MODE_SOURCE y el parámetro MACVLAN_MACADDR_ADD (o MACVLAN_MACADDR_SET), el dispositivo inferior ya tiene un puerto macvlan y register_netdevice() llamado desde macvlan_common_newlink() falla (por ejemplo, debido al nombre de enlace no válido).<br /> <br /> En este caso, macvlan_hash_add_source es llamado desde macvlan_change_sources() / macvlan_common_newlink():<br /> <br /> Esto añade una referencia a vlan al vlan_source_hash del puerto usando macvlan_source_entry.<br /> <br /> vlan es un puntero a los datos privados del enlace que se está creando.<br /> <br /> Cuando register_netdevice() falla, el error es devuelto desde macvlan_newlink() a rtnl_newlink_create():<br /> <br /> if (ops-&amp;gt;newlink)<br /> err = ops-&amp;gt;newlink(dev, &amp;amp;params, extack);<br /> else<br /> err = register_netdevice(dev);<br /> if (err &amp;lt; 0) {<br /> free_netdev(dev);<br /> goto out;<br /> }<br /> <br /> y se llama a free_netdev(), causando un kvfree() en la estructura net_device que todavía está referenciada en la entrada de origen adjunta al puerto macvlan del dispositivo inferior.<br /> <br /> Ahora, todos los paquetes enviados en el puerto macvlan con una dirección MAC de origen coincidente activarán un uso después de liberación en macvlan_forward_source().&amp;#39;<br /> <br /> Con todo eso, mi solución es asegurarme de que llamamos a macvlan_flush_sources() independientemente del valor de @create cada vez que se toma la ruta "goto destroy_macvlan_port;".<br /> <br /> Muchas gracias a valis por hacer seguimiento de este problema.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ice: Soluciona la desreferencia de puntero NULL de PTP durante la reconstrucción de VSI<br /> <br /> Soluciona la condición de carrera donde el trabajo periódico de PTP se ejecuta mientras VSI está siendo reconstruido, accediendo a vsi-&amp;gt;rx_rings NULL.<br /> <br /> La secuencia fue:<br /> 1. ice_ptp_prepare_for_reset() cancela el trabajo de PTP<br /> 2. ice_ptp_rebuild() encola inmediatamente el trabajo de PTP<br /> 3. La reconstrucción de VSI ocurre DESPUÉS de ice_ptp_rebuild()<br /> 4. El trabajo de PTP se ejecuta y accede a vsi-&amp;gt;rx_rings NULL<br /> <br /> Corrección: Mantener el trabajo de PTP cancelado durante la reconstrucción, solo encolarlo después de que la reconstrucción de VSI se complete en ice_rebuild().<br /> <br /> Se añadió la función auxiliar ice_ptp_queue_work() para encapsular la lógica de encolamiento del trabajo de PTP, asegurando que solo se encole cuando PTP es compatible y el estado es ICE_PTP_READY.<br /> <br /> Registro de error:<br /> [ 121.392544] ice 0000:60:00.1: Reinicio de PTP exitoso<br /> [ 121.392692] BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000000<br /> [ 121.392712] #PF: acceso de lectura de supervisor en modo kernel<br /> [ 121.392720] #PF: error_code(0x0000) - página no presente<br /> [ 121.392727] PGD 0<br /> [ 121.392734] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp-0000:60 Tainted: G S 6.19.0-rc6+ #4 PREEMPT(voluntary)<br /> [ 121.392761] Tainted: [S]=CPU_OUT_OF_SPEC<br /> [ 121.392773] RIP: 0010:ice_ptp_update_cached_phctime+0xbf/0x150 [ice]<br /> [ 121.393042] Traza de Llamada:<br /> [ 121.393047] <br /> [ 121.393055] ice_ptp_periodic_work+0x69/0x180 [ice]<br /> [ 121.393202] kthread_worker_fn+0xa2/0x260<br /> [ 121.393216] ? __pfx_ice_ptp_periodic_work+0x10/0x10 [ice]<br /> [ 121.393359] ? __pfx_kthread_worker_fn+0x10/0x10<br /> [ 121.393371] kthread+0x10d/0x230<br /> [ 121.393382] ? __pfx_kthread+0x10/0x10<br /> [ 121.393393] ret_from_fork+0x273/0x2b0<br /> [ 121.393407] ? __pfx_kthread+0x10/0x10<br /> [ 121.393417] ret_from_fork_asm+0x1a/0x30<br /> [ 121.393432]