Base de datos CVE

Existe una vulnerabilidad de stack-based buffer overflow en el módulo EasyMesh de TP-Link Archer AX55 v4. Cuando el modo Mesh está habilitado, un atacante de LAN puede enviar una entrada manipulada que provoque el bloqueo del daemon easymesh y que potencialmente permita lograr la ejecución remota de código en el dispositivo. La explotación exitosa puede provocar el bloqueo del daemon EasyMesh y potencialmente permitir la ejecución remota de código cuando el modo Mesh está habilitado. Esto puede tener un alto impacto en la confidencialidad, integridad y disponibilidad del dispositivo afectado.

MapLibre GL JS es una biblioteca de mapas de teselas vectoriales interactivos para navegadores web. Antes de la versión 6.4.1, DOM.sanitize() en src/util/dom.ts itera elem.attributes como un NamedNodeMap activo, mientras removeAttributes() elimina atributos de la misma colección, desplazando los índices y omitiendo un atributo peligroso adyacente. Un atacante que controle cadenas de atribución de estilo de terceros no confiables o atribuciones personalizadas proporcionadas por el usuario puede suministrar atributos peligrosos consecutivos, haciendo que un atributo como onload u ontoggle sobreviva a la sanitización y se ejecute cuando el control de atribución inserta el contenido en innerHTML. La víctima debe renderizar el contenido del mapa afectado para que el script se ejecute. Este problema se solucionó en la versión 6.4.1.

Confusión de tipos en V8 en Google Chrome anterior a 152.0.7977.82 permitió a un atacante remoto ejecutar código arbitrario dentro del sandbox mediante una página HTML manipulada. (Gravedad de seguridad de Chromium: Alta)

GeoNetwork es una aplicación de catálogo para gestionar recursos con referencia espacial. Antes de las versiones 4.4.12 y 4.2.17, el endpoint de la API para crear un nuevo formatter mediante la carga de archivos está desprotegido y permite la carga de archivos externos no controlados. Un atacante no autenticado puede cargar archivos formatter `.xsl` o `.zip` arbitrarios en el servidor. Un atacante no autenticado puede escribir archivos arbitrarios en el directorio formatter de GeoNetwork. Por sí solo, esto constituye un acceso de escritura no autorizado al almacenamiento del servidor. El problema está corregido en las versiones 4.4.12 y 4.2.17 de GeoNetwork.

GeoNetwork es una aplicación de catálogo para gestionar recursos con referencia espacial. Antes de las versiones 4.4.12 y 4.2.17, el procesador XSLT Saxon utilizado para renderizar formateadores está configurado sin procesamiento seguro (`FEATURE_SECURE_PROCESSING`) y sin deshabilitar las funciones de extensión Java (`ALLOW_EXTERNAL_FUNCTIONS`). Cualquier hoja de estilo cargada por GeoNetwork puede por tanto invocar `java.lang.Runtime.exec()` o `java.lang.ProcessBuilder` directamente, logrando la ejecución arbitraria de comandos como el usuario del proceso GeoNetwork. Un usuario con privilegios suficientes para subir un formateador puede entregar un archivo `.xsl` que contiene una llamada de extensión Java que ejecuta comandos arbitrarios del SO con los privilegios del proceso GeoNetwork. El problema está parcheado en las versiones 4.4.12 y 4.2.17 de GeoNetwork.

