Vulnerabilidades

Se encontró una vulnerabilidad de doble liberación en libdwarf. En un objeto DWARF multicorrupto, libdwarf puede intentar desasignar (liberar) una asignación dos veces, lo que podría provocar resultados diversos e impredecibles.

Se encontró una falla en iperf, una utilidad para probar el rendimiento de la red mediante TCP, UDP y SCTP. Un cliente malicioso o que no funciona correctamente puede enviar menos cantidad de datos de la esperada al servidor iperf, lo que puede hacer que el servidor se cuelgue indefinidamente esperando el resto o hasta que se cierre la conexión. Esto evitará otras conexiones al servidor, lo que provocará una denegación de servicio.

Las versiones 2023.6, 2021.12 y anteriores de ColdFusion se ven afectadas por una vulnerabilidad de control de acceso inadecuado que podría provocar una lectura arbitraria del sistema de archivos. Un atacante podría aprovechar esta vulnerabilidad para eludir las medidas de seguridad y obtener acceso no autorizado a archivos confidenciales y realizar escrituras arbitrarias en el sistema de archivos. La explotación de este problema no requiere la interacción del usuario.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tcp: agregue controles de seguridad a rx zerocopy La intención de TCP rx zerocopy es mapear páginas inicialmente asignadas desde controladores NIC, no páginas propiedad de un fs. Este parche añade a can_map_frag() estas comprobaciones adicionales: - La página no debe ser compuesta. - página->mapeo debe ser NULL. Esto soluciona el pánico informado por ZhangPeng. syzbot pudo realizar un loopback de paquetes creados con sendfile(), asignando páginas propiedad de un archivo ext4 a TCP rx zerocopy. r3 = socket$inet_tcp(0x2, 0x1, 0x0) mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0) r4 = socket$inet_tcp(0x2, 0x1, 0x0) bind$inet(r4 , &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10) connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10) r5 = openat$dir(0xffffffffffffff9c, &(0x7f00) 000000c0 )='./file0\x00', 0x181e42, 0x0) fallocate(r5, 0x0, 0x0, 0x85b8) sendfile(r4, r5, 0x0, 0x8ba0) getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &(0x7f00000) 001c0)={ &(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40) r6 = openat$dir(0xffffffffffffff9c, &(0x7f000) 00000c0)='./archivo0 \x00', 0x181e42, 0x0)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ip6_tunnel: asegúrese de extraer el encabezado interno en __ip6_tnl_rcv(). El syzbot encontró que __ip6_tnl_rcv() podía acceder a datos unificados [1]. Llame a pskb_inet_may_pull() para solucionar este problema e inicialice la variable ipv6h después de esta llamada, ya que puede cambiar skb->head. [1] ERROR: KMSAN: valor uninit en __INET_ECN_decapsulate include/net/inet_ecn.h:253 [en línea] ERROR: KMSAN: valor uninit en INET_ECN_decapsulate include/net/inet_ecn.h:275 [en línea] ERROR: KMSAN: uninit -valor en IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [en línea] INET_ECN_decapsulate include/net/inet_ecn.h:275 [en línea] IP6_ECN_decapsulate+0x7df/0x1e50 include/ net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv 6/ip6_tunnel.c:888 gre_rcv +0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [en línea] NF_HOOK include/linux/netfilter.h:314 [en línea] ip6_input+0x15d/0x 430 netos /ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [en línea] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [en línea] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [en línea] __netif_receive_skb+0x1a6/0x5a0 net/core/dev. c:5646 netif_receive_skb_internal net/core/dev.c:5732 [en línea] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers /net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [en línea] new_sync_write fs/read_write.c:497 [en línea] vfs_write+0x786/ 0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [en línea] __se_sys_write fs/read_write.c:652 [en línea] __x64_sys_write+0x93/0xd0 fs/read _escribir .c:652 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit se creó en: slab_post_alloc_hook+0x129/0xa 70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [en línea] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net /core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [en línea] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [en línea] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [en línea] new_sync_write fs/read_write.c:497 [en línea] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [en línea] __se_sys_write fs/read_write.c:652 [en línea] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x6d/0x140 arch/x86/entry/common. c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 5034 Comm: syz-executor331 No contaminado 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/ 2023

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: corrige la eliminación de un espacio de nombres con nombres alternativos en conflicto. Mark informa un ERROR() cuando se elimina un espacio de nombres de red. ¡ERROR del kernel en net/core/dev.c:11520! Las interfaces físicas movidas fuera de init_net se "reembolsan" a init_net cuando ese espacio de nombres desaparece. El nombre de la interfaz principal puede sobrescribirse en el proceso si hubiera entrado en conflicto. También debemos descartar todos los nombres alternativos en conflicto. Las correcciones recientes abordaron garantizar que los nombres alternativos se movieran con la interfaz principal, lo que provocó este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: llc: Eliminación del soporte para ETH_P_TR_802_2. syzbot informó un error de valor uninit a continuación. [0] llc admite ETH_P_802_2 (0x0004) y solía admitir ETH_P_TR_802_2 (0x0011), y syzbot abusó de este último para desencadenar el error. escribir$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd" }}}}, 0x16) llc_conn_handler() inicializa las variables locales {saddr,daddr}.mac basadas en skb en llc_pdu_decode_sa()/llc_pdu_decode_da() y las pasa a __llc_lookup(). Sin embargo, la inicialización se realiza solo cuando skb->protocol es htons(ETH_P_802_2); de lo contrario, __llc_lookup_establecido() y __llc_lookup_listener() leerán basura. La inicialización faltante existía antes de el commit 211ed865108e ("net: eliminar todas las instancias de procesamiento especial para Token Ring"). Quitó la parte para expulsar el token ring, pero se olvidó de cerrar la puerta permitiendo que los paquetes ETH_P_TR_802_2 se colaran en llc_rcv(). Eliminemos llc_tr_packet_type y completemos la desaprobación. [0]: ERROR: KMSAN: valor uninit en __llc_lookup_establecido+0xe9d/0xf90 __llc_lookup_establecido+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [en línea] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:79 1 llc_rcv +0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [en línea] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [en línea] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [en línea] new_sync_write fs/read_write.c:491 [en línea] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [en línea] __se_sys_write fs/read_write.c:646 [en línea] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common. c: 51 [en línea] do_syscall_64+0x44/0x110 arch/x86/entry/comunes.c: 82 entry_syscall_64_after_hwframe+0x63/0x6b local variable daddr creado FBB /0x14a0 net/llc/llc_input.c:206 CPU: 1 PID: 5004 Comm: syz-executor994 No contaminado 6.6.0-syzkaller-14500-g1c41041124bd #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 10 /09/2023

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: llc: hacer que llc_ui_sendmsg() sea más robusto contra cambios de vinculación syzbot pudo engañar a llc_ui_sendmsg(), asignando un skb sin espacio libre, pero posteriormente intentó enviar 14 bytes de encabezado Ethernet [ 1] Como otros, llc_ui_sendmsg() libera el bloqueo del socket antes de llamar a sock_alloc_send_skb(). Luego lo adquiere nuevamente, pero no rehace todas las comprobaciones de cordura que se realizaron. Esta solución: - Utiliza LL_RESERVED_SPACE() para reservar espacio. - Verifique todas las condiciones nuevamente después de mantener nuevamente el bloqueo del casquillo. - No tenga en cuenta el encabezado Ethernet para la limitación de mtu. [1] skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 ERROR del kernel en net/core/skbuff.c:193. Error interno: Ups - ERROR: 00000000f2000800 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 PID: 6875 Comm: syz-executor.0 No contaminado 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Nombre del hardware : Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: skb_panic net/core/skbuff.c:189 [en línea] pc: skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr: skb_panic net/core/skbuff.c:189 [en línea] lr: skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp: ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c 9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x1 7: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9: e28a51f1087e8400 x8: e28a 51f1087e8400 x7: ffff80008028f8d0 x6: 0000000000000000 x5: 0000000000000001 x4: 0000000000000001 x3: ffff800082b78714 x2: 00000000000000 001 x1: 0000000100000000 x0: 0000000000000089 Rastreo de llamadas: skb_panic net/core /skbuff.c:189 [en línea] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c: 83 dev_hard_header include/linux/netdevice.h:3188 [en línea] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_ acciones net/llc/llc_sap.c :153 [en línea] llc_sap_next_state net/llc/llc_sap.c:182 [en línea] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ ui_sendmsg+0x7bc/ 0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs /splice.c:881 do_splice_from fs/splice.c:933 [en línea] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice. c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [en línea] __se_sys_sendfile64 fs/read_write.c:1308 [en línea] __arm64_sys_sendfile64+0x160/0x3b4 fs /read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [en línea] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/ 0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+ 0x190/0x194 arch/arm64/kernel/entry.S:595 Código: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ath11k: confía en el manejo de debugfs de mac80211 para vif mac80211 comenzó a eliminar entradas de debugfs en ciertos casos, lo que provocó que ath11k fallara cuando intentó eliminar las entradas más tarde. Solucione este problema confiando en mac80211 para eliminar las entradas cuando corresponda y agregándolas desde el controlador vif_add_debugfs.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nbd: siempre inicializa completamente la estructura msghdr syzbot se queja de que el valor msg->msg_get_inq puede no estar inicializado [1] la estructura msghdr obtuvo muchos campos nuevos recientemente, siempre debemos asegurarnos de que sus valores sean cero por defecto. [1] ERROR: KMSAN: valor uninit en tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571 tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571 inet_recvmsg+0x131/0x580 net/ipv4/af_inet. c:879 sock_recvmsg_nosec net/socket.c:1044 [en línea] sock_recvmsg+0x12b/0x1e0 net/socket.c:1066 __sock_xmit+0x236/0x5c0 drivers/block/nbd.c:538 nbd_read_reply drivers/block/nbd.c:732 [en línea] recv_work+0x262/0x3100 drivers/block/nbd.c:863 Process_one_work kernel/workqueue.c:2627 [en línea] Process_scheduled_works+0x104e/0x1e70 kernel/workqueue.c:2700 workqueue.c :2781 kthread+0x3ed/0x540 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Mensaje de variable local creado en: __sock_xmit+0x4c/0x5c0 drivers/block/nbd.c:513 nbd_read_reply drivers/block/nbd.c:732 [en línea] recv_work+0x262/0x3100 drivers/block/nbd.c:863 CPU: 1 PID: 7465 Comm : kworker/u5:1 No contaminado 6.7.0-rc7-syzkaller-00041-gf016f7547aee #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 Cola de trabajo: nbd5-recv recv_work

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm, kmsan: corrige la recursividad infinita debido a la sección crítica de RCU Alexander Potapenko escribe en [1]: "Para cada acceso a memoria en el código instrumentado por KMSAN llamamos kmsan_get_metadata() para obtener los metadatos de la memoria a la que se accede. Para la memoria virtual, los punteros de metadatos se almacenan en la `página de estructura` correspondiente, por lo tanto, necesitamos llamar a virt_to_page() para obtenerlos. De acuerdo con el comentario en arch/x86/include/asm/page .h, virt_to_page(kaddr) devuelve un puntero válido si virt_addr_valid(kaddr) es verdadero, por lo que KMSAN también necesita llamar a virt_addr_valid(). Para evitar la recursividad, kmsan_get_metadata() no debe llamar al código instrumentado, por lo tanto ./arch/x86/ include/asm/kmsan.h bifurca partes de arch/x86/mm/physaddr.c para verificar si una dirección virtual es válida o no, pero la introducción de rcu_read_lock() a pfn_valid() agregó llamadas API de RCU instrumentadas a virt_to_page_or_null() , que es llamado por kmsan_get_metadata(), por lo que ahora hay una recursividad infinita. No creo que sea correcto detener esa recursividad haciendo kmsan_enter_runtime()/kmsan_exit_runtime() en kmsan_get_metadata(): eso evitaría que las funciones instrumentadas llamadas desde el tiempo de ejecución rastreen los valores ocultos, lo que podría introducir falsos positivos. problema al cambiar pfn_valid() a la variante _sched() de rcu_read_lock/unlock(), que no requiere llamar a RCU. Dado que la sección crítica en pfn_valid() es muy pequeña, esta es una compensación razonable (con RCU interrumpible ). Además, KMSAN debe tener cuidado de suprimir las llamadas al programador, lo que sería otra fuente de recursividad. Esto se puede hacer envolviendo la llamada a pfn_valid() en preempt_disable/enable_no_resched(). La desventaja es que esto sacrifica la interrupción de la programación. garantías; sin embargo, un kernel compilado con KMSAN ya ha renunciado a cualquier garantía de rendimiento debido a que está fuertemente instrumentado. Tenga en cuenta que el código KMSAN ya deshabilita el seguimiento a través de Makefile y, dado que mmzone.h está incluido, no es necesario usar la variante notrace, que generalmente se prefiere en todos los demás casos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: switchtec: corrige el bloqueo de stdev_release() después de una eliminación sorpresa en caliente. Puede ocurrir una eliminación en caliente del dispositivo PCI mientras stdev->cdev se mantiene abierto. La llamada a stdev_release() ocurre durante el cierre o la salida, en un punto mucho más allá de switchtec_pci_remove(). De lo contrario, la última referencia desaparecería con el put_device() final, justo antes del retorno. En ese momento posterior, la limpieza devm ya eliminó la asignación stdev->mmio_mrpc. Además, la referencia stdev->pdev no se contaba. Por lo tanto, en modo DMA, iowrite32() en stdev_release() causará un error de página fatal, y el dma_free_coherent() posterior, si se alcanza, pasaría un puntero &stdev->pdev->dev obsoleto. Para solucionarlo, mueva el apagado de MRPC DMA a switchtec_pci_remove(), después de stdev_kill(). Contar stdev->pdev ref ahora es opcional, pero puede evitar accidentes futuros. Reproducible a través del script en https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com