Vulnerabilidades

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: 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: 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: netfilter: flowtable: arreglo de flujos atascados en la limpieza debido a trabajo pendiente Para limpiar la tabla de flujo cuando está libre, normalmente ocurre la siguiente secuencia en orden: 1) Se detiene el trabajo de gc_step para deshabilitar cualquier solicitud de estadísticas/del. 2) Todas las entradas de la tabla de flujo se establecen en estado de desmontaje. 3) Se ejecuta gc_step, que pondrá en cola el trabajo de del de HW para cada entrada de la tabla de flujo. 4) Se espera a que finalice el trabajo del del anterior (vaciado). 5) Se vuelve a ejecutar gc_step, eliminando todas las entradas de la tabla de flujo. 6) Se libera la tabla de flujo. Pero si una entrada de la tabla de flujo ya tiene estadísticas de HW pendientes o trabajo de adición de HW, el paso 3 no pondrá en cola el trabajo de del de HW (se omitirá), el paso 4 esperará a que finalicen las adiciones/estadísticas pendientes y el paso 5 pondrá en cola el trabajo de del de HW que podría ejecutarse después de liberar la tabla de flujo. Para solucionar lo anterior, este parche limpia el trabajo pendiente, luego establece el indicador de desmontaje en todos los flujos en la tabla de flujo y fuerza la ejecución de un recolector de basura para poner en cola el trabajo para eliminar los flujos del hardware, luego limpia este nuevo trabajo pendiente y (finalmente) fuerza la ejecución de otro recolector de basura para eliminar la entrada de la tabla de flujo del software. Rastreo de pila: [47773.882335] ERROR: KASAN: Use-After-Free en down_read+0x99/0x460 [47773.883634] Escritura de tamaño 8 en la dirección ffff888103b45aa8 por la tarea kworker/u20:6/543704 [47773.885634] CPU: 3 PID: 543704 Comm: kworker/u20:6 No contaminado 5.12.0-rc7+ #2 [47773.886745] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009) [47773.888438] Cola de trabajo: nf_ft_offload_del flow_offload_work_handler [nf_flow_table] [47773.889727] Rastreo de llamadas: [47773.890214] dump_stack+0xbb/0x107 [47773.890818] print_address_description.constprop.0+0x18/0x140 [47773.892990] kasan_report.cold+0x7c/0xd8 [47773.894459] kasan_check_range+0x145/0x1a0 [47773.895174] down_read+0x99/0x460 [47773.899706] nf_flow_offload_tuple+0x24f/0x3c0 [nf_flow_table] [47773.907137] flow_offload_work_handler+0x72d/0xbe0 [nf_flow_table] [47773.913372] process_one_work+0x8ac/0x14e0 [47773.921325] [47773.921325] Allocated by task 592159: [47773.922031] kasan_save_stack+0x1b/0x40 [47773.922730] __kasan_kmalloc+0x7a/0x90 [47773.923411] tcf_ct_flow_table_get+0x3cb/0x1230 [act_ct] [47773.924363] tcf_ct_init+0x71c/0x1156 [act_ct] [47773.925207] tcf_action_init_1+0x45b/0x700 [47773.925987] tcf_action_init+0x453/0x6b0 [47773.926692] tcf_exts_validate+0x3d0/0x600 [47773.927419] fl_change+0x757/0x4a51 [cls_flower] [47773.928227] tc_new_tfilter+0x89a/0x2070 [47773.936652] [47773.936652] Freed by task 543704: [47773.937303] kasan_save_stack+0x1b/0x40 [47773.938039] kasan_set_track+0x1c/0x30 [47773.938731] kasan_set_free_info+0x20/0x30 [47773.939467] __kasan_slab_free+0xe7/0x120 [47773.940194] slab_free_freelist_hook+0x86/0x190 [47773.941038] kfree+0xce/0x3a0 [47773.941644] tcf_ct_flow_table_cleanup_work Descripción del parche original y seguimiento de la pila por Paul Blakey.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_tproxy: restricción al gancho de preenrutamiento. TPROXY solo se permite desde el preenrutamiento, pero nft_tproxy no lo comprueba. Esto corrige un fallo (desreferencia nula) al usar tproxy desde la salida, por ejemplo.

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.

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: 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: 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: 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: mm/hugetlb: evitar la corrupción del mapeo de páginas en hugetlb_mcopy_atomic_pte. En el caso de MCOPY_ATOMIC_CONTINUE con un VMA no compartido, las páginas de la caché de páginas se instalan en los ptes. Sin embargo, se llama a hugepage_add_new_anon_rmap por error porque no son vm_shared. Esto corromperá el mapeo de páginas utilizado por el código de la caché de páginas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/mprotect: solo hace referencia a la página pfn de intercambio si coincide el tipo Yu Zhao informó un error después de el commit "mm/swap: Agregar swp_offset_pfn() para obtener PFN de la entrada de intercambio" agregó una verificación en swp_offset_pfn() para el tipo de intercambio [1]: ¡ERROR del kernel en include/linux/swapops.h:117! CPU: 46 PID: 5245 Com: EventManager_De Contaminado: GSOL 6.0.0-dbg-DEV #2 RIP: 0010:pfn_swap_entry_to_page+0x72/0xf0 Código: c6 48 8b 36 48 83 fe ff 74 53 48 01 d1 48 83 c1 08 48 8b 09 f6 c1 01 75 7b 66 90 48 89 c1 48 8b 09 f6 c1 01 74 74 5d c3 eb 9e <0f> 0b 48 ba ff ff ff ff 03 00 00 00 eb ae a9 ff 0f 00 00 75 13 48 RSP: 0018:ffffa59e73fabb80 EFLAGS: 00010282 RAX: 00000000ffffffe8 RBX: 0c00000000000000 RCX: ffffcd5440000000 RDX: 1ffffffffff7a80a RSI: 0000000000000000 RDI: 0c0000000000042b RBP: ffffa59e73fabb80 R08: ffff9965ca6e8bb8 R09: 0000000000000000 R10: ffffffffa5a2f62d R11: 0000030b372e9fff R12: ffff997b79db5738 R13: 000000000000042b R14: 0c0000000000042b R15: 1ffffffffff7a80a FS: 00007f549d1bb700(0000) GS:ffff99d3cf680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000440d035b3180 CR3: 0000002243176004 CR4: 00000000003706e0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: change_pte_range+0x36e/0x880 change_p4d_range+0x2e8/0x670 change_protection_range+0x14e/0x2c0 mprotect_fixup+0x1ee/0x330 do_mprotect_pkey+0x34c/0x440 __x64_sys_mprotect+0x1d/0x30 Se activa porque pfn_swap_entry_to_page() podría invocarse, por ejemplo, en una entrada de intercambio genuina. Para solucionarlo, invoque solo cuando se trate de una entrada de migración de escritura donde se use page*. [1] https://lore.kernel.org/lkml/CAOUHufaVC2Za-p8m0aiHw6YkheDcrO-C3wRGixwDS32VTS+k1w@mail.gmail.com/