Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de corrupción de caché de espacio y posibles asignaciones dobles. Al probar space_cache v2 en un conjunto grande de máquinas, encontramos algunos síntomas: 1. Errores "no se puede agregar espacio libre :-17" (EEXIST). 2. Falta de información de espacio libre, a veces detectados con el error "falta información de espacio libre para X". 3. Espacio contabilizado dos veces: rangos asignados en el árbol de extensiones y marcados como libres en dicho árbol, rangos marcados como asignados dos veces en el árbol de extensiones o rangos marcados como libres dos veces en dicho árbol. Si estos últimos se almacenaban en el disco, el siguiente reinicio generaría el error BUG_ON() en add_new_free_space(). 4. En algunos hosts sin corrupción en disco ni mensajes de error, la caché de espacio en memoria (volcada con drgn) no coincidía con el árbol de espacio libre. Todos estos síntomas tienen la misma causa subyacente: una competencia entre el almacenamiento en caché del espacio libre de un grupo de bloques y su devolución a la caché de espacio en memoria para las extensiones fijadas provoca la duplicación de un rango libre en la caché de espacio. Esta competencia se produce cuando se almacena en caché el espacio libre del árbol de espacio libre (space_cache=v2) o del árbol de extensiones (nospace_cache, o space_cache=v1 si es necesario regenerar la caché). Se supone que struct btrfs_block_group::last_byte_to_unpin y struct btrfs_block_group::progress protegen contra esta competencia, pero el commit d0c2f4fa555e ("btrfs: hacer que las sincronizaciones simultáneas esperen menos al esperar el commit de una transacción") interrumpió esto sutilmente al permitir que varias transacciones desanclaran extensiones simultáneamente. Específicamente, la ejecución es la siguiente: 1. Se elimina una extensión de un grupo de bloques no almacenados en caché en la transacción A. 2. Se llama a btrfs_commit_transaction() para la transacción A. 3. btrfs_run_delayed_refs() -> __btrfs_free_extent() ejecuta la referencia retrasada para la extensión eliminada. 4. __btrfs_free_extent() -> do_free_extent_accounting() -> add_to_free_space_tree() agrega la extensión eliminada nuevamente al árbol de espacio libre. 5. do_free_extent_accounting() -> btrfs_update_block_group() -> btrfs_cache_block_group() pone en cola el grupo de bloques para almacenar en caché. block_group->progress se establece en block_group->start. 6. btrfs_commit_transaction() para la transacción A llama a switch_commit_roots(). Establece block_group->last_byte_to_unpin en block_group->progress, que es block_group->start porque el grupo de bloques aún no se ha almacenado en caché. 7. El hilo de caché accede a nuestro grupo de bloques. Dado que las raíces de las confirmaciones ya se han cambiado, load_free_space_tree() detecta la extensión eliminada como libre y la añade a la caché de espacio. Finaliza el almacenamiento en caché y establece block_group->progress en U64_MAX. 8. btrfs_commit_transaction() avanza la transacción A a TRANS_STATE_SUPER_COMMITTED. 9. fsync llama a btrfs_commit_transaction() para la transacción B. Dado que la transacción A ya está en TRANS_STATE_SUPER_COMMITTED y el commit es para fsync, avanza. 10. btrfs_commit_transaction() para la transacción B llama a switch_commit_roots(). Esta vez, el grupo de bloques ya se ha almacenado en caché, por lo que establece block_group->last_byte_to_unpin en U64_MAX. 11. btrfs_commit_transaction() para la transacción A llama a btrfs_finish_extent_commit(), que llama a unpin_extent_range() para la extensión eliminada. Ve que last_byte_to_unpin está establecido en U64_MAX (¡por la transacción B!), por lo que vuelve a añadir la extensión eliminada a la caché de espacio. Esto explica todos nuestros síntomas anteriores: * Si la secuencia de eventos es exactamente la descrita anteriormente, cuando se vuelve a añadir el espacio libre en el paso 11, fallará con EEXIST. * ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Arreglar el bloqueo en sendmsg de rxrpc Corrige tres errores en la implementación de sendmsg de rxrpc: (1) rxrpc_new_client_call() debería liberar el bloqueo del socket al devolver un error de rxrpc_get_call_slot(). (2) rxrpc_wait_for_tx_window_intr() retornará sin el mutex de llamada retenido en caso de que seamos interrumpidos por una señal mientras esperamos espacio de transmisión en el socket o volvemos a bloquear el mutex de llamada posteriormente. Corrige esto mediante: (a) mover el desbloqueo/bloqueo del mutex de llamada hasta rxrpc_send_data() de modo que el bloqueo no se mantenga alrededor de todo rxrpc_wait_for_tx_window*() y (b) indicar a los llamadores superiores si retornamos con el bloqueo eliminado. Tenga en cuenta que esto significa que recvmsg() no se bloqueará en esta llamada mientras esperamos. (3) Después de eliminar y recuperar el mutex de llamada, rxrpc_send_data() debe volver a verificar el estado del búfer tx_pending y la comprobación de tx_total_len en caso de que hayamos utilizado otro sendmsg() en la misma llamada. Pensándolo bien, podría tener sentido tener bloqueos diferentes para sendmsg() y recvmsg(). Probablemente no sea necesario que recvmsg() espere a sendmsg(). Esto significa que recvmsg() puede devolver MSG_EOR, lo que indica que una llamada está inactiva antes de que un sendmsg() a esa llamada regrese, pero eso puede ocurrir de todos modos. Sin la corrección (2), se puede inducir algo como lo siguiente: ¡ADVERTENCIA: se detectó un saldo de desbloqueo incorrecto! 5.16.0-rc6-syzkaller #0 No contaminado ------------------------------------- syz-executor011/3597 está intentando liberar el bloqueo (&call->user_mutex) en: [] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 ¡pero no hay más bloqueos para liberar! Otra información que podría ayudarnos a depurar esto: syz-executor011/3597 no tiene bloqueos. ... Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_unlock_imbalance_bug include/trace/events/lock.h:58 [en línea] __lock_release kernel/locking/lockdep.c:5306 [en línea] lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657 __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900 rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561 sock_sendmsg_nosec net/socket.c:704 [en línea] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae [Gracias a Hawkins Jiawei y Khalid Masum por sus intentos de solucionar este problema]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: lantiq_xrx200: restaurar el búfer si falla la asignación de memoria. En caso de fallo en la asignación de memoria, se almacena una dirección de búfer no válida. Al volver a utilizar este descriptor, el sistema entra en pánico en la función build_skb() al acceder a la memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige una posible pérdida de memoria en btrfs_get_dev_args_from_path(). En btrfs_get_dev_args_from_path(), btrfs_get_bdev_and_sb() puede fallar si la ruta no es válida. En este caso, btrfs_get_dev_args_from_path() retorna directamente sin liberar los argumentos args->uuid y args->fsid asignados previamente, lo que provoca una pérdida de memoria. Para corregir estas posibles pérdidas, cuando btrfs_get_bdev_and_sb() falla, se llama a btrfs_put_dev_args_from_path() para limpiar la memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: writeback: evitar el Use-After-Free tras retirar un dispositivo. Al retirar un disco, se llama a bdi_unregister para detener la escritura diferida y esperar a que se complete el trabajo retrasado asociado. Sin embargo, wb_inode_writeback_end() puede programar la estimación de ancho de banda dwork después de que esto se haya completado, lo que puede provocar que el temporizador intente acceder al bdi_writeback recién liberado. Para solucionar esto, verifique si bdi_writeback está activo, de forma similar a cuando se programa la escritura diferida. Dado que esto requiere wb->work_lock y wb_inode_writeback_end() puede ser llamado desde una interrupción, cambie wb->work_lock a un bloqueo irqsafe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bootmem: eliminar las páginas vmemmap de kmemleak en put_page_bootmem. Las páginas vmemmap están marcadas por kmemleak cuando se asignan desde memblock. Elimínelas de kmemleak al liberar la página. De lo contrario, al reutilizar la página, kmemleak podría informar dicho error y dejar de funcionar. kmemleak: No se puede insertar 0xffff98fb6eab3d40 en el árbol de búsqueda de objetos (se superpone a los existentes) kmemleak: Detector de fugas de memoria del kernel deshabilitado kmemleak: Objeto 0xffff98fb6be00000 (tamaño 335544320): kmemleak: comm "swapper", pid 0, jiffies 4294892296 kmemleak: min_count = 0 kmemleak: count = 0 kmemleak: flags = 0x1 kmemleak: checksum = 0 kmemleak: backtrace:

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder_alloc: añade llamadas mmap_lock faltantes al usar el VMA. Se toma mmap_read_lock() al usar el VMA en binder_alloc_print_pages() y al buscar un VMA en binder_alloc_new_buf_locked(). Cabe destacar que binder_alloc_new_buf_locked() elimina el bloqueo de lectura del VMA tras verificar la existencia de un VMA, pero puede volver a tomarse en una fase más profunda de la pila de llamadas si es necesario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390: se corrige la doble liberación de los bloques de control de instrumentación de GS y RI en el fallo de fork() Los punteros para los bloques de control de instrumentación de almacenamiento protegido y tiempo de ejecución se almacenan en el thread_struct de la tarea asociada. Estos punteros se copian inicialmente en fork() mediante arch_dup_task_struct() y luego se borran mediante copy_thread() antes de que fork() regrese. Si fork() falla después del dup de la tarea inicial y antes de copy_thread(), la tarea recién asignada y la memoria thread_struct asociada se liberan mediante free_task() -> arch_release_task_struct(). Esto resulta en una doble liberación de las estructuras de información de almacenamiento protegido y tiempo de ejecución porque los campos en la tarea fallida todavía hacen referencia a la memoria asociada con la tarea de origen. Este problema puede manifestarse como un BUG_ON() en set_freepointer() (con CONFIG_SLAB_FREELIST_HARDENED habilitado) o un error de KASAN (si está habilitado) al ejecutar pruebas de fuzzing de llamadas al sistema de Trinity en s390x. Para evitar este problema, borre los campos de puntero asociados en arch_dup_task_struct() inmediatamente después de copiar la nueva tarea. Tenga en cuenta que el indicador RI permanece borrado en copy_thread() porque reside en la memoria de la pila de subprocesos, donde se copia la información de la pila.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen/privcmd: corrección del error de salida de privcmd_ioctl_dm_op(). La salida de error de privcmd_ioctl_dm_op() está llamando a unlock_pages() potencialmente con páginas NULL, lo que lleva a una desreferencia NULL. Además, lock_pages() no comprueba si pin_user_pages_fast() ha sido completamente exitoso, lo que resulta en que potencialmente no se bloqueen todas las páginas en la memoria. Esto podría resultar en fallos esporádicos al usar la memoria relacionada en modo de usuario. Corrija todo esto llamando a unlock_pages() siempre con el número real de páginas ancladas, que será cero en caso de que pages sea NULL, y comprobando que el número de páginas ancladas por pin_user_pages_fast() coincida con el número esperado de páginas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: llamada a __md_stop_writes en md_stop. En el enlace [1], podemos ver que raid1d se ejecutaba incluso después de la ruta raid_dtr -> md_stop -> __md_stop. Primero detengamos la escritura en el destructor para alinearla con el comando md-raid normal y solucionar el problema de KASAN. [1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: storvsc: Eliminar WQ_MEM_RECLAIM de storvsc_error_wq. La cola de trabajo storvsc_error_wq no debe marcarse como WQ_MEM_RECLAIM, ya que no necesita avanzar bajo presión de memoria. Marcar esta cola de trabajo como WQ_MEM_RECLAIM puede causar un bloqueo al vaciar una cola de trabajo que no sea WQ_MEM_RECLAIM. En el estado actual, provoca la siguiente advertencia: [ 14.506347] ------------[ cortar aquí ]------------ [ 14.506354] cola de trabajo: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun se está vaciando !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn [ 14.506360] ADVERTENCIA: CPU: 0 PID: 8 en <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130 [ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 No contaminado 5.4.0-1086-azure #91~18.04.1-Ubuntu [ 14.506391] Nombre del hardware: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI versión v4.1 09/05/2022 [ 14.506393] Cola de trabajo: storvsc_error_wq_0 storvsc_remove_lun [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 <-snip-> [ 14.506408] Seguimiento de llamadas: [ 14.506412] __flush_work+0xf1/0x1c0 [ 14.506414] __cancel_work_timer+0x12f/0x1b0 [ 14.506417] ? kernfs_put+0xf0/0x190 [ 14.506418] cancel_delayed_work_sync+0x13/0x20 [ 14.506420] disk_block_events+0x78/0x80 [ 14.506421] del_gendisk+0x3d/0x2f0 [ 14.506423] sr_remove+0x28/0x70 [ 14.506427] device_release_driver_internal+0xef/0x1c0 [ 14.506428] device_release_driver+0x12/0x20 [ 14.506429] bus_remove_device+0xe1/0x150 [ 14.506431] device_del+0x167/0x380 [ 14.506432] __scsi_remove_device+0x11d/0x150 [ 14.506433] scsi_remove_device+0x26/0x40 [ 14.506434] storvsc_remove_lun+0x40/0x60 [ 14.506436] process_one_work+0x209/0x400 [ 14.506437] worker_thread+0x34/0x400 [ 14.506439] kthread+0x121/0x140 [ 14.506440] ? process_one_work+0x400/0x400 [ 14.506441] ? kthread_park+0x90/0x90 [ 14.506443] ret_from_fork+0x35/0x40 [ 14.506445] ---[ fin de seguimiento 2d9633159fdc6ee7 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: No use tnum_range en la comprobación del rango de matriz para los descriptores de poke Hsin-Wei informó un splat de KASAN activado por su fuzzer de tiempo de ejecución BPF que se basa en un syzkaller personalizado: ERROR: KASAN: slab-out-of-bounds en bpf_int_jit_compile+0x1257/0x13f0 Lectura de tamaño 8 en la dirección ffff888004e90b58 por la tarea syz-executor.0/1489 CPU: 1 PID: 1489 Comm: syz-executor.0 No contaminado 5.19.0 #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x9c/0xc9 print_address_description.constprop.0+0x1f/0x1f0 ? bpf_int_jit_compile+0x1257/0x13f0 kasan_report.cold+0xeb/0x197 ? kvmalloc_node+0x170/0x200 ? bpf_int_jit_compile+0x1257/0x13f0 bpf_int_jit_compile+0x1257/0x13f0 ? arch_prepare_bpf_dispatcher+0xd0/0xd0 ? rcu_read_lock_sched_held+0x43/0x70 bpf_prog_select_runtime+0x3e8/0x640 ? bpf_obj_name_cpy+0x149/0x1b0 bpf_prog_load+0x102f/0x2220 ? __bpf_prog_put.constprop.0+0x220/0x220 ? find_held_lock+0x2c/0x110 ? __might_fault+0xd6/0x180 ? lock_downgrade+0x6e0/0x6e0 ? lock_is_held_type+0xa6/0x120 ? __might_fault+0x147/0x180 __sys_bpf+0x137b/0x6070 ? bpf_perf_link_attach+0x530/0x530 ? new_sync_read+0x600/0x600 ? __fget_files+0x255/0x450 ? lock_downgrade+0x6e0/0x6e0 ? fput+0x30/0x1a0 ? ksys_write+0x1a8/0x260 __x64_sys_bpf+0x7a/0xc0 ? syscall_enter_from_user_mode+0x21/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f917c4e2c2d El problema aquí es que un rango de tnum_range(0, map->max_entries - 1) tiene una capacidad limitada para representar el rango estrecho concreto con el tnum como el conjunto de estados resultantes de value + mask puede resultar en un superconjunto del rango real deseado, y como tal una comprobación tnum_in(range, reg->var_off) puede dar como resultado verdadero cuando no debería, por ejemplo tnum_range(0, 2) daría como resultado 00XX -> v = 0000, m = 0011 de modo que el conjunto deseado de {0, 1, 2} está representado aquí por un superconjunto menos preciso de {0, 1, 2, 3}. Como el registro es un escalar constante, simplemente use el valor concreto reg->var_off.value para la verificación del índice superior.