Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4.0: Se corrige un problema de use-after-free en la función open() asincrónica Yang Erkun informa que cuando dos subprocesos abren archivos al mismo tiempo y se ven obligados a abortar antes de que se vea una respuesta, la llamada a nfs_release_seqid() en nfs4_opendata_free() puede dar como resultado un use-after-free del puntero a la tarea rpc inactiva del otro subproceso. La solución es garantizar que si la llamada RPC se aborta antes de que se complete la llamada a nfs_wait_on_sequence(), entonces debemos llamar a nfs_release_seqid() en nfs4_open_release() antes de que se libere la rpc_task.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-fabrics: se corrige el fallo del kernel al apagar el controlador La operación de mantenimiento de conexión de nvme, que se ejecuta a intervalos periódicos, podría colarse mientras se apaga un controlador de red. Esto puede provocar una ejecución entre la ruta del código de destrucción de la cola de administración del controlador de red (invocada mientras se apaga el controlador) y el despachador de cola hw/hctx llamado desde la operación de puesta en cola de solicitudes asincrónicas de mantenimiento de conexión de nvme. Esta ejecución podría provocar el bloqueo del kernel que se muestra a continuación: Rastreo de llamada: autoremove_wake_function+0x0/0xbc (no confiable) __blk_mq_sched_dispatch_requests+0x114/0x24c blk_mq_sched_dispatch_requests+0x44/0x84 blk_mq_run_hw_queue+0x140/0x220 nvme_keep_alive_work+0xc8/0x19c [nvme_core] process_one_work+0x200/0x4e0 worker_thread+0x340/0x504 kthread+0x138/0x140 start_kernel_thread+0x14/0x18 Al apagar el controlador de estructura, si la solicitud de mantenimiento de conexión de nvme se cuela, se eliminará. Luego se invoca la función nvme_keep_alive_end_io para gestionar el final de la operación keep-alive que disminuye el admin->q_usage_counter y, asumiendo que esta es la última/única solicitud en la cola de administración, entonces el admin->q_usage_counter se convierte en cero. Si eso sucede, entonces la operación de destrucción de cola blk-mq (blk_mq_destroy_queue()) que podría estar ejecutándose simultáneamente en otra CPU (ya que esta es la ruta del código de apagado del controlador) reenviaría el progreso y eliminaría la cola de administración. Entonces, ahora a partir de este punto en adelante no se supone que accedamos a los recursos de la cola de administración. Sin embargo, el problema aquí es que el hilo de keep-alive de nvme que ejecuta la operación de despacho de cola hw/hctx aún no ha terminado su trabajo y, por lo tanto, aún podría acceder potencialmente al recurso de la cola de administración mientras que la cola de administración ya se había eliminado y eso causa el bloqueo anterior. El fallo del kernel anterior es una regresión causada por los cambios implementados en el commit a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()"). Lo ideal sería detener el keep-alive antes de destruir la cola de administración y liberar el conjunto de etiquetas de administración para que no se introduzca durante la operación de apagado. Sin embargo, eliminamos la operación de detención de keep-alive del comienzo de la ruta del código de apagado del controlador en el commit a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()") y la agregamos bajo nvme_uninit_ctrl() que se ejecuta muy tarde en la ruta del código de apagado después de que se destruye la cola de administración y se elimina su conjunto de etiquetas. Por lo tanto, este cambio creó la posibilidad de que el keep-alive se introduzca e interfiera con la operación de apagado y cause el fallo del kernel observado. Para solucionar el fallo observado, decidimos mover nvme_stop_keep_alive() de nvme_uninit_ctrl() a nvme_remove_admin_tag_set(). Este cambio garantizaría que no avancemos el progreso ni eliminemos la cola de administración hasta que la operación de mantenimiento de la actividad finalice (si está en curso) o se cancele, y eso ayudaría a contener la condición de ejecución explicada anteriormente y, por lo tanto, evitar el fallo. Mover nvme_stop_keep_alive() a nvme_remove_admin_tag_set() en lugar de agregar nvme_stop_keep_alive() al comienzo de la ruta del código de apagado del controlador en nvme_stop_ctrl(), como era el caso antes de el commit a54a93d0e359 ("nvme: mover la operación de mantenimiento de la actividad de detención a nvme_uninit_ctrl()"), ayudaría a ahorrar un sitio de llamada de nvme_stop_keep_alive().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: sched: corregir el orden del ajuste de qlen Los cambios en sch->q.qlen en torno a qdisc_tree_reduce_backlog() deben realizarse _antes_ de una llamada a dicha función porque, de lo contrario, puede fallar en notificar a los qdisc principales cuando el secundario está a punto de vaciarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfs/blocklayout: No intente anular el registro de un dispositivo de bloque no válido Desde el commit d869da91cccb ("nfs/blocklayout: Reparar la anulación prematura del registro de una clave PR"), un desmontaje de un NFS con diseño SCSI habilitado pNFS puede anular la referencia de un block_device NULL en: bl_unregister_scsi+0x16/0xe0 [blocklayoutdriver] bl_free_device+0x70/0x80 [blocklayoutdriver] bl_free_deviceid_node+0x12/0x30 [blocklayoutdriver] nfs4_put_deviceid_node+0x60/0xc0 [nfsv4] nfs4_deviceid_purge_client+0x132/0x190 [nfsv4] Esto sucede porque, aunque pudimos crear el nfs4_deviceid_node, la búsqueda del dispositivo no pudo adjuntar el dispositivo de bloque a pnfs_block_dev. Si nunca encontramos un dispositivo de bloque para registrar, podemos evitar este caso con el indicador PNFS_BDEV_REGISTERED. Mueva el desreferenciador detrás de la prueba para el indicador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sunrpc: se corrige un problema de UAF causado por el socket TCP del kernel de sunrpc ERROR: KASAN: slab-use-after-free en tcp_write_timer_handler+0x156/0x3e0 Lectura de tamaño 1 en la dirección ffff888111f322cd por la tarea swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 No contaminado 6.12.0-rc4-dirty #7 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 Rastreo de llamadas: dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 asm_sysvec_apic_timer_interrupt+0x1a/0x20 DESCARGA: 0010:default_idle+0xf/0x20 Código: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242 RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196 RDX: 0000000000000000 RSI: 00000000000000000 RDI: ffffffff9f00590f RBP: 0000000000000000 R08: 00000000000000001 R09: ffffed102360835d R10: ffff88811b041aeb R11: 00000000000000001 R12: 00000000000000000 R13: fffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 llamada_inactiva_predeterminada+0x6b/0xa0 llamada_inactiva_cpuidle+0x1af/0x1f0 inactividad_real+0xbc/0x130 entrada_inicio_cpu+0x33/0x40 inicio_resto+0x11f/0x210 núcleo_inicio+0x39a/0x420 reserva_inicio_x86_64+0x18/0x30 núcleo_inicio_x86_64+0x97/0xa0 inicio_común_64+0x13e/0x141 Asignado por la tarea 595: pila_guardado_kasan+0x24/0x50 seguimiento_guardado_kasan+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Liberado por la tarea 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 Script de reproducción: mkdir -p /mnt/nfsshare mkdir -p /mnt/nfs/netns_1 mkfs.ext4 /dev/sdb mount /dev/sdb /mnt/nfsshare systemctl restart nfs-server chmod 777 /mnt/nfsshare exportfs -i -o rw,no_root_squash *:/mnt/nfsshare ip netns add netns_1 ip link add name veth_1_peer type veth peer veth_1 ifconfig veth_1_peer 11.11.0.254 up ip link set veth_1 netns netns_1 ip netns exec netns_1 ifconfig veth_1 11.11.0.1 ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \ --tcp-flags FIN FIN -j DROP (nota: En mi entorno, una operación DESTROY_CLIENTID siempre se envía inmediatamente, interrumpiendo la conexión tcp de nfs). ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \ 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1 ip netns del netns_1 La razón aquí es que el socket tcp en netns_1 (lado nfs) se ha apagado y cerrado (hecho en xs_destroy), pero el mensaje FIN (con ack) se descarta y el lado nfsd sigue enviando mensajes de retransmisión. Como resultado, cuando el sock tcp en netns_1 procesa el mensaje recibido, envía el mensaje (mensaje FIN) en la cola de envío y se restablece el temporizador tcp. Cuando se elimina el espacio de nombres de red, la estructura de red a la que accede la función del controlador del temporizador de tcp causa problemas. Para solucionar este problema, mantengamos netns refcnt para el socket de kernel tcp como se hizo en otros módulos. Este es un truco feo que se puede adaptar fácilmente a kernels anteriores. Seguiremos con una solución adecuada que limpie las interfaces, pero puede que no sea tan fácil adaptarla.

