Vulnerabilidades

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]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> linkwatch: usar __dev_put() en las funciones que llaman para prevenir UAF<br /> <br /> Después de que linkwatch_do_dev() llama a __dev_put() para liberar la referencia de linkwatch, el contador de referencias del dispositivo puede bajar a 1. En este punto, netdev_run_todo() puede continuar (ya que linkwatch_sync_dev() ve una lista vacía y regresa sin bloquear), esperar a que el contador de referencias llegue a 1 a través de netdev_wait_allrefs_any(), y luego liberar el dispositivo a través de kobject_put().<br /> <br /> Esto crea un uso después de liberación cuando __linkwatch_run_queue() intenta llamar a netdev_unlock_ops() en el dispositivo ya liberado.<br /> <br /> Tenga en cuenta que añadir el par netdev_lock_ops()/netdev_unlock_ops() en netdev_run_todo() antes de kobject_put() no funcionaría, porque netdev_lock_ops() es condicional - solo bloquea cuando netdev_need_ops_lock() devuelve verdadero. Si el dispositivo no requiere ops_lock, linkwatch no mantendrá ningún bloqueo, y netdev_run_todo() al adquirir el bloqueo no proporcionará sincronización.<br /> <br /> Solucione esto moviendo __dev_put() de linkwatch_do_dev() a sus funciones que llaman. La referencia del dispositivo se empareja lógicamente con la eliminación del dispositivo de la lista, por lo que es razonable que la función que realizó la eliminación de la lista lo libere. Esto permite colocar __dev_put() después de que todos los accesos al dispositivo estén completos, previniendo UAF.<br /> <br /> El error puede reproducirse añadiendo mdelay(2000) después de linkwatch_do_dev() en __linkwatch_run_queue(), luego ejecutando:<br /> <br /> ip tuntap add mode tun name tun_test<br /> ip link set tun_test up<br /> ip link set tun_test carrier off<br /> ip link set tun_test carrier on<br /> sleep 0.5<br /> ip tuntap del mode tun name tun_test<br /> <br /> Informe KASAN:<br /> <br /> ==================================================================<br /> BUG: KASAN: uso después de liberación in netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]<br /> BUG: KASAN: uso después de liberación in netdev_unlock_ops include/net/netdev_lock.h:47 [inline]<br /> BUG: KASAN: uso después de liberación in __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245<br /> Read of size 8 at addr ffff88804de5c008 by task kworker/u32:10/8123<br /> <br /> CPU: 0 UID: 0 PID: 8123 Comm: kworker/u32:10 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Workqueue: events_unbound linkwatch_event<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x156/0x4c9 mm/kasan/report.c:482<br /> kasan_report+0xdf/0x1a0 mm/kasan/report.c:595<br /> netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]<br /> netdev_unlock_ops include/net/netdev_lock.h:47 [inline]<br /> __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245<br /> linkwatch_event+0x8f/0xc0 net/core/link_watch.c:304<br /> process_one_work+0x9c2/0x1840 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x5da/0xe40 kernel/workqueue.c:3421<br /> kthread+0x3b3/0x730 kernel/kthread.c:463<br /> ret_from_fork+0x754/0xaf0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> ==================================================================

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: target: iscsi: Corrección de uso después de liberación en iscsit_dec_session_usage_count()<br /> <br /> En iscsit_dec_session_usage_count(), la función llama a complete() mientras mantiene el sess-&amp;gt;session_usage_lock. Similar a la lógica de conteo de uso de la conexión, el hilo en espera señalado por complete() (por ejemplo, en la ruta de liberación de la sesión) puede despertar y liberar la estructura iscsit_session inmediatamente.<br /> <br /> Esto crea una condición de carrera donde el hilo actual puede intentar ejecutar spin_unlock_bh() en una estructura de sesión que ya ha sido desasignada, lo que resulta en un KASAN slab-uso después de liberación.<br /> <br /> Para resolver esto, liberar el session_usage_lock antes de llamar a complete() para asegurar que todas las desreferencias del puntero sess hayan terminado antes de que se permita al hilo en espera proceder con la desasignación.