Vulnerabilidades

Unitree Go1 <= Go1_2022_05_11 es vulnerable a un control de acceso incorrecto debido a que las credenciales de autenticación están codificadas en texto sin formato.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: Se ha corregido el error use-after-free en tipc_conn_close(). syzbot informó de un error "null-ptr-deref" en tipc_conn_close() durante el desmantelamiento de netns. [0] tipc_topsrv_stop() itera tipc_net(net)->topsrv->conn_idr e invoca tipc_conn_close() para cada tipc_conn. El problema es que tipc_conn_close() se invoca tras liberar el bloqueo IDR. Simultáneamente, tipc_conn_recv_work() podría estar ejecutándose y podría invocar tipc_conn_close() para el mismo tipc_conn y liberar su último ->kref. Una vez que liberamos el bloqueo IDR en tipc_topsrv_stop(), no hay garantía de que tipc_conn siga activo. Mantengamos la referencia antes de liberar el bloqueo y coloquemos la referencia después de tipc_conn_close() en tipc_topsrv_stop(). [0]: BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435 CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00) The buggy address belongs to the page: page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0 flags: 0xfff00000000100(slab) raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940 raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netlink: Se corrigen los wraparounds de sk->sk_rmem_alloc. Netlink presenta este patrón en algunos lugares if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) atomic_add(skb->truesize, &sk->sk_rmem_alloc); , que presenta el mismo problema corregido por el commit 5a465a0da13e ("udp: Se corrigen múltiples wraparounds de sk->sk_rmem_alloc."). Por ejemplo, si establecemos INT_MAX en SO_RCVBUFFORCE, la condición siempre es falsa, ya que los dos operandos son de tipo int. En ese caso, un solo socket puede consumir tantos skb como sea posible hasta que se produzca un OOM, y podemos observar múltiples wraparounds de sk->sk_rmem_alloc. Para solucionarlo, usemos atomic_add_return() y comparemos las dos variables como enteros sin signo. Antes: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Dirección local: Puerto Dirección del par: Puerto -1668710080 0 rtnl:nl_wraparound/293 * Después: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Dirección local: Puerto Dirección del par: Puerto 2147483072 0 rtnl:nl_wraparound/290 * ^ `--- INT_MAX - 576

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: Revertir al requisito de CAP_SYS_ADMIN para uprobes. Jann informa que los uprobes pueden usarse de forma destructiva cuando se usan en medio de una instrucción. El kernel solo verifica que haya una instrucción válida en el desplazamiento solicitado, pero debido a la longitud variable de la instrucción, no puede determinar si se trata de una instrucción como la detecta el flujo de ejecución previsto. Además, Mark Rutland señala que en arquitecturas que mezclan datos en el segmento de texto (como arm64), se puede realizar una acción similar si la palabra de datos se confunde con una instrucción. Por lo tanto, se requiere CAP_SYS_ADMIN para uprobes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vsock: Se ha corregido el error "TOCTOU" de transport_{g2h,h2g}. vsock_find_cid() y vsock_dev_do_ioctl() podrían competir con la descarga del módulo. transport_{g2h,h2g} podría volverse nulo después de la comprobación de valores nulos. Se ha implementado vsock_transport_local_cid() para proteger contra una posible desreferencia de PTR nula. KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsock_find_cid+0x47/0x90 Call Trace: __vsock_bind+0x4b2/0x720 vsock_bind+0x90/0xe0 __sys_bind+0x14d/0x1e0 __x64_sys_bind+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0 Call Trace: __x64_sys_ioctl+0x12d/0x190 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: Correcto signado en el cálculo del espacio restante de skb Syzkaller informó de un error [1] en el que sk->sk_forward_alloc puede desbordarse. Al enviar datos, si existe un skb al final de la cola de escritura, el kernel intentará añadir los nuevos datos a ese skb. Sin embargo, el código que comprueba el espacio disponible en el skb presenta un fallo: ''' copy = size_goal - skb->len ''' Los tipos de las variables implicadas son: ''' copy: ssize_t (s64 en sistemas de 64 bits) size_goal: int skb->len: unsigned int ''' Debido a las reglas de promoción de tipos de C, el signed size_goal se convierte en un unsigned int para que coincida con skb->len antes de la resta. El resultado es un unsigned int. Cuando este resultado entero sin signo se asigna a la variable de copia s64, se extiende a cero, conservando su valor no negativo. Por lo tanto, la copia siempre es >= 0. Supongamos que enviamos 2 GB de datos y que size_goal se ha ajustado a un valor menor que skb->len. La resta hará que la copia contenga un entero positivo muy grande. En la lógica subsiguiente, este valor alto se utiliza para actualizar sk->sk_forward_alloc, lo que puede provocar fácilmente un desbordamiento. El reproductor syzkaller utiliza TCP_REPAIR para crear esta condición de forma fiable. Sin embargo, esto también puede ocurrir en situaciones reales. La función tcp_bound_to_half_wnd() también puede reducir size_goal a un valor pequeño. Esto provocaría que la función tcp_wmem_schedule() posterior estableciera sk->sk_forward_alloc en un valor cercano a INT_MAX. Las solicitudes de asignación de memoria adicionales harían que sk_forward_alloc se repita y se vuelva negativo. [1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipmi:msghandler: Se corrige una posible corrupción de memoria en ipmi_create_user(). El iterador de lista "intf" es un puntero no válido si no se encuentra el valor correcto "intf->intf_num". Llamar a atomic_dec(&intf->nr_users) en un puntero no válido provocará corrupción de memoria. No es necesario llamar a atomic_dec() si no se ha llamado a atomic_add_return(), así que actualice también la ruta if (intf->in_shutdown).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: Abort __tc_modify_qdisc si la clase padre no existe. El parche de Lion [1] reveló un error antiguo en la API de qdisc. Siempre que un usuario crea o modifica una qdisc que especifica otra qdisc como padre, la API de qdisc detecta, durante el injerto, que el usuario no intenta asociarse a una clase y lo rechaza. Sin embargo, el injerto se realiza después de ejecutar qdisc_create (y, por lo tanto, la devolución de llamada de inicio de la qdisc). En las qdisc que eventualmente llaman a qdisc_tree_reduce_backlog durante la inicialización o el cambio (como fq, hhf, choke, etc.), surge un problema. Por ejemplo, al ejecutar los siguientes comandos: sudo tc qdisc add dev lo root handle a: htb default 2 sudo tc qdisc add dev lo parent a: handle beef fq Las Qdisc como fq, hhf, choke, etc., invocan incondicionalmente qdisc_tree_reduce_backlog() en su ruta de control init() o change(), lo que provoca un error al no encontrar la clase hija; sin embargo, esto no detiene la invocación incondicional de qlen_notify de la qdisc hija asumida con una clase nula. Todas estas qdisc asumen que la clase no es nula. La solución es garantizar que qdisc_leaf(), que busca la clase padre y se invoca antes que qdisc_create(), devuelva un error al no encontrar la clase. En este parche, aprovechamos qdisc_leaf para devolver ERR_PTR siempre que el parentid no corresponda a una clase, de modo que podamos detectarlo antes y abortar antes de que se llame a qdisc_create. [1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atm: clip: Se corrige la desreferencia del puntero NULL en vcc_sendmsg() atmarpd_dev_ops no implementa el método de envío, lo que puede provocar un bloqueo como el que se muestra a continuación. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0010 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246 RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000 RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000 RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287 R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00 R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88 FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 ____sys_sendmsg+0x52d/0x830 net/socket.c:2566 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620 __sys_sendmmsg+0x227/0x430 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atm: clip: Se corrige la llamada recursiva infinita de clip_push(). syzbot informó del problema a continuación. [0] Esto sucede si llamamos a ioctl(ATMARP_MKIP) más de una vez. Durante la primera llamada, clip_mkip() establece clip_push() en vcc->push() y la segunda llamada lo copia a clip_vcc->old_push(). Más tarde, cuando se cierra el socket, vcc_destroy_socket() pasa NULL skb a clip_push(), que llama a clip_vcc->old_push() y activa la recursión infinita. Prevengamos el segundo ioctl(ATMARP_MKIP) comprobando vcc->user_back, que se asigna en la primera llamada como clip_vcc. Tenga en cuenta también que usamos lock_sock() para evitar llamadas con mucha carga. [0]: BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000) Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191 Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 <41> 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00 RSP: 0018:ffffc9000d670000 EFLAGS: 00010246 RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000 RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e R10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300 R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578 FS: 000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0 Call Trace: clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 ... clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 clip_push+0x6dc/0x720 net/atm/clip.c:200 vcc_destroy_socket net/atm/common.c:183 [inline] vcc_release+0x157/0x460 net/atm/common.c:205 __sock_release net/socket.c:647 [inline] sock_close+0xc0/0x240 net/socket.c:1391 __fput+0x449/0xa70 fs/file_table.c:465 task_work_run+0x1d1/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:114 exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline] do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff31c98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fffb5aa1f78 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226f R10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608c R13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090 Modules linked in:

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atm: clip: Se corrige un posible error de referencia nulo en to_atmarpd(). atmarpd está protegido por RTNL desde el commit f3a0592b37b8 ("[ATM]: clip provoca un bloqueo al cancelar el registro"). Sin embargo, esto no es suficiente, ya que to_atmarpd() se llama sin RTNL, especialmente clip_neigh_solicit() / neigh_ops->solicit() no se puede suspender. Además, atmarpd no depende de RTNL. Usemos un mutex privado y una RCU para proteger el acceso a atmarpd en to_atmarpd().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vsock: Se corrige la asignación de transporte transport_* TOCTOU que podría competir con la descarga del módulo. Se evita que new_transport se convierta en un puntero obsoleto. Esto también soluciona una llamada insegura en vsock_use_local_transport(); se añade una aserción lockdep. BUG: unable to handle page fault for address: fffffbfff8056000 Oops: Oops: 0000 [#1] SMP KASAN RIP: 0010:vsock_assign_transport+0x366/0x600 Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53