En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: sh: intc: Fix use-after-free bug in register_intc_controller() en la gestión de errores para esta función, d se libera sin quitarlo nunca de intc_list, lo que provocaría un use-after-free. Para solucionar esto, solo agreguémoslo a la lista después de que todo haya sido exitoso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block, bfq: reparar bfqq uaf en bfq_limit_depth() Establecer un nuevo bfqq asignado a bic o eliminar un bfqq liberado de bic están ambos protegidos por bfqd->lock, sin embargo bfq_limit_depth() está diferenciando bfqq de bic sin el bloqueo, esto puede llevar a UAF si el io_context es compartido por múltiples tareas. Por ejemplo, la prueba bfq con io_uring puede activar el siguiente UAF en v6.6: ====================================================================== ERROR: KASAN: slab-use-after-free en bfqq_group+0x15/0x50 Seguimiento de llamadas: dump_stack_lvl+0x47/0x80 print_address_description.constprop.0+0x66/0x300 print_report+0x3e/0x70 kasan_report+0xb4/0xf0 bfqq_group+0x15/0x50 bfqq_request_over_limit+0x130/0x9a0 bfq_limit_depth+0x1b5/0x480 __blk_mq_alloc_requests+0x2b5/0xa00 blk_mq_get_new_requests+0x11d/0x1d0 blk_mq_submit_bio+0x286/0xb00 send_bio_noacct_nocheck+0x331/0x400 __block_write_full_folio+0x3d0/0x640 writepage_cb+0x3b/0xc0 write_cache_pages+0x254/0x6c0 write_cache_pages+0x254/0x6c0 do_writepages+0x192/0x310 filemap_fdatawrite_wbc+0x95/0xc0 __filemap_fdatawrite_range+0x99/0xd0 Asignado por la tarea 808602: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x83/0x90 kmem_cache_alloc_node+0x1b1/0x6d0 bfq_get_queue+0x138/0xfa0 bfq_get_bfqq_handle_split+0xe3/0x2c0 bfq_init_rq+0x196/0xbb0 bfq_insert_request.isra.0+0xb5/0x480 bfq_insert_requests+0x156/0x180 blk_mq_insert_request+0x15d/0x440 blk_mq_submit_bio+0x8a4/0xb00 send_bio_noacct_nocheck+0x331/0x400 __blkdev_direct_IO_async+0x2dd/0x330 blkdev_write_iter+0x39a/0x450 io_write+0x22a/0x840 io_issue_sqe+0x87/0x300 io_wq_submit_work+0xeb/0x390 io_worker_handle_work+0x24d/0x550 io_wq_worker+0x27f/0x6c0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x1b/0x30 Liberado por la tarea 808589: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40 __kasan_slab_free+0x126/0x1b0 kmem_cache_free+0x10c/0x750 bfq_put_queue+0x2dd/0x770 __bfq_insert_request.isra.0+0x155/0x7a0 bfq_insert_request.isra.0+0x122/0x480 bfq_insert_requests+0x156/0x180 blk_mq_dispatch_plug_list+0x528/0x7e0 blk_mq_flush_plug_list.part.0+0xe5/0x590 __blk_flush_plug+0x3b/0x90 blk_finish_plug+0x40/0x60 do_writepages+0x19d/0x310 filemap_fdatawrite_wbc+0x95/0xc0 Solucione el problema protegiendo bic_to_bfqq() con bfqd->lock.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sh: cpuinfo: Se corrige una advertencia para CONFIG_CPUMASK_OFFSTACK Cuando se seleccionan CONFIG_CPUMASK_OFFSTACK y CONFIG_DEBUG_PER_CPU_MAPS, cpu_max_bits_warn() genera una advertencia de tiempo de ejecución similar a la siguiente cuando se muestra /proc/cpuinfo. Corrija esto utilizando nr_cpu_ids (el límite de tiempo de ejecución) en lugar de NR_CPUS para iterar las CPU. [ 3.052463] ------------[ cortar aquí ]------------ [ 3.059679] ADVERTENCIA: CPU: 3 PID: 1 en include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Módulos vinculados en: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd No contaminado 5.19-rc5+ #1052 [ 3.099465] Pila: 9000000100157b08 9000000000f18530 900000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 90000010021de80 90000000101c890 [ 3.138056] 000000000000000 0000000000000000 0000000000000000 0000000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 000000000000004 900000000ef7430 000000000000000 [ 3.167012] 0000000000000009 0000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Seguimiento de llamadas: [ 3.203941] [<90000000002086d8>] mostrar_pila+0x38/0x14c [ 3.210666] [<9000000000cf846c>] nivel_pila_volcado+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] mostrar_info_cpu+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ fin del seguimiento 8b484262b4b8c24c ]---

