Vulnerabilidades

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: 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: mISDN: se corrige una posible pérdida de memoria en mISDN_register_device() Después de el commit 1fa5ae857bb1 ("núcleo del controlador: deshacerse de la matriz de cadenas bus_id del dispositivo de estructura"), el nombre del dispositivo se asigna dinámicamente, agregue put_device() para renunciar a la referencia, de modo que el nombre se pueda liberar en kobject_cleanup() cuando el refcount sea 0. Establezca la clase del dispositivo antes de put_device() para evitar el mensaje WARN de la función release() nula en device_release().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rose: Se corrige la desreferencia del puntero NULL en rose_send_frame() Syzkaller informó un problema: KASAN: null-ptr-deref en el rango [0x0000000000000380-0x0000000000000387] CPU: 0 PID: 4069 Comm: kworker/0:15 No contaminado 6.0.0-syzkaller-02734-g0326074ff465 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 22/09/2022 Cola de trabajo: rcu_gp srcu_invoke_callbacks RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101 Rastreo de llamadas: rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255 rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009 rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111 call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [en línea] __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790 __run_timers kernel/time/timer.c:1768 [en línea] run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803 __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571 [...] Activa la desreferencia de puntero nulo cuando se llama a 'neigh->dev->dev_addr' en rose_send_frame(). Es la primera vez que `neigh` aparece en rose_loopback_timer() como `rose_loopback_neigh', y `dev' en `rose_loopback_neigh' se inicializa como nullptr. Se corrigió con el commit 3b3fd068c56e3fbea30090859216a368398e39bf ("rose: Corregir la desreferencia de puntero nulo en rose_send_frame()"). Pero esto se introduce de nuevo con el commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8 ("rose: check NULL rose_loopback_neigh->loopback"). Lo solucionamos añadiendo una comprobación NULL en rose_transmit_clear_request(). Cuando el valor de "dev" en "neigh" es NULL, no respondemos a la solicitud y simplemente la borramos. syzkaller no proporciona reproducción, y yo proporciono una reproducción syz como: r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2) ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201}) r1 = syz_init_net_socket$rose(0xb, 0x5, 0x0) bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default, @null]}, 0x40) conectar$rosa(r1, &(0x7f0000000240)=@corto={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remoto={0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)

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: 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: 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: 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: ipvs: corrección de una advertencia en ip_vs_app_net_cleanup(). Durante la inicialización de ip_vs_app_net_init(), si no se crea el archivo ip_vs_app, la inicialización se realiza correctamente por defecto. Por lo tanto, el archivo ip_vs_app no se encuentra durante la eliminación en ip_vs_app_net_cleanup(). Esto provocará un error WRNING. La siguiente es la información de la pila: nombre 'ip_vs_app' ADVERTENCIA: CPU: 1 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: 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: 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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: L2CAP: corrección de use-after-free en l2cap_conn_del(). Cuando se invoca l2cap_recv_frame() para recibir datos y el CID es L2CAP_CID_A2MP, si el canal no existe, se crea uno. Sin embargo, una vez creado el canal, no se realiza la operación de retención. En este caso, el valor del recuento de referencias del canal es 1. Como resultado, tras la activación de hci_error_reset(), l2cap_conn_del() invoca la función de cierre de A2MP para liberar el canal. Entonces, l2cap_chan_unlock(chan) activará el problema de UAF. El proceso es el siguiente: Recibir datos: l2cap_data_channel() a2mp_channel_create() --->la referencia del canal es 2 l2cap_chan_put() --->la referencia del canal es 1 Evento desencadenador: hci_error_reset() hci_dev_do_close() ... l2cap_disconn_cfm() l2cap_conn_del() l2cap_chan_hold() --->la referencia del canal es 2 l2cap_chan_del() --->la referencia del canal es 1 a2mp_chan_close_cb() --->la referencia del canal es 0, liberar el canal l2cap_chan_unlock() --->UAF del canal El seguimiento de llamadas detallado es el siguiente: ERROR: KASAN: use-after-free en __mutex_unlock_slowpath+0xa6/0x5e0 Lectura de tamaño 8 en la dirección ffff8880160664b8 por la tarea kworker/u11:1/7593 Cola de trabajo: hci0 Rastreo de llamadas hci_error_reset: dump_stack_lvl+0xcd/0x134 print_report.cold+0x2ba/0x719 kasan_report+0xb1/0x1e0 kasan_check_range+0x140/0x190 __mutex_unlock_slowpath+0xa6/0x5e0 l2cap_conn_del+0x404/0x7b0 l2cap_disconn_cfm+0x8c/0xc0 hci_conn_hash_flush+0x11f/0x260 hci_dev_close_sync+0x5f5/0x11f0 hci_dev_do_close+0x2d/0x70 hci_error_reset+0x9e/0x140 process_one_work+0x98a/0x1620 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30 Allocated by task 7593: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0xa9/0xd0 l2cap_chan_create+0x40/0x930 amp_mgr_create+0x96/0x990 a2mp_channel_create+0x7d/0x150 l2cap_recv_frame+0x51b8/0x9a70 l2cap_recv_acldata+0xaa3/0xc00 hci_rx_work+0x702/0x1220 process_one_work+0x98a/0x1620 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30 Freed by task 7593: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0x20/0x30 ____kasan_slab_free+0x167/0x1c0 slab_free_freelist_hook+0x89/0x1c0 kfree+0xe2/0x580 l2cap_chan_put+0x22a/0x2d0 l2cap_conn_del+0x3fc/0x7b0 l2cap_disconn_cfm+0x8c/0xc0 hci_conn_hash_flush+0x11f/0x260 hci_dev_close_sync+0x5f5/0x11f0 hci_dev_do_close+0x2d/0x70 hci_error_reset+0x9e/0x140 process_one_work+0x98a/0x1620 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30 Last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0xbe/0xd0 call_rcu+0x99/0x740 netlink_release+0xe6a/0x1cf0 __sock_release+0xcd/0x280 sock_close+0x18/0x20 __fput+0x27c/0xa90 task_work_run+0xdd/0x1a0 exit_to_user_mode_prepare+0x23c/0x250 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x42/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Second to last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0xbe/0xd0 call_rcu+0x99/0x740 netlink_release+0xe6a/0x1cf0 __sock_release+0xcd/0x280 sock_close+0x18/0x20 __fput+0x27c/0xa90 task_work_run+0xdd/0x1a0 exit_to_user_mode_prepare+0x23c/0x250 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x42/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-mq: Se corrige kmemleak en blk_mq_init_allocated_queue Hay una kmemleak causada por modprobe null_blk.ko objeto no referenciado 0xffff8881acb1f000 (tamaño 1024): comm "modprobe", pid 836, jiffies 4294971190 (edad 27.068s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [<000000004a10c249>] kmalloc_node_trace+0x22/0x60 [<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350 [<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0 [<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440 [<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0 [<00000000d10c98c3>] 0xffffffffc450d69d [<00000000b9299f48>] 0xffffffffc4538392 [<0000000061c39ed6>] hacer_una_llamada_inicio+0xd0/0x4f0 [<00000000b389383b>] hacer_módulo_inicio+0x1a4/0x680 [<0000000087cf3542>] cargar_módulo+0x6249/0x7110 [<00000000beba61b8>] __hacer_módulo_finit_sys+0x140/0x200 [<00000000fdcfff51>] hacer_llamada_al_sistema_64+0x35/0x80 [<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Esto se debe a que q->ma_ops se establece en NULL antes de llamar a blk_release_queue. blk_mq_init_queue_data blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs para (i = 0; i < set->nr_hw_queues; i++) { old_hctx = xa_load(&q->hctx_table, i); si (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1] si (!old_hctx) break; xa_for_each_start(&q->hctx_table, j, hctx, j) blk_mq_exit_hctx(q, set, hctx, j); [2] if (!q->nr_hw_queues) [3] goto err_hctxs; err_exit: q->mq_ops = NULL; [4] blk_put_queue blk_release_queue if (queue_is_mq(q)) [5] blk_mq_release(q); [1]: blk_mq_alloc_and_init_hctx falló en i != 0. [2]: Los hctxs asignados por [1] se mueven a q->unused_hctx_list y se limpiarán en blk_mq_release. [3]: q->nr_hw_queues es 0. [4]: Establece q->mq_ops en NULL. [5]: queue_is_mq devuelve falso debido a [4]. No se llamará a blk_mq_release. Los hctxs en q->unused_hctx_list tienen fugas. Para solucionarlo, llame a blk_release_queue en la ruta de excepción.