Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: agregar la gestión de errores faltante dentro de get_canonical_dev_path Dentro de la función get_canonical_dev_path(), llamamos a d_path() para obtener la ruta final del dispositivo. Pero d_path() puede devolver un error y, en ese caso, la siguiente llamada a strscpy() activará un acceso a memoria no válido. Agregue nuevamente la gestión de errores faltante para d_path().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pktgen: Evitar acceso fuera de los límites en get_imix_entries Pasar una cantidad suficiente de entradas imix conduce a un acceso no válido a la matriz pkt_dev->imix_entries debido a la verificación de los límites incorrecta. UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24 index 20 is out of range for type 'imix_pkt [20]' CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: dump_stack_lvl lib/dump_stack.c:117 __ubsan_handle_out_of_bounds lib/ubsan.c:429 get_imix_entries net/core/pktgen.c:874 pktgen_if_write net/core/pktgen.c:1063 pde_write fs/proc/inode.c:334 proc_reg_write fs/proc/inode.c:346 vfs_write fs/read_write.c:593 ksys_write fs/read_write.c:644 do_syscall_64 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:130 Found by Linux Verification Center (linuxtesting.org) with SVACE. [ fp: allow to fill the array completely; minor changelog cleanup ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: openvswitch: fix lockup on tx to unregistering netdev with carrier Commit en una etiqueta fixes intentó solucionar el problema en la siguiente secuencia de llamadas: do_output -> ovs_vport_send -> dev_queue_xmit -> __dev_queue_xmit -> netdev_core_pick_tx -> skb_tx_hash Cuando el dispositivo está anulando el registro, 'dev->real_num_tx_queues' va a cero y el bucle 'while (unlikely(hash >= qcount))' dentro de 'skb_tx_hash' se vuelve infinito, bloqueando el núcleo para siempre. Pero desafortunadamente, verificar solo el estado del operador no es suficiente para solucionar el problema, porque algunos dispositivos aún pueden estar en estado de anulación de registro mientras informan que el estado del operador es correcto. Un ejemplo de dicho dispositivo es un net/dummy. Activa el operador al iniciar, pero no implementa .ndo_stop para desactivarlo. Y tiene sentido, porque dummy en realidad no tiene un operador. Por lo tanto, mientras este dispositivo se está anulando el registro, sigue siendo fácil alcanzar el bucle infinito en skb_tx_hash() desde la ruta de datos de OVS. Puede haber otros controladores que hagan lo mismo, pero dummy por sí solo es importante para el ecosistema OVS, porque se usa con frecuencia como un receptor de paquetes para tcpdump mientras se depuran las implementaciones de OVS. Y cuando se produce el problema, la única forma de recuperarse es reiniciar. Solucione eso comprobando también si el dispositivo está en ejecución. El estado de ejecución controla el núcleo de red durante la anulación del registro, por lo que cubre mejor el caso de anulación del registro y realmente no necesitamos enviar paquetes a dispositivos que no se están ejecutando de todos modos. Si bien solo comprobar el estado de ejecución puede ser suficiente, la comprobación del operador se conserva. Los estados de ejecución y del operador parecen estar separados en todo el código y en los diferentes controladores. Y otras funciones básicas como __dev_direct_xmit() comprueban ambos antes de intentar transmitir un paquete. Por lo tanto, parece más seguro comprobar también ambos indicadores en OVS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se solucionó la pérdida de memoria de bpf_sk_select_reuseport() Como se señaló en el comentario original, la búsqueda en sockmap puede devolver un socket TCP ESTABLISHED. Es posible que dicho socket TCP haya tenido SO_ATTACH_REUSEPORT_EBPF configurado antes de que se estableciera. En otras palabras, un sk_reuseport_cb que no sea NULL no implica un socket sin referencia. Elimine la referencia de sk en ambas rutas de error. objeto sin referencia 0xffff888101911800 (tamaño 2048): comm "test_progs", pid 44109, jiffies 4297131437 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ seguimiento inverso (crc 9336483b): __kmalloc_noprof+0x3bf/0x560 __reuseport_alloc+0x1d/0x40 reuseport_alloc+0xca/0x150 reuseport_attach_prog+0x87/0x140 sk_reuseport_attach_bpf+0xc8/0x100 sk_setsockopt+0x1181/0x1990 do_sock_setsockopt+0x12b/0x160 __sys_setsockopt+0x7b/0xc0 __x64_sys_setsockopt+0x1b/0x30 do_syscall_64+0x93/0x180 entrada_SYSCALL_64_después_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: bnxt: siempre recalcula las características después de borrar XDP, corrige null-deref Recalcula las características cuando se desconecta XDP. Antes: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: off [solicitado el] Después: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: on El hecho de que HW-GRO no se vuelva a habilitar automáticamente es solo una molestia menor. El problema real es que las funciones volverán de forma aleatoria durante otra reconfiguración que invoca netdev_update_features(). El controlador no gestiona la reconfiguración de dos cosas a la vez de forma muy robusta. A partir de el commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in __bnxt_reserve_rings()"), solo reconfiguramos la tabla hash RSS si el número "efectivo" de anillos Rx ha cambiado. Si HW-GRO está habilitado, el número "efectivo" de anillos es el doble de lo que ve el usuario. Entonces, si estamos en un mal estado, con la rehabilitación de HW-GRO "pendiente" después de desactivar XDP, y reducimos los anillos en / 2, los anillos de HW-GRO haciendo 2x y ethtool -L haciendo / 2 pueden cancelarse entre sí, y la condición: if (old_rx_rings != bp->hw_resc.resv_rx_rings && en __bnxt_reserve_rings() será falsa. El mapa RSS no se actualizará y nos bloquearemos con: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000168 RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0 bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180 __bnxt_setup_vnic_p5+0x58/0x110 bnxt_init_nic+0xb72/0xf50 __bnxt_open_nic+0x40d/0xab0 bnxt_open_nic+0x2b/0x60 ethtool_set_channels+0x18c/0x1d0 Cuando intentamos acceder a un anillo liberado, el problema está presente desde que se agregó la compatibilidad con XDP, pero antes de el commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in __bnxt_reserve_rings()") no causaba problemas importantes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vsock/bpf: retorno anticipado si el transporte no está asignado Algunas de las funciones principales solo se pueden llamar si el transporte ha sido asignado. Como informó Michal, un socket puede tener el transporte en NULL, por ejemplo después de un connect() fallido, lo que provoca el siguiente seguimiento: ERROR: desreferencia de puntero NULL del núcleo, dirección: 00000000000000a0 #PF: acceso de lectura de supervisor en modo núcleo #PF: error_code(0x0000) - página no presente PGD 12faf8067 P4D 12faf8067 PUD 113670067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 15 UID: 0 PID: 1198 Comm: a.out No contaminado 6.13.0-rc2+ RIP: 0010:vsock_connectible_has_data+0x1f/0x40 Seguimiento de llamada: vsock_bpf_recvmsg+0xca/0x5e0 sock_recvmsg+0xb9/0xc0 __sys_recvfrom+0xb3/0x130 __x64_sys_recvfrom+0x20/0x30 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Por lo tanto, debemos verificar `vsk->transport` en vsock_bpf_recvmsg(), especialmente para sockets conectados (stream/seqpacket) como ya lo hacemos en __vsock_connectible_recvmsg().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: afs: Se corrige la condición de error de la regla de preferencia de fusión. syzbot informó de un bloqueo retenido al volver al espacio de usuario[1]. Esto se debe a que si argc es menor que 0 y la función retorna directamente, el bloqueo del inodo retenido no se libera. Corrija esto almacenando el error en ret y saltando a done para limpiar en lugar de regresar directamente. [dh: Se modificó el parche original de Lizhi Xu para que respete el código de error de afs_split_string()] [1] ADVERTENCIA: ¡bloqueo retenido al volver al espacio de usuario! 6.13.0-rc3-syzkaller-00209-g499551201b5f #0 No contaminado ------------------------------------------------ ¡syz-executor133/5823 está abandonando el kernel con bloqueos aún retenidos! 1 bloqueo mantenido por syz-executor133/5823: #0: ffff888071cffc00 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, en: inode_lock include/linux/fs.h:818 [en línea] #0: ffff888071cffc00 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, en: afs_proc_addr_prefs_write+0x2bb/0x14e0 fs/afs/addr_prefs.c:388

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: se corrige la doble liberación de TCP_Server_Info::hostname Al apagar el servidor en cifs_put_tcp_session(), el hilo cifsd podría estar reconectándose a múltiples objetivos DFS antes de darse cuenta de que debería salir del bucle, por lo que @server->hostname no se puede liberar mientras el hilo cifsd no haya terminado. De lo contrario, puede ocurrir lo siguiente: RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __reconnect_target_unlocked+0x3e/0x160 [cifs] ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0xce/0x120 ? __slab_free+0x223/0x3c0 ? do_error_trap+0x65/0x80 ? __slab_free+0x223/0x3c0 ? exc_invalid_op+0x4e/0x70 ? __slab_free+0x223/0x3c0 ? asm_exc_invalid_op+0x16/0x20 ? __slab_free+0x223/0x3c0 ? extract_hostname+0x5c/0xa0 [cifs] ? extract_hostname+0x5c/0xa0 [cifs] ? __kmalloc+0x4b/0x140 __reconnect_target_unlocked+0x3e/0x160 [cifs] reconnect_dfs_server+0x145/0x430 [cifs] cifs_handle_standard+0x1ad/0x1d0 [cifs] cifs_demultiplex_thread+0x592/0x730 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Se corrige la advertencia de dependencia de inversión al habilitar el túnel IPsec El intento de habilitar la descarga de paquetes IPsec en modo túnel en el kernel de depuración genera el siguiente pánico del kernel, que ocurre debido a dos problemas: 1. En la sección de adición de SA, debería ser la variante _bh() al marcar el modo SA. 2. No se necesita flush_workqueue en la rutina de eliminación de SA. No es necesario en esta etapa, ya que se elimina de SADB y el trabajo en ejecución se cancelará más tarde en la liberación de SA. ======================================================== ADVERTENCIA: Se detectó orden de bloqueo SOFTIRQ-safe -> SOFTIRQ-unsafe 6.12.0+ #4 No contaminado -----------------------------------------------------charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire: ffff88810f365020 (&xa->xa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core] and this task is already holding: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30 which would create a new lock dependency: (&x->lock){+.-.}-{3:3} -> (&xa->xa_lock#24){+.+.}-{3:3} but this new dependency connects a SOFTIRQ-irq-safe lock: (&x->lock){+.-.}-{3:3} ... which became SOFTIRQ-irq-safe at: lock_acquire+0x1be/0x520 _raw_spin_lock_bh+0x34/0x40 xfrm_timer_handler+0x91/0xd70 __hrtimer_run_queues+0x1dd/0xa60 hrtimer_run_softirq+0x146/0x2e0 handle_softirqs+0x266/0x860 irq_exit_rcu+0x115/0x1a0 sysvec_apic_timer_interrupt+0x6e/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20 default_idle+0x13/0x20 default_idle_call+0x67/0xa0 do_idle+0x2da/0x320 cpu_startup_entry+0x50/0x60 start_secondary+0x213/0x2a0 common_startup_64+0x129/0x138 to a SOFTIRQ-irq-unsafe lock: (&xa->xa_lock#24){+.+.}-{3:3} ... which became SOFTIRQ-irq-unsafe at: ... lock_acquire+0x1be/0x520 _raw_spin_lock+0x2c/0x40 xa_set_mark+0x70/0x110 mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core] xfrm_dev_state_add+0x3bb/0xd70 xfrm_add_sa+0x2451/0x4a90 xfrm_user_rcv_msg+0x493/0x880 netlink_rcv_skb+0x12e/0x380 xfrm_netlink_rcv+0x6d/0x90 netlink_unicast+0x42f/0x740 netlink_sendmsg+0x745/0xbe0 __sock_sendmsg+0xc5/0x190 __sys_sendto+0x1fe/0x2c0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&xa->xa_lock#24); local_irq_disable(); lock(&x->lock); lock(&xa->xa_lock#24); lock(&x->lock); *** DEADLOCK *** 2 locks held by charon/1337: #0: ffffffff87f8f858 (&net->xfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90 #1: ffff88813e0f0d48 (&x->lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30 the dependencies between SOFTIRQ-irq-safe lock and the holding lock: -> (&x->lock){+.-.}-{3:3} ops: 29 { HARDIRQ-ON-W at: lock_acquire+0x1be/0x520 _raw_spin_lock_bh+0x34/0x40 xfrm_alloc_spi+0xc0/0xe60 xfrm_alloc_userspi+0x5f6/0xbc0 xfrm_user_rcv_msg+0x493/0x880 netlink_rcv_skb+0x12e/0x380 xfrm_netlink_rcv+0x6d/0x90 netlink_unicast+0x42f/0x740 netlink_sendmsg+0x745/0xbe0 __sock_sendmsg+0xc5/0x190 __sys_sendto+0x1fe/0x2c0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 IN-SOFTIRQ-W at: lock_acquire+0x1be/0x520 _raw_spin_lock_bh+0x34/0x40 xfrm_timer_handler+0x91/0xd70 __hrtimer_run_queues+0x1dd/0xa60 ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pfcp: Destruye el dispositivo junto con el desmantelamiento de netns del socket udp. pfcp_newlink() vincula el dispositivo a una lista en dev_net(dev) en lugar de net, donde se crea un socket de túnel udp. Incluso cuando se elimina net, el dispositivo permanece activo en dev_net(dev). Luego, eliminar net activa el splat a continuación. [0] En este ejemplo, pfcp0 se crea en ns2, pero el socket udp se crea en ns1. ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name pfcp0 type pfcp ip netns del ns1 Vinculemos el dispositivo al netns del socket en su lugar. Ahora, pfcp_net_exit() necesita otra iteración netdev para eliminar todos los dispositivos pfcp en el netns. pfcp_dev_list no se utiliza en RCU, por lo que la API de lista se convierte a la variante que no es RCU. pfcp_net_exit() can be converted to .exit_batch_rtnl() in net-next. [0]: ref_tracker: net notrefcnt@00000000128b34dc has 1/1 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) pfcp_create_sock (drivers/net/pfcp.c:168) pfcp_newlink (drivers/net/pfcp.c:182 drivers/net/pfcp.c:197) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347) netlink_sendmsg (net/netlink/af_netlink.c:1891) ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) ___sys_sendmsg (net/socket.c:2639) __sys_sendmsg (net/socket.c:2669) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) WARNING: CPU: 1 PID: 11 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179) Modules linked in: CPU: 1 UID: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179) Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89 RSP: 0018:ff11000007f3fb60 EFLAGS: 00010286 RAX: 00000000000020ef RBX: ff1100000d6481e0 RCX: 1ffffffff0e40d82 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c RBP: ff1100000d648230 R08: 0000000000000001 R09: fffffbfff0e395af R10: 0000000000000001 R11: 0000000000000000 R12: ff1100000d648230 R13: dead000000000100 R14: ff1100000d648230 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005620e1363990 CR3: 000000000eeb2002 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn (kernel/panic.c:748) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:285) ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467) cleanup_net (net/cor ---truncated---

En el kernel Linux, se ha resuelto la siguiente vulnerabilidad: vsock/virtio: descartar paquetes si cambia el transporte Si el socket ha sido desasignado o asignado a otro transporte, debemos descartar cualquier paquete recibido porque no son los esperados y causarían problemas cuando accedamos a vsk->transport. Un posible escenario es descrito por Hyunwoo Kim en el enlace adjunto, donde después de un primer connect() interrumpido por una señal, y un segundo connect() fallido, podemos encontrar `vsk->transport` en NULL, lo que lleva a una desreferencia de puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: zram: se corrige el UAF potencial de la tabla zram. Si zram_meta_alloc falla antes, libera la tabla zram-> asignada sin configurarla como NULL. Esto potencialmente hará que zram_meta_free acceda a la tabla si el usuario reinicia un dispositivo fallido y no inicializado.