Vulnerabilidades

Vulnerabilidad de inyección SQL en TeamCal Neo, versión 3.8.2. Esto podría permitir a un atacante recuperar, actualizar y eliminar toda la información de la base de datos inyectando una sentencia SQL maliciosa a través del parámetro ‘abs’ en ‘/teamcal/src/index.php’.

Cross-Site Scripting (XSS) Reflejado en TeamCal Neo, versión 3.8.2. Esto permite que un atacante ejecute código JavaScript malicioso, después de inyectar código a través del parámetro ‘abs’ en ‘/teamcal/src/index.php’.

Escalada de privilegios locales debido a una vulnerabilidad de secuestro de DLL. Los siguientes productos están afectados: Acronis Cyber ??Protect Cloud Agent (Windows) antes de la compilación 39378.

Escalada de privilegios locales debido a una vulnerabilidad de ruta de búsqueda sin comillas. Los siguientes productos están afectados: Acronis Cyber ??Protect Cloud Agent (Windows) antes de la compilación 39378.

Escalada de privilegios locales debido a una vulnerabilidad de secuestro de DLL. Los siguientes productos están afectados: Acronis Cyber ??Protect Cloud Agent (Windows) antes de la compilación 39378.

Escalada de privilegios locales debido a una vulnerabilidad de secuestro de DLL. Los siguientes productos están afectados: Acronis Cyber ??Protect Cloud Agent (Windows) antes de la compilación 39378.

