Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: stmmac: solucionar el problema de bloqueo para la acción XDP_TX de copia cero<br /> <br /> Existe un problema de bloqueo al ejecutar la acción XDP_TX de copia cero; el registro de bloqueo se muestra a continuación.<br /> <br /> [ 216.122464] No se puede manejar la solicitud de paginación del kernel en la dirección virtual fffeffff80000000<br /> [ 216.187524] Error interno: Oops: 0000000096000144 [#1] SMP<br /> [ 216.301694] Traza de llamadas:<br /> [ 216.304130] dcache_clean_poc+0x20/0x38 (P)<br /> [ 216.308308] __dma_sync_single_for_device+0x1bc/0x1e0<br /> [ 216.313351] stmmac_xdp_xmit_xdpf+0x354/0x400<br /> [ 216.317701] __stmmac_xdp_run_prog+0x164/0x368<br /> [ 216.322139] stmmac_napi_poll_rxtx+0xba8/0xf00<br /> [ 216.326576] __napi_poll+0x40/0x218<br /> [ 216.408054] Pánico del kernel - no sincronizando: Oops: Excepción fatal en interrupción<br /> <br /> Para la acción XDP_TX, el xdp_buff se convierte a xdp_frame mediante xdp_convert_buff_to_frame(). El tipo de memoria del xdp_frame resultante depende del tipo de memoria del xdp_buff. Para xdp_buff basado en pool de páginas, produce xdp_frame con tipo de memoria MEM_TYPE_PAGE_POOL. Para xdp_buff basado en pool XSK de copia cero, produce xdp_frame con tipo de memoria MEM_TYPE_PAGE_ORDER0. Sin embargo, stmmac_xdp_xmit_back() no verifica el tipo de memoria y siempre usa el tipo de pool de páginas, lo que lleva a mapeos inválidos y causa el bloqueo. Por lo tanto, verifique el tipo de memoria del xdp_buff en stmmac_xdp_xmit_back() para solucionar este problema.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> RDMA/core: Comprobar la presencia de LS_NLA_TYPE_DGID correctamente<br /> <br /> La respuesta netlink para RDMA_NL_LS_OP_IP_RESOLVE siempre debe tener un atributo LS_NLA_TYPE_DGID; es inválida si no lo tiene.<br /> <br /> Usar la lógica de análisis nl correctamente y llamar a nla_parse_deprecated() para rellenar el array nlattrs y luego indexar directamente ese array para obtener los datos para el DGID. Simplemente fallar si es NULL.<br /> <br /> Eliminar el bucle for que busca el nla, y fusionar la validación y el análisis en una sola función.<br /> <br /> Corrige una lectura no inicializada de la pila activada por el espacio de usuario si no proporciona el DGID a una consulta RDMA_NL_LS_OP_IP_RESOLVE iniciada por el kernel.<br /> <br /> BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline]<br /> BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490<br /> hex_byte_pack include/linux/hex.h:13 [inline]<br /> ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490<br /> ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509<br /> ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633<br /> pointer+0xc09/0x1bd0 lib/vsprintf.c:2542<br /> vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930<br /> vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279<br /> vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426<br /> vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465<br /> vprintk+0x36/0x50 kernel/printk/printk_safe.c:82<br /> _printk+0x17e/0x1b0 kernel/printk/printk.c:2475<br /> ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline]<br /> ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141<br /> rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline]<br /> rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]<br /> rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]<br /> netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346<br /> netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> __sock_sendmsg+0x333/0x3d0 net/socket.c:729<br /> ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617<br /> ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671<br /> __sys_sendmsg+0x1aa/0x300 net/socket.c:2703<br /> __compat_sys_sendmsg net/compat.c:346 [inline]<br /> __do_compat_sys_sendmsg net/compat.c:353 [inline]<br /> __se_compat_sys_sendmsg net/compat.c:350 [inline]<br /> __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350<br /> ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371<br /> do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]<br /> __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306<br /> do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331<br /> do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ipv4: Corrección de fuga de contador de referencias al usar rutas de error con objetos nexthop<br /> <br /> Cuando un objeto nexthop es eliminado, es marcado como muerto y luego se llama a fib_table_flush() para vaciar todas las rutas que están usando el nexthop muerto.<br /> <br /> La lógica actual en fib_table_flush() es vaciar solo las rutas de error (p. ej., blackhole) cuando se llama como parte del desmantelamiento de un espacio de nombres de red (es decir, con flush_all=true). Por lo tanto, las rutas de error no se vacían cuando su objeto nexthop es eliminado:<br /> <br /> # ip link add name dummy1 up type dummy<br /> # ip nexthop add id 1 dev dummy1<br /> # ip route add 198.51.100.1/32 nhid 1<br /> # ip route add blackhole 198.51.100.2/32 nhid 1<br /> # ip nexthop del id 1<br /> # ip route show<br /> blackhole 198.51.100.2 nhid 1 dev dummy1<br /> <br /> Como tal, siguen manteniendo una referencia en el objeto nexthop que a su vez mantiene una referencia en el dispositivo nexthop, lo que resulta en una fuga de contador de referencias:<br /> <br /> # ip link del dev dummy1<br /> [ 70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2<br /> <br /> Corrección vaciando las rutas de error cuando su nexthop es marcado como muerto.<br /> <br /> IPv6 no sufre de este problema.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ip6_gre: hacer que ip6gre_header() sea robusto<br /> <br /> A lo largo de los años, syzbot encontró muchas maneras de colapsar el kernel en ip6gre_header() [1].<br /> <br /> Esto implica la capacidad de los controladores de equipo o de enlace (bonding) de cambiar dinámicamente su dev-&amp;gt;needed_headroom y/o dev-&amp;gt;hard_header_len<br /> <br /> En este colapso particular, mld_newpack() asignó un skb con una reserva/espacio de cabecera (headroom) demasiado pequeño, y para cuando se llamó a mld_sendpack(), syzbot logró adjuntar un dispositivo ip6gre.<br /> <br /> [1]<br /> skbuff: skb_under_panic: texto:ffffffff8a1d69a8 longitud:136 puesto:40 cabecera:ffff888059bc7000 datos:ffff888059bc6fe8 cola:0x70 fin:0x6c0 dispositivo:team0<br /> ------------[ cortar aquí ]------------<br /> BUG del kernel en net/core/skbuff.c:213 !<br /> <br /> skb_under_panic net/core/skbuff.c:223 [en línea]<br /> skb_push+0xc3/0xe0 net/core/skbuff.c:2641<br /> ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371<br /> dev_hard_header include/linux/netdevice.h:3436 [en línea]<br /> neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618<br /> neigh_output include/net/neighbour.h:556 [en línea]<br /> ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136<br /> __ip6_finish_output net/ipv6/ip6_output.c:-1 [en línea]<br /> ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220<br /> NF_HOOK_COND include/linux/netfilter.h:307 [en línea]<br /> ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247<br /> NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318<br /> mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855<br /> mld_send_cr net/ipv6/mcast.c:2154 [en línea]<br /> mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/xe/oa: Corrige un potencial uso después de liberación en xe_oa_add_config_ioctl()<br /> <br /> En xe_oa_add_config_ioctl(), accedimos a oa_config-&amp;gt;id después de liberar metrics_lock. Dado que este bloqueo protege la vida útil de oa_config, un atacante podría adivinar el id y llamar a xe_oa_remove_config_ioctl() con una sincronización perfecta, liberando oa_config antes de que lo desreferenciemos, lo que lleva a un potencial uso después de liberación.<br /> <br /> Esto se corrige al almacenar en caché el id en una variable local mientras se mantiene el bloqueo.<br /> <br /> v2: (Matt A)<br /> - Se eliminó el cambio de orden de mutex_unlock(&amp;amp;oa-&amp;gt;metrics_lock) de xe_oa_remove_config_ioctl()<br /> <br /> (cherry picked from commit 28aeaed130e8e587fd1b73b6d66ca41ccc5a1a31)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> wifi: rtlwifi: 8192cu: solución a tid fuera de rango en rtl92cu_tx_fill_desc()<br /> <br /> El TID obtenido de ieee80211_get_tid() podría estar fuera del rango del tamaño del array de sta_entry-&amp;gt;tids[], por lo tanto, se verifica que el TID sea menor que MAX_TID_COUNT. De lo contrario, UBSAN advierte:<br /> <br /> UBSAN: índice de array fuera de límites en drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30<br /> el índice 10 está fuera de rango para el tipo &amp;#39;rtl_tid_data [9]&amp;#39;

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iommu: deshabilitar SVA cuando CONFIG_X86 está configurado<br /> <br /> Serie de parches &amp;#39;Corrección de entradas IOTLB obsoletas para el espacio de direcciones del kernel&amp;#39;, v7.<br /> <br /> Esto propone una corrección para una vulnerabilidad de seguridad relacionada con el Direccionamiento Virtual Compartido (SVA) de IOMMU. En un contexto SVA, un IOMMU puede almacenar en caché entradas de la tabla de páginas del kernel. Cuando una página de la tabla de páginas del kernel es liberada y reasignada para otro propósito, el IOMMU aún podría contener entradas obsoletas e incorrectas. Esto puede ser explotado para causar una condición de uso después de liberación o de escritura después de liberación, lo que podría llevar a una escalada de privilegios o a la corrupción de datos.<br /> <br /> Esta solución introduce un mecanismo de liberación diferida para las páginas de la tabla de páginas del kernel, que proporciona una ventana segura para notificar al IOMMU que invalide sus cachés antes de que la página sea reutilizada.<br /> <br /> Este parche (de 8):<br /> <br /> En el contexto de Direccionamiento Virtual Compartido (SVA) de IOMMU, el hardware IOMMU comparte y recorre las tablas de páginas de la CPU. La arquitectura x86 mapea el espacio de direcciones virtual del kernel en la porción superior de la tabla de páginas de cada proceso. En consecuencia, en un contexto SVA, el hardware IOMMU puede recorrer y almacenar en caché entradas de la tabla de páginas del kernel.<br /> <br /> El kernel de Linux actualmente carece de un mecanismo de notificación para los cambios en la tabla de páginas del kernel, específicamente cuando las páginas de la tabla de páginas son liberadas y reutilizadas. El controlador IOMMU solo es notificado de los cambios en las asignaciones de direcciones virtuales de usuario. Esto puede hacer que las cachés internas del IOMMU retengan entradas obsoletas para VA del kernel.<br /> <br /> Las condiciones de Uso Después de Liberación (UAF) y Escritura Después de Liberación (WAF) surgen cuando las páginas de la tabla de páginas del kernel son liberadas y posteriormente reasignadas. El IOMMU podría malinterpretar los nuevos datos como entradas válidas de la tabla de páginas. El IOMMU podría entonces recorrer memoria controlada por el atacante, lo que llevaría a un acceso DMA arbitrario a la memoria física o a una escalada de privilegios. Esto también es un problema de Escritura Después de Liberación, ya que el IOMMU potencialmente continuará escribiendo bits de Acceso y Sucio en la memoria liberada mientras intenta recorrer las tablas de páginas obsoletas.<br /> <br /> Actualmente, los contextos SVA no tienen privilegios y no pueden acceder a las asignaciones del kernel. Sin embargo, el IOMMU seguirá recorriendo tablas de páginas solo del kernel hasta las entradas hoja, donde se da cuenta de que la asignación es para el kernel y produce un error. Esto significa que el IOMMU aún almacena en caché estas entradas intermedias de la tabla de páginas, lo que convierte la vulnerabilidad descrita en una preocupación real.<br /> <br /> Deshabilitar SVA en la arquitectura x86 hasta que el IOMMU pueda recibir notificación para vaciar la caché de paginación antes de liberar las páginas de la tabla de páginas del kernel de la CPU.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> RDMA/cm: Soluciona la fuga de la referencia de la tabla GID de multidifusión<br /> <br /> Si el ID de CM es destruido mientras el evento de CM para la creación de multidifusión aún está en cola, la función cancel_work_sync() evitará que el trabajo se ejecute, lo que también impide destruir el ah_attr. Esto provoca una fuga de refcount y activa una ADVERTENCIA:<br /> <br /> Fuga de referencia de entrada GID para dev syz1 índice 2 ref=573<br /> ADVERTENCIA: CPU: 1 PID: 655 en drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline]<br /> ADVERTENCIA: CPU: 1 PID: 655 en drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886<br /> <br /> Destruir el ah_attr después de cancelar el trabajo; es seguro llamar a esto dos veces.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ipv6: BUG() en pskb_expand_head() como parte de calipso_skbuff_setattr()<br /> <br /> Existe un oops del kernel causado por un BUG_ON(nhead &amp;lt; 0) en net/core/skbuff.c:2232 en pskb_expand_head(). Este error se activa como parte de la rutina calipso_skbuff_setattr() cuando a skb_cow() se le pasa un headroom &amp;gt; INT_MAX (es decir, (int)(skb_headroom(skb) + len_delta) &amp;lt; 0).<br /> <br /> La causa raíz del error se debe a una conversión implícita de entero en __skb_cow(). La comprobación (headroom &amp;gt; skb_headroom(skb)) tiene como objetivo asegurar que delta = headroom - skb_headroom(skb) nunca sea negativo, de lo contrario, activaremos un BUG_ON en pskb_expand_head(). Sin embargo, si headroom &amp;gt; INT_MAX y delta &amp;lt;= -NET_SKB_PAD, la comprobación pasa, delta se vuelve negativo y a pskb_expand_head() se le pasa un valor negativo para nhead.<br /> <br /> Corregir la condición de activación en calipso_skbuff_setattr(). Evitar pasar tamaños de &amp;#39;headroom&amp;#39; &amp;#39;negativos&amp;#39; a skb_cow() dentro de calipso_skbuff_setattr() utilizando únicamente skb_cow() para aumentar el headroom.<br /> <br /> PoC:<br /> Usando la herramienta &amp;#39;netlabelctl&amp;#39;:<br /> <br /> netlabelctl map del default<br /> netlabelctl calipso add pass doi:7<br /> netlabelctl map add default address:0::1/128 protocol:calipso,7<br /> <br /> Luego ejecute el siguiente PoC:<br /> <br /> int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);<br /> <br /> // setup msghdr<br /> int cmsg_size = 2;<br /> int cmsg_len = 0x60;<br /> struct msghdr msg;<br /> struct sockaddr_in6 dest_addr;<br /> struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1,<br /> sizeof(struct cmsghdr) + cmsg_len);<br /> msg.msg_name = &amp;amp;dest_addr;<br /> msg.msg_namelen = sizeof(dest_addr);<br /> msg.msg_iov = NULL;<br /> msg.msg_iovlen = 0;<br /> msg.msg_control = cmsg;<br /> msg.msg_controllen = cmsg_len;<br /> msg.msg_flags = 0;<br /> <br /> // setup sockaddr<br /> dest_addr.sin6_family = AF_INET6;<br /> dest_addr.sin6_port = htons(31337);<br /> dest_addr.sin6_flowinfo = htonl(31337);<br /> dest_addr.sin6_addr = in6addr_loopback;<br /> dest_addr.sin6_scope_id = 31337;<br /> <br /> // setup cmsghdr<br /> cmsg-&amp;gt;cmsg_len = cmsg_len;<br /> cmsg-&amp;gt;cmsg_level = IPPROTO_IPV6;<br /> cmsg-&amp;gt;cmsg_type = IPV6_HOPOPTS;<br /> char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr);<br /> hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80<br /> <br /> sendmsg(fd, &amp;amp;msg, 0);

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: rose: corrige índice de array inválido en rose_kill_by_device()<br /> <br /> rose_kill_by_device() recopila sockets en un array[] local y luego itera sobre ellos para desconectar los sockets vinculados a un dispositivo que está siendo dado de baja.<br /> <br /> El bucle indexa erróneamente array[cnt] en lugar de array[i]. Para cnt &amp;lt; ARRAY_SIZE(array), esto lee una entrada no inicializada; para cnt == ARRAY_SIZE(array), es una lectura fuera de límites. Cualquiera de los dos casos puede llevar a una desreferenciación de puntero de socket inválida y también filtra referencias tomadas a través de sock_hold().<br /> <br /> Corrige el índice para usar i.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iavf: corrige problemas de &amp;#39;off-by-one&amp;#39; en iavf_config_rss_reg()<br /> <br /> Existen errores de &amp;#39;off-by-one&amp;#39; al configurar la clave hash RSS y la tabla de búsqueda, causando lecturas fuera de límites a la memoria [1] y escrituras fuera de límites a los registros del dispositivo.<br /> <br /> Antes del commit 43a3d9ba34c9 (&amp;#39;i40evf: Permitir al controlador PF configurar RSS&amp;#39;), los límites superiores del bucle eran:<br /> i &amp;lt;= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX<br /> lo cual es seguro ya que el valor es el último índice válido.<br /> <br /> Ese commit cambió los límites a:<br /> i &amp;lt;= adapter-&amp;gt;rss_{key,lut}_size / 4<br /> donde &amp;#39;rss_{key,lut}_size / 4&amp;#39; es el número de dwords, por lo que el último índice válido es &amp;#39;(rss_{key,lut}_size / 4) - 1&amp;#39;. Por lo tanto, usar &amp;#39;&amp;lt;=&amp;#39; accede a un elemento más allá del final.<br /> <br /> Se corrigen los problemas usando &amp;#39;&amp;lt;&amp;#39; en lugar de &amp;#39;&amp;lt;=&amp;#39;, asegurando que no excedemos los límites.<br /> <br /> [1] Informe de KASAN sobre el &amp;#39;off-by-one&amp;#39; de rss_key_size<br /> ERROR: KASAN: &amp;#39;slab-out-of-bounds&amp;#39; en iavf_config_rss+0x619/0x800<br /> Lectura de tamaño 4 en la dirección ffff888102c50134 por la tarea kworker/u8:6/63<br /> <br /> CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 No contaminado 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntario)<br /> Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Cola de trabajo: iavf iavf_watchdog_task<br /> Traza de llamadas:<br /> <br /> dump_stack_lvl+0x6f/0xb0<br /> print_report+0x170/0x4f3<br /> kasan_report+0xe1/0x1a0<br /> iavf_config_rss+0x619/0x800<br /> iavf_watchdog_task+0x2be7/0x3230<br /> process_one_work+0x7fd/0x1420<br /> worker_thread+0x4d1/0xd40<br /> kthread+0x344/0x660<br /> ret_from_fork+0x249/0x320<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Asignado por la tarea 63:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x7f/0x90<br /> __kmalloc_noprof+0x246/0x6f0<br /> iavf_watchdog_task+0x28fc/0x3230<br /> process_one_work+0x7fd/0x1420<br /> worker_thread+0x4d1/0xd40<br /> kthread+0x344/0x660<br /> ret_from_fork+0x249/0x320<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> La dirección con error pertenece al objeto en ffff888102c50100<br /> el cual pertenece a la caché kmalloc-64 de tamaño 64<br /> La dirección con error está ubicada 0 bytes a la derecha de<br /> la región asignada de 52 bytes [ffff888102c50100, ffff888102c50134)<br /> <br /> La dirección con error pertenece a la página física:<br /> página: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50<br /> flags: 0x200000000000000(node=0|zone=2)<br /> page_type: f5(slab)<br /> raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000<br /> raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000<br /> página volcada porque: kasan: acceso incorrecto detectado<br /> <br /> Estado de la memoria alrededor de la dirección con error:<br /> ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc<br /> ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc<br /> &amp;gt;ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc<br /> ^<br /> ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc<br /> ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mptcp: retroceso más temprano en conexión simultánea<br /> <br /> Syzkaller informa una condición de carrera de conexión simultánea que lleva a un estado de retroceso inconsistente:<br /> <br /> WARNING: CPU: 3 PID: 33 at net/mptcp/subflow.c:1515 subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515<br /> Modules linked in:<br /> CPU: 3 UID: 0 PID: 33 Comm: ksoftirqd/3 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515<br /> Code: 89 ee e8 78 61 3c f6 40 84 ed 75 21 e8 8e 66 3c f6 44 89 fe bf 07 00 00 00 e8 c1 61 3c f6 41 83 ff 07 74 09 e8 76 66 3c f6 90 &amp;lt;0f&amp;gt; 0b 90 e8 6d 66 3c f6 48 89 df e8 e5 ad ff ff 31 ff 89 c5 89 c6<br /> RSP: 0018:ffffc900006cf338 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff888031acd100 RCX: ffffffff8b7f2abf<br /> RDX: ffff88801e6ea440 RSI: ffffffff8b7f2aca RDI: 0000000000000005<br /> RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000007<br /> R10: 0000000000000004 R11: 0000000000002c10 R12: ffff88802ba69900<br /> R13: 1ffff920000d9e67 R14: ffff888046f81800 R15: 0000000000000004<br /> FS: 0000000000000000(0000) GS:ffff8880d69bc000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000560fc0ca1670 CR3: 0000000032c3a000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> tcp_data_queue+0x13b0/0x4f90 net/ipv4/tcp_input.c:5197<br /> tcp_rcv_state_process+0xfdf/0x4ec0 net/ipv4/tcp_input.c:6922<br /> tcp_v6_do_rcv+0x492/0x1740 net/ipv6/tcp_ipv6.c:1672<br /> tcp_v6_rcv+0x2976/0x41e0 net/ipv6/tcp_ipv6.c:1918<br /> ip6_protocol_deliver_rcu+0x188/0x1520 net/ipv6/ip6_input.c:438<br /> ip6_input_finish+0x1e4/0x4b0 net/ipv6/ip6_input.c:489<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> NF_HOOK include/linux/netfilter.h:312 [inline]<br /> ip6_input+0x105/0x2f0 net/ipv6/ip6_input.c:500<br /> dst_input include/net/dst.h:471 [inline]<br /> ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline]<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> NF_HOOK include/linux/netfilter.h:312 [inline]<br /> ipv6_rcv+0x264/0x650 net/ipv6/ip6_input.c:311<br /> __netif_receive_skb_one_core+0x12d/0x1e0 net/core/dev.c:5979<br /> __netif_receive_skb+0x1d/0x160 net/core/dev.c:6092<br /> process_backlog+0x442/0x15e0 net/core/dev.c:6444<br /> __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7494<br /> napi_poll net/core/dev.c:7557 [inline]<br /> net_rx_action+0xa9f/0xfe0 net/core/dev.c:7684<br /> handle_softirqs+0x216/0x8e0 kernel/softirq.c:579<br /> run_ksoftirqd kernel/softirq.c:968 [inline]<br /> run_ksoftirqd+0x3a/0x60 kernel/softirq.c:960<br /> smpboot_thread_fn+0x3f7/0xae0 kernel/smpboot.c:160<br /> kthread+0x3c2/0x780 kernel/kthread.c:463<br /> ret_from_fork+0x5d7/0x6f0 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> <br /> El subflujo TCP puede procesar el paquete syn-ack de conexión simultánea después de la transición al estado TCP_FIN1, evitando la verificación de retroceso de MPTCP, ya que la devolución de llamada sk_state_change() no se invoca para transiciones de * -&amp;gt; FIN_WAIT1.<br /> <br /> Eso moverá el socket msk a un estado inconsistente y los próximos datos entrantes alcanzarán el splat reportado.<br /> <br /> Cerrar la condición de carrera moviendo la verificación de retroceso simultáneo en la etapa más temprana posible, es decir, en el momento de la generación del syn-ack.<br /> <br /> Sobre las etiquetas de correcciones: [2] se suponía que también corregiría este problema introducido por [3]. [1] es requerido como dependencia: no fue marcado explícitamente como una corrección, pero lo es y ya ha sido retroportado antes de [3]. En otras palabras, este commit debería ser retroportado hasta [3], incluyendo [2] y [1] si aún no están allí.