Vulnerabilidades

Una vulnerabilidad de omisión de autenticación en dispositivos NETGEAR Orbi permite a los usuarios conectados a la red local acceder a la interfaz web del router como administrador.

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 /> 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.