Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bridge: corrige el refcnt dst del túnel vlan al salir El código del túnel de salida usa dst_clone() y establece directamente el resultado que es incorrecto porque la entrada puede tener 0 refcnt o ya estar eliminada , causando varios problemas. También activa WARN_ON() en dst_hold()[1] cuando no se puede tomar una referencia. Solucionelo usando dst_hold_safe() y verificando si realmente se tomó una referencia antes de configurar el dst. [1] Registro dmesg WARN_ON y siguientes errores de referencia ADVERTENCIA: CPU: 5 PID: 38 en include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [puente] Módulos vinculados en: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net CPU : 5 PID: 38 Comm: ksoftirqd/5 Kdump: cargado Contaminado: GW 5.13.0-rc3+ #360 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 01/04/2014 RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [puente] Código: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 f6 e8 64 a.C. 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49 RSP: 0018:ffff8881003d39e8 EFLAGS: 00010246 RAX: 00000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0 RBP: ffff8881040c6700 R08: 0000000000000000 R09: 00000000000000001 R10: 2ce93d0054fe0d00 R11: d00000e0000 R12: ffff888109515000 R13: 0000000000000000 R14: 0000000000000001 R15: 00000000000000401 FS: 0000000000000000(0000) 8822bf40000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0 Seguimiento de llamadas: br_handle_vlan+0xbc/0xca [puente] _forward+0x23/0x164 [puente] delivery_clone+0x41/0x48 [puente] br_handle_frame_finish+0x36f/ 0x3aa [puente] ? skb_dst+0x2e/0x38 [puente]? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [puente]? br_handle_frame_finish+0x3aa/0x3aa [puente] br_handle_frame+0x2c3/0x377 [puente]? __skb_pull+0x33/0x51? vlan_do_receive+0x4f/0x36a? br_handle_frame_finish+0x3aa/0x3aa [puente] __netif_receive_skb_core+0x539/0x7c6? __list_del_entry_valid+0x16e/0x1c2 __netif_receive_skb_list_core+0x6d/0xd6 netif_receive_skb_list_internal+0x1d9/0x1fa gro_normal_list+0x22/0x3e dev_gro_receive+0x55b/0x600 ? detach_buf_split+0x58/0x140 napi_gro_receive+0x94/0x12e virtnet_poll+0x15d/0x315 [virtio_net] __napi_poll+0x2c/0x1c9 net_rx_action+0xe6/0x1fb __do_softirq+0x115/0x2d8 run_ksoftirq d+0x18/0x20 smpboot_thread_fn+0x183/0x19c ? smpboot_unregister_percpu_thread+0x66/0x66 kthread+0x10a/0x10f? kthread_mod_delayed_work+0xb6/0xb6 ret_from_fork+0x22/0x30 ---[ end trace 49f61b07f775fd2b ]--- dst_release: dst:00000000c02d677a refcnt:-1 dst_release underflow

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bridge: corrige la desreferencia del puntero null del túnel vlan dst Este parche corrige una desreferencia del puntero null de Tunnel_dst debido al acceso sin bloqueo en la ruta de salida del túnel. Al eliminar un túnel VLAN, el puntero Tunnel_dst se establece en NULL sin esperar un período de gracia (es decir, mientras aún se puede utilizar) y los paquetes que salen lo desreferencian sin verificarlo. Use READ/WRITE_ONCE para anotar el uso sin bloqueo de Tunnel_id, use RCU para acceder a Tunnel_dst y asegúrese de que se lea solo una vez y se verifique en la ruta de salida. El dst ya está correctamente protegido por la RCU, por lo que no necesitamos hacer nada sofisticado más que asegurarnos de que Tunnel_id y Tunnel_dst se lean solo una vez y se verifiquen en la ruta de salida.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:ll_temac: Asegúrate de liberar skb cuando esté completamente utilizado. Con el puntero skb acoplado en la BD TX, tenemos una forma sencilla y eficaz de liberar el buffer skb. cuando la trama ha sido transmitida. Pero para evitar liberar el skb mientras todavía hay fragmentos del skb en uso, debemos aprovechar el BD TX del skb, no el primero. Sin esto, estamos haciendo use after free en el lado DMA, cuando el primer BD de un paquete BD de transmisión múltiple se considera completado en xmit_done y los BD restantes todavía se están procesando.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mac80211: corrige el punto muerto en el manejo de AP/VLAN. Syzbot informa que cuando tienes interfaces AP_VLAN activas y cierras la interfaz AP a la que pertenecen, obtenemos un punto muerto. No es de extrañar, ya que los dev_close() los usamos con el mutex wiphy retenido, lo que regresa al notificador netdev en cfg80211 e intenta adquirir el mutex wiphy allí. Para solucionar esto, debemos hacer dos cosas: 1) evitar cambiar iftype mientras las AP_VLAN estén activas, no podemos solucionar fácilmente este caso ya que cfg80211 ya nos llama con el mutex wiphy retenido, pero change_interface() es relativamente raro en los controladores de todos modos , por lo que cambiar iftype no se usa mucho (y el espacio de usuario tiene que volver a bajar/cambiar/arriba de todos modos) 2) extraiga el bucle dev_close() sobre las VLAN de la sección wiphy mutex en el caso de detención normal

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: Invalida el estado de la FPU después de un XRSTOR fallido desde un búfer de usuario. Tanto Intel como AMD consideran que es arquitectónicamente válido que XRSTOR falle con #PF pero aun así cambie el estado del registro. . Las condiciones reales bajo las cuales esto podría ocurrir no están claras [1], pero parece plausible que esto pueda desencadenarse si un hilo hermano desasigna una página e invalida el TLB compartido mientras otro hilo hermano está ejecutando XRSTOR en la página en cuestión. __fpu__restore_sig() puede ejecutar XRSTOR mientras los registros de hardware se conservan en nombre de una tarea de víctima diferente (usando el mecanismo fpu_fpregs_owner_ctx) y, en teoría, XRSTOR podría fallar pero modificar los registros. Si esto sucede, entonces hay una ventana en la que __fpu__restore_sig() podría programar la salida y la tarea de la víctima podría volver a programarse sin recargar sus propios registros FPU. Esto resultaría en parte del estado de la FPU en el que __fpu__restore_sig() intentaba cargar una filtración en el estado visible para el usuario de la tarea de la víctima. Invalide los registros FPU preservados en caso de falla de XRSTOR para evitar que esta situación corrompa cualquier estado. [1] Los lectores frecuentes de las listas de erratas podrían imaginar "condiciones microarquitectónicas complejas".

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/fpu: evita la corrupción del estado en __fpu__restore_sig() La ruta lenta no compactada usa __copy_from_user() y copia todo el búfer del usuario en el búfer del kernel, palabra por palabra. Esto significa que el búfer del kernel ahora puede contener un estado completamente inválido en el que XRSTOR realizará #GP. validar_user_xstate_header() puede detectar parte de esa corrupción, pero eso deja a las personas que llaman la responsabilidad de borrar el búfer. Antes de la compatibilidad con XSAVES, era posible simplemente reinicializar el búfer por completo, pero con los estados del supervisor eso ya no es posible porque la división del código de borrado del búfer lo hacía al revés. Arreglar eso es posible, pero no corromper al Estado en primer lugar es más sólido. Evite la corrupción del búfer XSAVE del kernel utilizando copy_user_to_xstate() que valida el contenido del encabezado XSAVE antes de copiar los estados reales al kernel. copy_user_to_xstate() anteriormente solo se llamaba para buffers del kernel en formato compacto, pero funciona tanto para formatos compactos como no compactos. Usarlo para el formato no compacto es más lento debido a múltiples operaciones __copy_from_user(), pero ese costo es menos importante que el código robusto en una ruta que ya es lenta. [Registro de cambios pulido por Dave Hansen]