Hermes Agent 0.18.2 through 0.21.0, corregido en el commit f6234d0, contiene una vulnerabilidad de ejecución remota de código que permite a los atacantes ejecutar comandos arbitrarios del sistema operativo suministrando un repositorio malicioso con un .git/config manipulado que establece core.fsmonitor en un comando controlado por el atacante. Cuando un usuario abre el repositorio malicioso y envía cualquier mensaje, el agente desencadena una actualización del índice de git status que ejecuta el comando inyectado en el contexto del proceso del usuario, exponiendo todo el entorno, incluidas las API keys del proveedor configurado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Añadir comprobación de límites para la longitud del subtipo CRAT El analizador CRAT valida que el encabezado del subtipo quepa dentro de la imagen, pero no verifica que la longitud anunciada del subtipo quepa. Una tabla CRAT malformada con un campo de longitud sobredimensionado provoca lecturas fuera de los límites cuando kfd_parse_subtype() convierte el encabezado en estructuras de subtipo específicas. Añadir validación de que sub_type_hdr + length no exceda el límite de la imagen antes de analizar el contenido del subtipo. (seleccionado del commit 48e1d1e6e8798aef0312e68d8e586021b5b3cf4d)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Comprobar sk_state antes de sk_protocol en bpf_tcp_*_syncookie bpf_tcp_gen_syncookie y bpf_tcp_check_syncookie aceptan un puntero de socket 'sk' con tipo de argumento ARG_PTR_TO_BTF_ID_SOCK_COMMON. Sin embargo, acceden a sk->sk_protocol sin validar si 'sk' representa un socket completo. Corregir este problema comprobando sk->sk_state != TCP_LISTEN antes de inspeccionar sk->sk_protocol tanto en bpf_tcp_gen_syncookie como en bpf_tcp_check_syncookie. Dado que los mini-sockets nunca están en el estado TCP_LISTEN, la condición hace cortocircuito y evita desreferenciar campos específicos de fullsock.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir «drm/amdgpu: fix aperture mapping leak» La liberación de devres sigue un orden LIFO. El nodo devres de aperture se registró después del nodo del dispositivo DRM, por lo que devres_release_all() desmapea la aperture antes de que la callback de liberación del dispositivo DRM ejecute amdgpu_device_fini_sw(). Las callbacks IP sw_fini (p. ej., vcn_v4_0_sw_fini) escriben en fw_shared a través de un puntero derivado de aper_base_kaddr, lo que provoca un fallo de página del kernel al fallar la sonda / durante la reversión: BUG: unable to handle page fault ... PMD 0 RIP: vcn_v4_0_sw_fini+0x7b/0x170 [amdgpu] Call Trace: amdgpu_device_fini_sw amdgpu_driver_release_kms devm_drm_dev_init_release devres_release_all Esto revierte el commit d871e99879cb5fd1fa798b006b4888887e63a17a. (seleccionado mediante cherry-pick del commit 336e0cd576817ac64a4b394ca2b3680029f3e37f)

