Vulnerabilidades

Se encontró una vulnerabilidad de sobrelectura del búfer basado en montón en la función ProcXIGetSelectedEvents() del servidor X.org. Este problema se produce cuando se utilizan valores de longitud de bytes intercambiados en las respuestas, lo que puede provocar pérdidas de memoria y errores de segmentación, especialmente cuando lo activa un cliente con una endianidad diferente. Un atacante podría aprovechar esta vulnerabilidad para hacer que el servidor X lea los valores de la memoria dinámica y luego los transmita de vuelta al cliente hasta encontrar una página no asignada, lo que provocaría un bloqueo. A pesar de la incapacidad del atacante para controlar la memoria específica copiada en las respuestas, los pequeños valores de longitud que normalmente se almacenan en un entero de 32 bits pueden dar como resultado importantes intentos de lecturas fuera de los límites.

Se encontró una vulnerabilidad de sobrelectura del búfer de almacenamiento dinámico en la función ProcXIPassiveGrabDevice() del servidor X.org. Este problema se produce cuando se utilizan valores de longitud de bytes intercambiados en las respuestas, lo que puede provocar pérdidas de memoria y errores de segmentación, especialmente cuando lo activa un cliente con una endianidad diferente. Un atacante podría aprovechar esta vulnerabilidad para hacer que el servidor X lea los valores de la memoria dinámica y luego los transmita de vuelta al cliente hasta encontrar una página no asignada, lo que provocaría un bloqueo. A pesar de la incapacidad del atacante para controlar la memoria específica copiada en las respuestas, los pequeños valores de longitud que normalmente se almacenan en un entero de 32 bits pueden dar como resultado importantes intentos de lecturas fuera de los límites.

Se encontró una vulnerabilidad de sobrelectura del búfer de almacenamiento dinámico en la función ProcAppleDRICreatePixmap() del servidor X.org. Este problema se produce cuando se utilizan valores de longitud de bytes intercambiados en las respuestas, lo que puede provocar pérdidas de memoria y errores de segmentación, especialmente cuando lo activa un cliente con una endianidad diferente. Un atacante podría aprovechar esta vulnerabilidad para hacer que el servidor X lea los valores de la memoria dinámica y luego los transmita de vuelta al cliente hasta encontrar una página no asignada, lo que provocaría un bloqueo. A pesar de la incapacidad del atacante para controlar la memoria específica copiada en las respuestas, los pequeños valores de longitud que normalmente se almacenan en un entero de 32 bits pueden dar como resultado importantes intentos de lecturas fuera de los límites.

Se encontró una vulnerabilidad en el componente quarkus-core. Quarkus captura las variables de entorno local del espacio de nombres de Quarkus durante la compilación de la aplicación. Por lo tanto, la ejecución de la aplicación resultante hereda los valores capturados en el momento de la compilación. Sin embargo, es posible que el entorno de desarrollador/CI haya configurado algunas variables de entorno local con fines de prueba, como eliminar la base de datos durante el inicio de la aplicación o confiar en que todos los certificados TLS acepten certificados autofirmados. Si estas propiedades se configuran mediante variables de entorno o la función .env, se capturan en la aplicación integrada. Conduce a un comportamiento peligroso si la aplicación no anula estos valores. Este comportamiento solo ocurre para las propiedades de configuración del espacio de nombres `quarkus.*`. Por lo tanto, las propiedades específicas de la aplicación no se capturan.

Vulnerabilidad de Directory Traversal en INOTEC Sicherheitstechnik GmbH INOTEC Sicherheitstechnik GmbH WebServer CPS220/64 V.3.3.19 permite a un atacante remoto ejecutar código arbitrario a través del archivo /etc/passwd.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_set_pipapo: libera elementos en el clon solo desde la ruta de destrucción. El clon ya siempre proporciona una vista actual de la tabla de búsqueda, úsala para destruir el conjunto; de lo contrario, es posible destruir elementos. dos veces. Esta solución requiere: 212ed75dc5fb ("netfilter: nf_tables: integrar pipapo en el protocolo de confirmación") que vino después: 9827a0e6e23b ("netfilter: nft_set_pipapo: liberar elementos en clon desde la ruta de cancelación").