Umbraco CMS es un CMS ASP.NET utilizado por más de 730.000 sitios web. El Cross Site Scripting (XSS) Almacenado permite a los atacantes que tienen acceso al backoffice introducir contenido malicioso en un sitio web o aplicación. Esta vulnerabilidad se ha solucionado en las versiones 8.18.13, 10.8.4, 12.3.7, 13.1.1 mediante la implementación de IHtmlSanitizer.

Un problema en Cesanta mjs 2.20.0 permite a un atacante remoto provocar una denegación de servicio a través de la función mjs_array_length en el archivo mjs.c.

Un problema en Cesanta mjs 2.20.0 permite a un atacante remoto provocar una denegación de servicio a través de la función mjs_mk_ffi_sig en el archivo mjs.c.

Un problema en Cesanta mjs 2.20.0 permite que un atacante remoto provoque una denegación de servicio a través de la función mjs_do_gc en el archivo mjs.c.

El complemento ElementsKit Pro para WordPress es vulnerable a Cross Site Scripting Almacenado a través del parámetro 'url' en versiones hasta la 3.6.1 incluida debido a una sanitización de entrada y un escape de salida insuficientes. Esto hace posible que atacantes autenticados, con permisos de nivel de colaborador y superiores, inyecten scripts web arbitrarios en páginas que se ejecutarán cada vez que un usuario acceda a una página inyectada.

La vulnerabilidad de desbordamiento del búfer basado en pila en dispositivos OEM basados en ZkTeco permite, en algunos casos, la ejecución de código arbitrario. Debido a la falta de mecanismos de protección como stack canaries y PIE, es posible ejecutar código con éxito incluso en condiciones restrictivas. Este problema afecta a dispositivos OEM basados en ZkTeco (ZkTeco ProFace X, Smartec ST-FR043, Smartec ST-FR041ME y posiblemente otros) con firmware ZAM170-NF-1.8.25-7354-Ver1.0.0 y posiblemente otros.