Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hns: Se solucionó el problema del puntero nulo en free_mr_init(). La captura de bloqueo ocurre en un escenario concurrente, lo que resulta en la sobreexposición a un puntero nulo. Se debe inicializar mutex_init() antes de usar el bloqueo. No se puede gestionar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000000 Rastreo de llamadas: __mutex_lock.constprop.0+0xd0/0x5c0 __mutex_lock_slowpath+0x1c/0x2c mutex_lock+0x44/0x50 free_mr_send_cmd_to_hw+0x7c/0x1c0 [hns_roce_hw_v2] hns_roce_v2_dereg_mr+0x30/0x40 [hns_roce_hw_v2] hns_roce_dereg_mr+0x4c/0x130 [hns_roce_hw_v2] ib_dereg_mr_user+0x54/0x124 uverbs_free_mr+0x24/0x30 destroy_hw_idr_uobject+0x38/0x74 uverbs_destroy_uobject+0x48/0x1c4 uobj_destroy+0x74/0xcc ib_uverbs_cmd_verbs+0x368/0xbb0 ib_uverbs_ioctl+0xec/0x1a4 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x58/0x190 do_el0_svc+0x30/0x90 el0_svc+0x2c/0xb4 el0t_64_sync_handler+0x1a4/0x1b0 el0t_64_sync+0x19c/0x1a0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipvs: corrección de una ADVERTENCIA en __ip_vs_cleanup_batch(). Durante la inicialización de ip_vs_conn_net_init(), si no se crea el archivo ip_vs_conn o ip_vs_conn_sync, la inicialización se realiza correctamente por defecto. Por lo tanto, no se encuentra el archivo ip_vs_conn o ip_vs_conn_sync durante la eliminación. La siguiente es la información de la pila: nombre 'ip_vs_conn_sync' ADVERTENCIA: CPU: 3 PID: 9 en fs/proc/generic.c:712 remove_proc_entry+0x389/0x460 Módulos vinculados en: Cola de trabajo: netns cleanup_net RIP: 0010:remove_proc_entry+0x389/0x460 Seguimiento de llamadas: __ip_vs_cleanup_batch+0x7d/0x120 ops_exit_list+0x125/0x170 cleanup_net+0x4ea/0xb00 process_one_work+0x9bf/0x1710 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: liberación del objeto de regla de flujo desde la ruta de confirmación. No es necesario posponer esto hasta la ruta de liberación de la confirmación, ya que ningún paquete pasa por este objeto; solo se accede a él desde el plano de control. Esto ayudó a descubrir el UAF activado por ejecuciones con el notificador netlink.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: el notificador netlink podría acelerar la liberación de objetos. La ruta de liberación de confirmación se invoca mediante call_rcu y se ejecuta sin bloqueo para liberar los objetos después del período de gracia de rcu. El controlador del notificador netlink podría ganar la ejecución para eliminar objetos de la ruta de liberación de confirmación a los que el contexto de la transacción aún hace referencia. Se debe llamar a rcu_barrier() para garantizar que las devoluciones de llamada rcu pendientes se ejecuten por completo si la lista de transacciones a destruir no está vacía.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: sched: Se corrige el use after free en red_enqueue(). No podemos volver a usar "skb" después de pasarlo a qdisc_enqueue(). Esto es prácticamente idéntico a el commit 2f09707d0c97 ("sch_sfb: También se almacena la longitud de skb antes de llamar a la cola secundaria").

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: nfcmrvl: Se corrige una posible fuga de memoria en nfcmrvl_i2c_nci_send(). nfcmrvl_i2c_nci_send() será llamado por nfcmrvl_nci_send(), y skb debería liberarse en nfcmrvl_i2c_nci_send(). Sin embargo, nfcmrvl_nci_send() solo liberará skb cuando i2c_master_send() devuelva >=0, lo que significa que skb sufrirá fugas de memoria si i2c_master_send() falla. Skb se libera independientemente de si i2c_master_send() tiene éxito.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: nxp-nci: Se corrige una posible fuga de memoria en nxp_nci_send(). nxp_nci_send() llamará a nxp_nci_i2c_write() y solo liberará skb cuando nxp_nci_i2c_write() falle. Sin embargo, incluso si la ejecución de nxp_nci_i2c_write() tiene éxito, skb no se liberará en nxp_nci_i2c_write(). Como resultado, skb sufrirá una fuga de memoria. nxp_nci_send() también debería liberar skb cuando nxp_nci_i2c_write() tenga éxito.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: L2CAP: Se corrige eluse-after-free causado por l2cap_reassemble_sdu. Se corrige la condición de ejecución entre los dos flujos que se ejecutan en paralelo: 1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) -> __sock_queue_rcv_skb. 2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram. Un SKB puede ser puesto en cola por el primer flujo e inmediatamente desencolado y liberado por el segundo flujo; por lo tanto, quienes llaman a l2cap_reassemble_sdu no pueden usar el SKB después del retorno de la función. Sin embargo, en algunos lugares, se continúa accediendo a la estructura l2cap_ctrl, que reside en el CB de la SKB, durante un breve periodo después del retorno de l2cap_reassemble_sdu, lo que genera una condición de use-after-free (el seguimiento de la pila se encuentra a continuación; los números de línea corresponden al kernel 5.19.8). Para solucionarlo, mantenga una copia local de la estructura l2cap_ctrl. ERROR: KASAN: use-after-free en l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth Lectura de tamaño 1 en la dirección ffff88812025f2f0 por la tarea kworker/u17:3/43169 Cola de trabajo: hci0 hci_rx_work [bluetooth] Rastreo de llamadas: dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429) ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493) ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth ret_from_fork (arch/x86/entry/entry_64.S:306) Allocated by task 43169: kasan_save_stack (mm/kasan/common.c:39) __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293) __alloc_skb (net/core/skbuff.c:414) l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth process_one_work (kernel/workqueue.c:2289) worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437) kthread (kernel/kthread.c:376) ret_from_fork (arch/x86/entry/entry_64.S:306) Freed by task 27920: kasan_save_stack (mm/kasan/common.c:39) kasan_set_track (mm/kasan/common.c:45) kasan_set_free_info (mm/kasan/generic.c:372) ____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328) slab_free_freelist_hook (mm/slub.c:1780) kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553) skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323) bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth sock_read_iter (net/socket.c:1087) new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401) vfs_read (fs/read_write.c:482) ksys_read (fs/read_write.c:620) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: ipset: aplicar el límite documentado para evitar la asignación de grandes cantidades de memoria. Daniel Xu informó que el tipo hash:net,iface del subsistema ipset no limita la adición de la misma red con diferentes interfaces a un conjunto, lo que puede provocar un uso excesivo de memoria o fallos de asignación. El reproductor rápido es: $ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0 $ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; hecho El backtrace cuando vmalloc falla: [Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages <...> [Tue Oct 25 00:13:08 2022] Call Trace: [Tue Oct 25 00:13:08 2022] [Tue Oct 25 00:13:08 2022] dump_stack_lvl+0x48/0x60 [Tue Oct 25 00:13:08 2022] warn_alloc+0x155/0x180 [Tue Oct 25 00:13:08 2022] __vmalloc_node_range+0x72a/0x760 [Tue Oct 25 00:13:08 2022] ? hash_netiface4_add+0x7c0/0xb20 [Tue Oct 25 00:13:08 2022] ? __kmalloc_large_node+0x4a/0x90 [Tue Oct 25 00:13:08 2022] kvmalloc_node+0xa6/0xd0 [Tue Oct 25 00:13:08 2022] ? hash_netiface4_resize+0x99/0x710 <...> La solución es aplicar el límite documentado en la página de manual de ipset(8): > La restricción interna del tipo de conjunto hash:net,iface es que el mismo prefijo de red no se puede almacenar con más de 64 interfaces diferentes en un solo conjunto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrigen fugas de ulist en las rutas de error de las autopruebas de qgroup. En las autopruebas de qgroup test_no_shared_qgroup() y test_multiple_refs(), si no se añade la referencia del árbol, se elimina el elemento de extensión o se elimina la referencia de extensión, se regresa de la función de prueba sin liberar la ulist "old_roots" asignada por las llamadas anteriores a btrfs_find_all_roots(). Se puede solucionar llamando a ulist_free() antes de regresar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de fuga de lista de inodos durante el recorrido de backref en find_parent_nodes() Durante el recorrido de backref, en find_parent_nodes(), si estamos tratando con una extensión de datos y obtenemos un error al resolver los backrefs indirectos, en resolve_indirect_refs(), o en el bucle while que itera sobre los refs en el rbtree de refs directos, terminamos filtrando las listas de inodos adjuntas a los refs directos que tenemos en el rbtree de refs directos que aún no se agregaron a la ulist de refs pasada como argumento a find_parent_nodes(). Dado que aún no se agregaron a la ulist de refs y prelim_release() no libera las listas, en caso de error, el llamador solo puede liberar las listas adjuntas a los refs que se agregaron a la ulist de refs, todas las referencias restantes obtienen sus listas de inodos nunca liberadas, por lo tanto, filtran su memoria. Para solucionar este problema, haga que prelim_release() siempre libere cualquier lista de inodos adjunta a cada referencia encontrada en el rbtree y que find_parent_nodes() establezca la lista de inodos de la referencia en NULL una vez que transfiera la propiedad de la lista de inodos a una referencia agregada a la lista de referencias pasada a find_parent_nodes().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de fuga de lista de inodos durante el recorrido de backref en resolve_indirect_refs() Durante el recorrido de backref, en resolve_indirect_refs(), si obtenemos un error saltamos a la etiqueta 'out' y llamamos a ulist_free() en la ulist 'parents', que libera todos los elementos en la ulist - sin embargo, eso no libera ninguna lista de inodos que pueda estar adjunta a elementos, a través del campo 'aux' de un nodo ulist, por lo que terminamos filtrando listas si tenemos alguna adjunta a los unodes. Arregle esto llamando a free_leaf_list() en lugar de ulist_free() cuando salimos de resolve_indirect_refs(). La función estática free_leaf_list() se mueve hacia arriba para que esto sea posible y se simplifica ligeramente eliminando código innecesario.