Vulnerabilidad de exposición de información en el software RT que afecta a la versión 4.4.1. Esta vulnerabilidad permite a un atacante con acceso local al dispositivo recuperar información confidencial sobre la aplicación, como tickets de vulnerabilidad, porque la aplicación almacena la información en la memoria caché del navegador, lo que lleva a la exposición de la información a pesar de la finalización de la sesión.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nft_chain_filter: maneja NETDEV_UNREGISTER para la cadena base inet/ingress Elimine netdevice de la cadena base inet/ingress en caso de que se informe el evento NETDEV_UNREGISTER; de lo contrario, permanecerá una referencia obsoleta a netdevice en la lista de enlaces.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: evite el posible use-after-free en hci_error_reset Mientras se maneja el evento HCI_EV_HARDWARE_ERROR, si el controlador BT subyacente no responde, el mecanismo de reinicio de GPIO liberaría hci_dev y provocaría un error. use-after-free en hci_error_reset. Este es el seguimiento de llamadas observado en un dispositivo ChromeOS con Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth ] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth ] hci_error_reset+0x4f/0xa4 [bluetooth ] Process_one_work+0x1d8/0x33f trabajador_thread+0x21b/0x373 kthread+0x13a /0x152 ? pr_cont_work+0x54/0x54? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30 Este parche mantiene el recuento de referencias en hci_dev mientras procesa un evento HCI_EV_HARDWARE_ERROR para evitar posibles fallas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: stmmac: Borrar variable al destruir la cola de trabajo Actualmente, al suspender el controlador y detener la cola de trabajo, se verifica si la cola de trabajo no es NULL y, de ser así, se destruye. La función destroy_workqueue() drena la cola y borra la variable, pero no establece la variable de la cola de trabajo en NULL. Esto puede causar pánico en el núcleo/módulo si el código intenta borrar la cola de trabajo que no se inicializó. Este escenario es posible al reanudar el controlador suspendido en stmmac_resume(), porque no hay control para stmmac_hw_setup() fallido, que puede fallar y regresar si el motor DMA no se pudo inicializar y la cola de trabajo se inicializa después del motor DMA. Si el motor DMA no se inicializa, la reanudación se realizará normalmente, pero la interfaz no funcionará y la cola de TX eventualmente expirará, lo que provocará el error "Restablecer adaptador". Esto luego destruye la cola de trabajo durante el proceso de reinicio. Y dado que la cola de trabajo se inicializa después del motor DMA y se puede omitir, provocará pánico en el núcleo/módulo. Para protegerse contra este posible bloqueo, establezca la variable workqueue en NULL al destruir workqueue. El registro/rastreo del fallo es el siguiente: [88.031977]------------[ cortar aquí ]------------ [88.031985]NETDEV WATCHDOG: eth0 (sxgmac) : Se agotó el tiempo de espera de la cola de transmisión 1 [88.032017] ADVERTENCIA: CPU: 0 PID: 0 en net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398 [88.032251]---[fin de rastreo e70de432e4d5c2c0] --- [88.032282]sxgmac 16d88000.ethernet eth0: Restablecer el adaptador. [88.036359]------------[ cortar aquí ]------------ [88.036519]Rastreo de llamadas: [88.036523] Flush_workqueue+0x3e4/0x430 [88.036528] Drain_workqueue+ 0xc4/0x160 [88.036533] destroy_workqueue+0x40/0x270 [88.036537] stmmac_fpe_stop_wq+0x4c/0x70 [88.036541] stmmac_release+0x278/0x280 [88.036546] __dev_close_many+0xcc/0 x158 [88.036551] dev_close_many+0xbc/0x190 [88.036555] dev_close.part. 0+0x70/0xc0 [88.036560] dev_close+0x24/0x30 [88.036564] stmmac_service_task+0x110/0x140 [88.036569] Process_one_work+0x1d8/0x4a0 [88.036573] trabajador_thread+0x54/0x408 [8 8.036578] kthread+0x164/0x170 [88.036583] ret_from_fork+ 0x10/0x20 [88.036588]---[fin de seguimiento e70de432e4d5c2c1]--- [88.036597]No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000004

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: veth: borra GRO al borrar XDP incluso cuando está desactivado veth configura NETIF_F_GRO automáticamente cuando XDP está habilitado, porque ambas funciones utilizan la misma maquinaria NAPI. La lógica para borrar NETIF_F_GRO se encuentra en veth_disable_xdp(), que se llama tanto en ndo_stop como cuando XDP está desactivado. Para evitar que la bandera se borre cuando se baja el dispositivo, la eliminación se omite cuando IFF_UP no está configurado. De hecho, bajar el dispositivo no debería modificar sus características. Desafortunadamente, esto significa que la limpieza también se omite cuando XDP está deshabilitado _mientras_ el dispositivo está inactivo. Y no hay nada en el camino abierto para volver a sincronizar las funciones del dispositivo. IOW, si el usuario habilita XDP, lo deshabilita y luego enciende el dispositivo, terminaremos con un indicador GRO perdido pero sin instancias NAPI. No dependemos del indicador GRO en la ruta de datos, por lo que la ruta de datos no fallará. Nos bloquearemos (o colgaremos), sin embargo, la próxima vez que se sincronicen las funciones (ya sea por el usuario a través de ethtool o por un compañero cambiando su configuración). La bandera GRO desaparecerá y Veth intentará desactivar las NAPI. Pero el camino abierto nunca los creó ya que XDP estaba desactivado, la bandera GRO estaba perdida. Si NAPI se inicializó antes, colgaremos napi_disable(). Si nunca fue así, fallaremos al intentar detener el hrtimer no inicializado. Mueva las actualizaciones del indicador GRO a las rutas de activación/desactivación de XDP, en lugar de mezclarlas con las rutas ndo_open/ndo_close.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ip_tunnel: evita el crecimiento perpetuo del espacio libre syzkaller activado después de kasan splat: ERROR: KASAN: use-after-free en __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Lectura del tamaño 1 en la dirección ffff88812fb4000e mediante la tarea syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_key incluir/linux /skbuff.h:1514 [en línea] ___skb_get_hash net/core/flow_dissector.c:1791 [en línea] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [en línea] ip_tunnel_xmit +0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [en línea] netdev_start_xmit include/linux/netdevice.h:4954 [en línea] xmit_one net/core/dev.c:3548 [en línea] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice .h:3134 [en línea] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c :323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit incluir /linux /netdevice.h:4940 [en línea] netdev_start_xmit include/linux/netdevice.h:4954 [en línea] xmit_one net/core/dev.c:3548 [en línea] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 . .. El símbolo se produce porque skb->data apunta más allá del área asignada de skb->head. Esto se debe a que la capa vecina hace: __skb_pull(skb, skb_network_offset(skb)); ... pero skb_network_offset() devuelve un desplazamiento negativo y el argumento __skb_pull() no está firmado. OIA, nosotros, skb->los datos, se "ajustan" en un valor enorme. El valor negativo se devuelve porque la distancia de skb->head y skb->data es superior a 64k y skb->network_header (u16) se ha ajustado. El error está en la infraestructura ip_tunnel, lo que puede hacer que dev->needed_headroom se incremente hasta el infinito. El reproductor syzkaller consta de paquetes que se enrutan a través de un túnel gre y una ruta de paquetes encapsulados gre que apuntan a otro túnel (ipip). La encapsulación ipip encuentra gre0 como el siguiente dispositivo de salida. Esto da como resultado el siguiente patrón: 1). El primer paquete se enviará a través de gre0. La búsqueda de ruta encontró un dispositivo de salida, ipip0. 2). ip_tunnel_xmit para gre0 aumenta gre0->needed_headroom según el dispositivo de salida futuro, rt.dev->needed_headroom (ipip0). 3). ipoutput/start_xmit mueve skb a ipip0. que ejecuta la misma ruta de código nuevamente (xmit recursividad). 4). El paso de enrutamiento para el paquete post-gre0-encap encuentra gre0 como dispositivo de salida para usar con el paquete encapsulado ipip0. tunl0->needed_headroom luego se incrementa según el espacio libre del dispositivo gre0 (ya aumentado). Esto se repite para cada paquete futuro: gre0->needed_headroom se infla porque el paso ipip0 de los paquetes anteriores incrementó el espacio libre rt->dev (gre0), y ipip0 se incrementó porque se aumentó el espacio necesario_headroom de gre0. Para cada paquete posterior, gre/ipip0->needed_headroom crece hasta que las reasignaciones posteriores a la expansión del cabezal dan como resultado una distancia skb->head/data de más de 64k. Una vez que eso sucede, skb->network_header (u16) se ajusta cuando pskb_expand_head intenta asegurarse de que skb_network_offset() no cambie después de la expansión/reasignación del espacio libre. Después de esto, skb_network_offset(skb) devuelve un resultado diferente (y negativo) posterior a la expansión del espacio libre.---trucado---