Vulnerabilidades

Una vulnerabilidad de validación de entrada insuficiente en el NETGEAR XR1000v2 permite a atacantes conectados a la LAN del router ejecutar inyecciones de comandos del sistema operativo.

Una vulnerabilidad de autenticación insuficiente en extensores de rango WiFi NETGEAR permite a un atacante adyacente a la red con autenticación WiFi o una conexión física al puerto Ethernet eludir el proceso de autenticación y acceder al panel de administración.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> e1000: corrección de OOB en e1000_tbi_should_accept()<br /> <br /> En e1000_tbi_should_accept() leemos el último byte de la trama a través de data[length - 1] para evaluar la solución alternativa de TBI. Si la longitud reportada por el descriptor es cero o mayor que el tamaño real del búfer RX, esta lectura se sale de los límites y puede afectar objetos slab no relacionados. El problema se observa desde la ruta de recepción NAPI (e1000_clean_rx_irq):<br /> <br /> ==================================================================<br /> ERROR: KASAN: slab-out-of-bounds en e1000_tbi_should_accept+0x610/0x790<br /> Lectura de tamaño 1 en la dirección ffff888014114e54 por la tarea sshd/363<br /> <br /> CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014<br /> Traza de Llamada:<br /> <br /> dump_stack_lvl+0x5a/0x74<br /> print_address_description+0x7b/0x440<br /> print_report+0x101/0x200<br /> kasan_report+0xc1/0xf0<br /> e1000_tbi_should_accept+0x610/0x790<br /> e1000_clean_rx_irq+0xa8c/0x1110<br /> e1000_clean+0xde2/0x3c10<br /> __napi_poll+0x98/0x380<br /> net_rx_action+0x491/0xa20<br /> __do_softirq+0x2c9/0x61d<br /> do_softirq+0xd1/0x120<br /> <br /> <br /> __local_bh_enable_ip+0xfe/0x130<br /> ip_finish_output2+0x7d5/0xb00<br /> __ip_queue_xmit+0xe24/0x1ab0<br /> __tcp_transmit_skb+0x1bcb/0x3340<br /> tcp_write_xmit+0x175d/0x6bd0<br /> __tcp_push_pending_frames+0x7b/0x280<br /> tcp_sendmsg_locked+0x2e4f/0x32d0<br /> tcp_sendmsg+0x24/0x40<br /> sock_write_iter+0x322/0x430<br /> vfs_write+0x56c/0xa60<br /> ksys_write+0xd1/0x190<br /> do_syscall_64+0x43/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f511b476b10<br /> Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 &amp;lt;48&amp;gt; 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24<br /> RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10<br /> RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003<br /> RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00<br /> R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003<br /> <br /> Asignado por la tarea 1:<br /> __kasan_krealloc+0x131/0x1c0<br /> krealloc+0x90/0xc0<br /> add_sysfs_param+0xcb/0x8a0<br /> kernel_add_sysfs_param+0x81/0xd4<br /> param_sysfs_builtin+0x138/0x1a6<br /> param_sysfs_init+0x57/0x5b<br /> do_one_initcall+0x104/0x250<br /> do_initcall_level+0x102/0x132<br /> do_initcalls+0x46/0x74<br /> kernel_init_freeable+0x28f/0x393<br /> kernel_init+0x14/0x1a0<br /> ret_from_fork+0x22/0x30<br /> La dirección errónea pertenece al objeto en ffff888014114000<br /> que pertenece a la caché kmalloc-2k de tamaño 2048<br /> La dirección errónea se encuentra 1620 bytes a la derecha de<br /> región de 2048 bytes [ffff888014114000, ffff888014114800]<br /> La dirección errónea pertenece a la página física:<br /> page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110<br /> head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0<br /> flags: 0x100000000010200(slab|head|node=0|zone=1)<br /> raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000<br /> raw: 0000000000000000 0000000000080008

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: usb: asix: validar dirección PHY antes de usar<br /> <br /> El controlador ASIX lee la dirección PHY del dispositivo USB a través de asix_read_phy_addr(). Un dispositivo malicioso o defectuoso puede devolver una dirección no válida (&amp;gt;= PHY_MAX_ADDR), lo que causa una advertencia en mdiobus_get_phy():<br /> <br /> addr 207 fuera de rango<br /> WARNING: drivers/net/phy/mdio_bus.c:76<br /> <br /> Validar la dirección PHY en asix_read_phy_addr() y eliminar la comprobación ahora redundante en ax88172a.c.

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 /> 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);