En el Linux kernel, se ha resuelto la siguiente vulnerabilidad: selinux: rechazar un recuento de permisos de clase inferior a su common heredado security_get_permissions() mapea los permisos de un common heredado en un array dimensionado por el permissions.nprim propio de la clase, pero class_read() toma ese nprim literalmente de la imagen de política y nunca comprueba que cubra el common. Una clase que hereda un common de N permisos mientras declara un nprim menor es aceptada, y al cargar los permisos del common se escriben más allá del array dimensionado para la clase -- una escritura heap fuera de límites. Rechazar una clase cuyo recuento de permisos esté por debajo del de su common heredado. Las políticas bien formadas, donde el recuento de la clase ya incluye los permisos heredados, no se ven afectadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables_offload: suprimir WARN_ON_ONCE para ENOMEM en la ruta de aborto En nft_flow_rule_offload_abort(), se dispara WARN_ON_ONCE(err) en cada error durante el rollback, incluido -ENOMEM. Los fallos de asignación de memoria son esperables en condiciones de poca memoria y no indican un error del kernel. Trace, por ejemplo: nft_flow_offload_chain() // FLOW_BLOCK_BIND nft_flow_block_chain() nft_chain_offload_cmd() nft_block_offload_cmd() ->ndo_setup_tc() nsim_setup_tc() flow_block_cb_setup_simple() flow_block_cb_alloc() // falla con -ENOMEM El aviso se reprodujo en el kernel estable 5.10 bajo presión de memoria mediante inyección de fallos, pero el fallo subyacente también existe en mainline, como lo demuestra el rastro de ENOMEM anterior. El siguiente splat se activó durante el procesamiento de transacciones de nf_tables: WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_abort net/netfilter/nf_tables_offload.c:532 [inline] WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_commit+0x971/0xcd0 net/netfilter/nf_tables_offload.c:591 Modules linked in: CPU: 0 PID: 8567 Comm: syz-executor.0 Not tainted 5.10.260-syzkaller #0 Hard

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers Los manejadores de interrupciones toman un puntero a struct device y llaman a dev_get_drvdata() para obtener los datos del controlador. Sin embargo, los datos del controlador solo se establecen al final del probe, después de devm_request_irq(), por lo que una interrupción producida en ese intervalo hace que los manejadores pasen un puntero NULL a readl() y provoque un fallo. Pase los datos privados directamente como argumento de devm_request_irq() en lugar del puntero al dispositivo, coincidiendo con lo que esperan los manejadores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_packet: No enviar datos de longitud cero en tpacket_snd(). syzbot informó de un WARNING en __dev_queue_xmit() provocado a través de tpacket_snd(): skb_assert_len WARNING: at include/linux/skbuff.h:2753 skb_assert_len WARNING: at __dev_queue_xmit+0x21bc/0x4970 net/core/dev.c:4781 Rastro de llamadas: <TASK> dev_queue_xmit include/linux/netdevice.h:3448 [inline] packet_xmit+0x243/0x310 net/packet/af_packet.c:276 tpacket_snd net/packet/af_packet.c:2907 [inline] packet_sendmsg+0x28d6/0x4eb0 net/packet/af_packet.c:3134 Cuando se envían paquetes de 0 bytes a través del búfer en anillo TPACKET en dispositivos sin cabecera hardware (por ejemplo, dev->hard_header_len == 0), tpacket_fill_skb() rellena un skb con skb->len == 0 y devuelve 0. Entonces tpacket_snd() reenvía ese skb vacío a packet_xmit(), lo que provoca que __dev_queue_xmit() alcance skb_assert_len(skb). Existen comprobaciones similares en packet_snd() mediante el commit dc633700f00f ("net/af_packet: check len when min_header_len equals to 0") y en packet_sendmsg_spkt() mediante el commit 6a341729fb31 ("af_packet: Don't send zero-byte data in packet_sendmsg_spkt()."). Devuelve -EINVAL en tpacket_fill_skb() cuando skb->len es cero para rechazar paquetes de longitud cero en tpacket_snd().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: amba-pl011: sincronizar la finalización de DMA dmaengine_terminate_all() no espera a un callback en ejecución, por lo que el callback de TX aún puede tocar el búfer de TX después de liberarlo. El temporizador de sondeo de RX lee los búferes de RX sin el bloqueo del puerto. Cambie a dmaengine_terminate_sync() y elimine el temporizador de RX antes de liberar los búferes.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net: remove WARN_ON_ONCE() from sk_mc_loop() sk_mc_loop() puede llamarse para sockets que no son ni AF_INET ni AF_INET6 (p. ej. sockets AF_PACKET al enviar paquetes vía raw/packet socket sobre dispositivos virtuales como VRF o ipvlan). En tales casos, sk_family no es AF_INET/AF_INET6 y sk_mc_loop() cae a través de la sentencia switch y desencadena WARN_ON_ONCE(1). Los sockets no INET no admiten las opciones IP_MULTICAST_LOOP o IPV6_MULTICAST_LOOP, por lo que loopback debería ser true por defecto sin generar una advertencia.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: ata: pata_sl82c105: fix bridge revision use-after-free pci_get_slot() devuelve un dispositivo PCI referenciado. El commit 44c10138fd4b ("PCI: Change all drivers to use pci_device->revision") reemplazó una lectura del espacio de configuración con el acceso directo al campo de revisión en caché, pero dejó ese acceso después de pci_dev_put(). Por lo tanto, el bridge puede ser liberado antes de que se lea su revisión. Lea la revisión antes de descartar la referencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: eliminar el relleno con ceros de CAP_SYS_RAWIO en dev_validate_header dev_validate_header() lee dev->hard_header_len directamente al rellenar con ceros las cabeceras cortas de la capa de enlace para los titulares de CAP_SYS_RAWIO: if (capable(CAP_SYS_RAWIO)) { memset(ll_header + len, 0, dev->hard_header_len - len); return true; } Las rutas de envío de paquetes llaman a dev_validate_header() sobre skbs cuyo headroom fue asignado a partir de una lectura anterior de hard_header_len. Si el dispositivo se reconfigura de modo que dev->hard_header_len aumente antes de la validación, el memset escribe más allá del búfer reservado, una escritura fuera de los límites. Esta escritura fuera de los límites queda enmascarada hoy en algunas rutas SOCK_RAW porque el mismo aumento concurrente puede hacer primero que skb_push() supere el headroom reservado y provoque skb_under_panic(). Elimine la rama de relleno con ceros antes de hacer coherentes esas lecturas de hard_header_len, de modo que las correcciones de instantáneas no conviertan un pánico ruidoso en una sobrescritura silenciosa. Esta ruta solo se alcanza para protocolos L2 de longitud variable, donde len < hard_header_len pero len >= min_header_len. Ningún protocolo L2 de longitud variable restante en el árbol implementa header_ops->validate, y el desvío CAP_SYS_RAWIO que rellena con ceros y acepta cabeceras cortas no tiene valor real más allá de permitir probar entradas intencionadamente malformadas. Elimine la rama CAP_SYS_RAWIO. Las lecturas restantes de dev->hard_header_len en dev_validate_header() son solo comparaciones y no tienen impacto en la seguridad de la memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ring-buffer: Corrige el fallo al pasar ERR_PTR a kthread_stop() En el bucle de limpieza out_free de test_ringbuffer(), la comprobación `!rb_threads[cpu]` solo detecta entradas NULL y omite las entradas que contienen un ERR_PTR. rb_threads[] es estático, por lo que las posiciones no asignadas son NULL. Pero cuando kthread_run_on_cpu() falla para una cpu, almacena ERR_PTR(-ENOMEM) (o -EINTR) en rb_threads[cpu] antes de que el bucle de creación salte a out_free. Esa entrada no es NULL, por lo que la antigua comprobación `!ptr` no interrumpe el bucle y la limpieza continúa llamando a kthread_stop() sobre el ERR_PTR. kthread_stop() desreferencia entonces el puntero no válido, provocando el fallo del kernel durante la prueba automática de late_initcall. registros del fallo: BUG: kernel NULL pointer dereference, address: 000000000000001c Oops: 0002 [#1] SMP NOPTI CPU: 1 PID: 1 Comm: swapper/0 Not tainted 7.2.0-rc6-dirty #7 PREEMPT(lazy) RIP: 0010:kthread_stop+0x2e/0x220 RBX: fffffffffffffff4 CR2: 000000000000001c Call Trace: <TASK> test_ringbuffer+0x1ec/0x650 do_one_initcall+0x6c/0x2c0 kernel_init_freeable+0x21d/0x420 kernel_init+0x15/0x1c0 ret_from_fork+0x21b/0x320 </TASK> Kernel panic - not syncing: Fatal exception

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/mmu: Advertir y limpiar role.invalid al crear una página shadow secundaria Limpiar explícitamente role.invalid al derivar el rol de una página shadow secundaria de su padre para endurecer contra errores en otras partes de KVM, ya que violar el invariante de KVM de que las páginas inválidas NO están en la lista de páginas MMU activas conduce a un use-after-free debido a que __kvm_mmu_prepare_zap_page() usa list_add() en lugar de list_move() al procesar una página shadow inválida, es decir, hace que una mala situación sea mucho peor. Gritar fuerte si el padre es inválido, ya que significa que KVM ha omitido una comprobación de validez, es decir, KVM está intentando mapear memoria usando una raíz inválida/obsoleta, pero continuar ya que la secundaria, de lo contrario, sigue siendo una página shadow válida. ================================================================== BUG: KASAN: slab-use-after-free in __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm] Escritura de tamaño 8 en la dirección ff11000153dd1368 por la tarea repro/853 CPU

Anteriormente, un canal registrado en el chanList del mux no es utilizable hasta que se establece. Un peer malicioso podía inundar los incomingRequests del canal, provocando un deadlock en toda la conexión. Ahora, añadimos un estado established atómico, establecido cuando un canal se vuelve utilizable. Hasta ese momento, handlePacket descarta cada paquete que no sea la confirmación/fallo de apertura, sin bloquearse y sin cerrar la conexión.