Escalada de privilegios locales debido a una vulnerabilidad de secuestro de DLL. Los siguientes productos están afectados: Acronis Cyber ??Protect Cloud Agent (Windows) antes de la compilación 39378.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: agregar la gestión de errores faltante dentro de get_canonical_dev_path Dentro de la función get_canonical_dev_path(), llamamos a d_path() para obtener la ruta final del dispositivo. Pero d_path() puede devolver un error y, en ese caso, la siguiente llamada a strscpy() activará un acceso a memoria no válido. Agregue nuevamente la gestión de errores faltante para d_path().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pktgen: Evitar acceso fuera de los límites en get_imix_entries Pasar una cantidad suficiente de entradas imix conduce a un acceso no válido a la matriz pkt_dev->imix_entries debido a la verificación de los límites incorrecta. UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24 index 20 is out of range for type 'imix_pkt [20]' CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: dump_stack_lvl lib/dump_stack.c:117 __ubsan_handle_out_of_bounds lib/ubsan.c:429 get_imix_entries net/core/pktgen.c:874 pktgen_if_write net/core/pktgen.c:1063 pde_write fs/proc/inode.c:334 proc_reg_write fs/proc/inode.c:346 vfs_write fs/read_write.c:593 ksys_write fs/read_write.c:644 do_syscall_64 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:130 Found by Linux Verification Center (linuxtesting.org) with SVACE. [ fp: allow to fill the array completely; minor changelog cleanup ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: openvswitch: fix lockup on tx to unregistering netdev with carrier Commit en una etiqueta fixes intentó solucionar el problema en la siguiente secuencia de llamadas: do_output -> ovs_vport_send -> dev_queue_xmit -> __dev_queue_xmit -> netdev_core_pick_tx -> skb_tx_hash Cuando el dispositivo está anulando el registro, 'dev->real_num_tx_queues' va a cero y el bucle 'while (unlikely(hash >= qcount))' dentro de 'skb_tx_hash' se vuelve infinito, bloqueando el núcleo para siempre. Pero desafortunadamente, verificar solo el estado del operador no es suficiente para solucionar el problema, porque algunos dispositivos aún pueden estar en estado de anulación de registro mientras informan que el estado del operador es correcto. Un ejemplo de dicho dispositivo es un net/dummy. Activa el operador al iniciar, pero no implementa .ndo_stop para desactivarlo. Y tiene sentido, porque dummy en realidad no tiene un operador. Por lo tanto, mientras este dispositivo se está anulando el registro, sigue siendo fácil alcanzar el bucle infinito en skb_tx_hash() desde la ruta de datos de OVS. Puede haber otros controladores que hagan lo mismo, pero dummy por sí solo es importante para el ecosistema OVS, porque se usa con frecuencia como un receptor de paquetes para tcpdump mientras se depuran las implementaciones de OVS. Y cuando se produce el problema, la única forma de recuperarse es reiniciar. Solucione eso comprobando también si el dispositivo está en ejecución. El estado de ejecución controla el núcleo de red durante la anulación del registro, por lo que cubre mejor el caso de anulación del registro y realmente no necesitamos enviar paquetes a dispositivos que no se están ejecutando de todos modos. Si bien solo comprobar el estado de ejecución puede ser suficiente, la comprobación del operador se conserva. Los estados de ejecución y del operador parecen estar separados en todo el código y en los diferentes controladores. Y otras funciones básicas como __dev_direct_xmit() comprueban ambos antes de intentar transmitir un paquete. Por lo tanto, parece más seguro comprobar también ambos indicadores en OVS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se solucionó la pérdida de memoria de bpf_sk_select_reuseport() Como se señaló en el comentario original, la búsqueda en sockmap puede devolver un socket TCP ESTABLISHED. Es posible que dicho socket TCP haya tenido SO_ATTACH_REUSEPORT_EBPF configurado antes de que se estableciera. En otras palabras, un sk_reuseport_cb que no sea NULL no implica un socket sin referencia. Elimine la referencia de sk en ambas rutas de error. objeto sin referencia 0xffff888101911800 (tamaño 2048): comm "test_progs", pid 44109, jiffies 4297131437 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ seguimiento inverso (crc 9336483b): __kmalloc_noprof+0x3bf/0x560 __reuseport_alloc+0x1d/0x40 reuseport_alloc+0xca/0x150 reuseport_attach_prog+0x87/0x140 sk_reuseport_attach_bpf+0xc8/0x100 sk_setsockopt+0x1181/0x1990 do_sock_setsockopt+0x12b/0x160 __sys_setsockopt+0x7b/0xc0 __x64_sys_setsockopt+0x1b/0x30 do_syscall_64+0x93/0x180 entrada_SYSCALL_64_después_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: bnxt: siempre recalcula las características después de borrar XDP, corrige null-deref Recalcula las características cuando se desconecta XDP. Antes: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: off [solicitado el] Después: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: on El hecho de que HW-GRO no se vuelva a habilitar automáticamente es solo una molestia menor. El problema real es que las funciones volverán de forma aleatoria durante otra reconfiguración que invoca netdev_update_features(). El controlador no gestiona la reconfiguración de dos cosas a la vez de forma muy robusta. A partir de el commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in __bnxt_reserve_rings()"), solo reconfiguramos la tabla hash RSS si el número "efectivo" de anillos Rx ha cambiado. Si HW-GRO está habilitado, el número "efectivo" de anillos es el doble de lo que ve el usuario. Entonces, si estamos en un mal estado, con la rehabilitación de HW-GRO "pendiente" después de desactivar XDP, y reducimos los anillos en / 2, los anillos de HW-GRO haciendo 2x y ethtool -L haciendo / 2 pueden cancelarse entre sí, y la condición: if (old_rx_rings != bp->hw_resc.resv_rx_rings && en __bnxt_reserve_rings() será falsa. El mapa RSS no se actualizará y nos bloquearemos con: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000168 RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0 bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180 __bnxt_setup_vnic_p5+0x58/0x110 bnxt_init_nic+0xb72/0xf50 __bnxt_open_nic+0x40d/0xab0 bnxt_open_nic+0x2b/0x60 ethtool_set_channels+0x18c/0x1d0 Cuando intentamos acceder a un anillo liberado, el problema está presente desde que se agregó la compatibilidad con XDP, pero antes de el commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in __bnxt_reserve_rings()") no causaba problemas importantes.