Vulnerabilidades

Se encontró una vulnerabilidad en 389 Directory Servidor. Una confusión de tipos en el gestor de operación extendida de token SSO causa que se divulgue información parcial de la dirección de la pila en las respuestas LDAP a usuarios autenticados.

Se encontró una vulnerabilidad en 389 Directory Server. El analizador LDIF lee más allá del final de un búfer de pila al procesar tipos de atributos con puntos y coma finales durante la importación de la base de datos, causando una lectura fuera de límites detectable mediante instrumentación de memoria.

Se encontró un fallo en 389 Directory Server. La función ldap_utf8prev() lee bytes antes del inicio de un búfer sin comprobación de límites, causando una sobrelectura del búfer de pila en el análisis de filtros de cadena que puede influir en el comportamiento interno de procesamiento de filtros.

Se encontró una falla en 389 Directory Server. El plugin de control de desreferencia no verifica si hay fallas en la asignación antes de usar una estructura BER, lo que permite a un atacante remoto no autenticado bloquear el servidor LDAP cuando el sistema está bajo presión de memoria.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: gro: no fusionar skbs zcopy<br /> <br /> skb_gro_receive() actualmente puede copiar fragmentos entre el skb de origen y el GRO, sin verificar el estado de zerocopy, y en particular el indicador SKBFL_MANAGED_FRAG_REFS.<br /> <br /> Cuando SKBFL_MANAGED_FRAG_REFS está establecido, el skb no mantiene una referencia en las páginas en shinfo-&gt;frags. Adjuntar esos fragmentos a los fragmentos de otro skb sin corregir el recuento de referencias de la página puede llevar a UAF.<br /> <br /> Cuando el último skb en la cadena GRO (aquel al que adjuntaríamos fragmentos) o el skb de origen es zerocopy, no fusionar los skbs.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> KVM: arm64: Reasignar el array nested_mmus detrás de mmu_lock<br /> <br /> kvm-&gt;arch.nested_mmus[] es recorrido bajo kvm-&gt;mmu_lock, incluyendo desde la ruta del notificador de MMU (kvm_unmap_gfn_range() -&gt; kvm_nested_s2_unmap()), que puede ejecutarse en cualquier momento. kvm_vcpu_init_nested() reasigna el array y libera el búfer antiguo mientras mantiene solo kvm-&gt;arch.config_lock, por lo que dicho recorredor puede referenciar el array liberado.<br /> <br /> Asignar el nuevo array fuera de mmu_lock, ya que la asignación puede dormir. Bajo el bloqueo, copiar las entradas existentes, corregir los punteros inversos y reasignar el array. Liberar el búfer antiguo después de soltar el bloqueo, ya que kvfree() también puede dormir.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> Revertir &amp;#39;mm/hugetlbfs: update hugetlbfs to use mmap_prepare&amp;#39;<br /> <br /> Esto revierte el commit ea52cb24cd3f (&amp;#39;mm/hugetlbfs: update hugetlbfs to use mmap_prepare&amp;#39;) con resolución de conflictos para tener en cuenta los cambios en el commit ea52cb24cd3f (&amp;#39;mm/hugetlbfs: update hugetlbfs to use mmap_prepare&amp;#39;).<br /> <br /> El parche manejó incorrectamente la asignación del bloqueo VMA de hugetlb en la etapa mmap_prepare, donde una asignación fallida que ocurre después de que se llama a mmap_prepare podría resultar en la fuga del bloqueo.<br /> <br /> No hay riesgo de que una fusión cause problemas similares, ya que VMA_DONTEXPAND_BIT está configurado para las asignaciones de hugetlb.<br /> <br /> Como primer paso para abordar este problema, simplemente revertimos el cambio para que podamos reelaborar cómo hacemos esto habiendo corregido los problemas subyacentes.<br /> <br /> Mantenemos los cambios de las banderas VMA lo mejor que podemos, teniendo en cuenta el hecho de que estábamos trabajando con un descriptor VMA anteriormente y propagando cambios equivalentes para esto.<br /> <br /> Tenga en cuenta que invocamos vma_set_flags() y no llamamos a vma_start_write() como lo hace vm_flags_set(). Esto está bien ya que se está haciendo en un gancho .mmap donde el VMA aún no está vinculado al árbol, por lo que nadie más puede acceder a él.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: act_ct: Solo liberar el bloqueo de lectura RCU después de ct_ft<br /> <br /> Al buscar una tabla de flujo en act_ct en tcf_ct_flow_table_get(), rhashtable_lookup_fast() abre y cierra internamente una sección crítica de lectura RCU antes de devolver ct_ft.<br /> La tcf_ct_flow_table_cleanup_work() puede completarse antes de que se invoque refcount_inc_not_zero() sobre el ct_ft devuelto, lo que resulta en un UAF en el objeto ct_ft ya liberado. Esta vulnerabilidad puede conducir a la escalada de privilegios.<br /> <br /> Análisis de zdi-disclosures@trendmicro.com:<br /> Al inicializar act_ct, se llama a tcf_ct_init(), lo que internamente dispara tcf_ct_flow_table_get().<br /> <br /> static int tcf_ct_flow_table_get(struct net net, struct tcf_ct_params params)<br /> <br /> {<br /> struct zones_ht_key key = { .net = net, .zone = params-&gt;zone };<br /> struct tcf_ct_flow_table ct_ft;<br /> int err = -ENOMEM;<br /> <br /> mutex_lock(&amp;zones_mutex);<br /> ct_ft = rhashtable_lookup_fast(&amp;zones_ht, &amp;key, zones_params); // [1]<br /> if (ct_ft &amp;&amp; refcount_inc_not_zero(&amp;ct_ft-&gt;ref)) // [2]<br /> goto out_unlock;<br /> ...<br /> }<br /> <br /> static __always_inline void rhashtable_lookup_fast(<br /> struct rhashtable ht, const void key,<br /> const struct rhashtable_params params)<br /> {<br /> void obj;<br /> <br /> rcu_read_lock();<br /> obj = rhashtable_lookup(ht, key, params);<br /> rcu_read_unlock();<br /> <br /> return obj;<br /> }<br /> <br /> En [1], rhashtable_lookup_fast() busca y devuelve el ct_ft correspondiente de zones_ht. La búsqueda se realiza dentro de una sección crítica de lectura RCU a través de rcu_read_lock() / rcu_read_unlock(), lo que evita que el objeto sea liberado. Sin embargo, en el punto de retorno de la función, rcu_read_unlock() ya ha sido llamado, y no hay nada que impida que ct_ft sea liberado antes de alcanzar refcount_inc_not_zero(&amp;ct_ft-&gt;ref) en [2]. Este intervalo se convierte en la ventana de carrera, durante la cual ct_ft puede ser liberado.<br /> <br /> Proceso de Liberación:<br /> <br /> tcf_ct_flow_table_put() se ejecuta a través de la ruta tcf_ct_cleanup() call_rcu() tcf_ct_params_free_rcu() tcf_ct_params_free() tcf_ct_flow_table_put().<br /> <br /> static void tcf_ct_flow_table_put(struct tcf_ct_flow_table ct_ft)<br /> {<br /> if (refcount_dec_and_test(&amp;ct_ft-&gt;ref)) {<br /> rhashtable_remove_fast(&amp;zones_ht, &amp;ct_ft-&gt;node, zones_params);<br /> INIT_RCU_WORK(&amp;ct_ft-&gt;rwork, tcf_ct_flow_table_cleanup_work); // [3]<br /> queue_rcu_work(act_ct_wq, &amp;ct_ft-&gt;rwork);<br /> }<br /> }<br /> <br /> En [3], tcf_ct_flow_table_cleanup_work() se programa como trabajo RCU<br /> <br /> static void tcf_ct_flow_table_cleanup_work(struct work_struct work)<br /> <br /> {<br /> struct tcf_ct_flow_table ct_ft;<br /> struct flow_block block;<br /> <br /> ct_ft = container_of(to_rcu_work(work), struct tcf_ct_flow_table,<br /> rwork);<br /> nf_flow_table_free(&amp;ct_ft-&gt;nf_ft);<br /> block = &amp;ct_ft-&gt;nf_ft.flow_block;<br /> down_write(&amp;ct_ft-&gt;nf_ft.flow_block_lock);<br /> WARN_ON(!list_empty(&amp;block-&gt;cb_list));<br /> up_write(&amp;ct_ft-&gt;nf_ft.flow_block_lock);<br /> kfree(ct_ft); // [4]<br /> <br /> module_put(THIS_MODULE);<br /> }<br /> <br /> tcf_ct_flow_table_cleanup_work() libera ct_ft en [4]. Cuando esta función se ejecuta entre [1] y [2], ocurre un UAF.<br /> <br /> Esta condición de carrera tiene una ventana de carrera muy corta, lo que la hace generalmente difícil de activar. Por lo tanto, para activar la vulnerabilidad se insertó un msleep(100) después de [1].

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> tap: liberar página en las rutas de error en tap_get_user_xdp()<br /> <br /> tap_get_user_xdp() rechaza una trama más corta que ETH_HLEN con -EINVAL, y devuelve -ENOMEM cuando build_skb() falla. Ambas rutas saltan a la etiqueta err sin liberar la página que vhost_net_build_xdp() asignó para la trama. tap_sendmsg() descarta el valor de retorno por búfer y siempre devuelve 0, por lo que vhost_tx_batch() toma la ruta de éxito y nunca libera la página; cada trama rechazada en un lote filtra un fragmento de página.<br /> <br /> Liberar la página en ambas rutas de error, antes de que se construya el skb. Esta es la contraparte de tap de la misma fuga en tun_xdp_one().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> tun: liberar página en el rechazo de tramas cortas en tun_xdp_one()<br /> <br /> tun_xdp_one() devuelve -EINVAL en una trama más corta que ETH_HLEN sin liberar la página que vhost_net_build_xdp() asignó para ella. tun_sendmsg() descarta ese -EINVAL y aún devuelve total_len, por lo que vhost_tx_batch() toma la ruta de éxito y nunca libera la página; cada trama corta en un lote filtra un chunk de fragmento de página.<br /> <br /> Un proceso local que puede abrir /dev/net/tun y /dev/vhost-net puede alcanzar esta ruta: adjunta un dispositivo tun/tap como el backend de vhost-net y alimenta descriptores TX cuya longitud menos el encabezado virtio-net está por debajo de ETH_HLEN. Cada kick filtra los chunks de fragmentos de página para ese lote, y un bucle de envío ajustado agota la memoria del host y desencadena un pánico OOM. Liberar la página antes de devolver -EINVAL, coincidiendo con la ruta de error del programa XDP en la misma función.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> tun: liberar página en caso de fallo de build_skb() en tun_xdp_one()<br /> <br /> Cuando build_skb() falla en tun_xdp_one(), la función establece ret en -ENOMEM y salta a la etiqueta out, la cual retorna sin liberar la página que vhost_net_build_xdp() asignó para el frame. Al igual que con la ruta de rechazo de frames cortos, tun_sendmsg() descarta el error por búfer y aún retorna total_len, por lo que vhost_tx_batch() toma la ruta de éxito y nunca libera la página. Cada fallo de build_skb() en un lote fuga un fragmento de página.<br /> <br /> Liberar la página antes de tomar la ruta de error, coincidiendo con el put_page() que las otras salidas de error de tun_xdp_one() ya realizan.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netfilter: nf_tables: usar list_del_rcu para los hooks de netlink<br /> <br /> nft_netdev_unregister_hooks y __nft_unregister_flowtable_net_hooks necesitan usar list_del_rcu(), esta lista puede ser recorrida por volcadores concurrentes.<br /> <br /> Añadir una nueva función auxiliar y usarla de forma consistente.