Una vulnerabilidad de DNS Security feature de Palo Alto Networks PAN-OS software permite que un atacante no autenticado envíe un paquete malicioso a través del plano de datos del firewall que reinicia el firewall. Los intentos repetidos de activar esta condición harán que el firewall entre en modo de mantenimiento.

Existe una vulnerabilidad de desbordamiento de pila en algunos teléfonos inteligentes Huawei. Un atacante puede crear un paquete específico para explotar esta vulnerabilidad. Debido a una verificación insuficiente, esto podría aprovecharse para alterar la información y afectar la disponibilidad. (ID de vulnerabilidad: HWPSIRT-2019-11030) A esta vulnerabilidad se le ha asignado un ID de vulnerabilidad y exposición común (CVE): CVE-2020-9253.

Existe una vulnerabilidad de diseño de interfaz incorrecta en un producto de Huawei. La interfaz de un módulo del producto afectado no gestiona correctamente algunas operaciones. Los atacantes pueden aprovechar esta vulnerabilidad para realizar operaciones maliciosas que pongan en peligro el servicio del módulo. (ID de vulnerabilidad: HWPSIRT-2020-05010) A esta vulnerabilidad se le ha asignado un ID de vulnerabilidad y exposición común (CVE): CVE-2020-9236.

Existe una vulnerabilidad de escalada de privilegios en el producto Huawei FusionCompute. Debido a la verificación insuficiente de archivos específicos que deben deserializarse, los atacantes locales pueden aprovechar esta vulnerabilidad para elevar los permisos. (ID de vulnerabilidad: HWPSIRT-2020-05241) A esta vulnerabilidad se le ha asignado un ID de vulnerabilidad y exposición común (CVE): CVE-2020-9222.