Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: mpc52xx: Agregar cancel_work_sync antes de eliminar el módulo Si eliminamos el módulo que llamará a mpc52xx_spi_remove, liberará 'ms' a través de spi_unregister_controller. mientras que se utilizará el trabajo ms->work. La secuencia de operaciones que puede provocar un error de UAF. Arréglelo asegurándose de que el trabajo se cancele antes de continuar con la desinfección en mpc52xx_spi_remove.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: stackdepot: se corrige stack_depot_save_flags() en el contexto NMI Según la documentación, se suponía que stack_depot_save_flags() se podía usar desde el contexto NMI si STACK_DEPOT_FLAG_CAN_ALLOC no está configurado. Sin embargo, aún intentaría tomar el pool_lock en un intento de guardar un seguimiento de pila en el pool actual (si hay espacio disponible). Esto podría resultar en un bloqueo si se gestiona un NMI mientras pool_lock ya está retenido. Para evitar el bloqueo, solo intente tomar el bloqueo en el contexto NMI y abandone si no tiene éxito. La documentación se corrige para transmitir esto claramente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: comprobar v2_ext_offset/eid_cnt/ism_gid_cnt al recibir un mensaje de propuesta Al recibir un mensaje de propuesta en el servidor, los campos v2_ext_offset/eid_cnt/ism_gid_cnt en el mensaje de propuesta son del cliente remoto y no se puede confiar plenamente en ellos. Especialmente el campo v2_ext_offset, una vez que se excede el valor máximo, existe la posibilidad de acceder a una dirección incorrecta y puede producirse un bloqueo. Este parche comprueba los campos v2_ext_offset/eid_cnt/ism_gid_cnt antes de usarlos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-rdma: anular la desactivación de admin_q antes de destruirlo El kernel se bloqueará al destruir admin_q mientras creamos un control fallido, como el siguiente calltrace: PID: 23644 TAREA: ff2d52b40f439fc0 CPU: 2 COMANDO: "nvme" #0 [ff61d23de260fb78] __schedule en ffffffff8323bc15 #1 [ff61d23de260fc08] schedule en ffffffff8323c014 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait en ffffffff82a3dba1 #3 [ff61d23de260fc78] blk_freeze_queue en ffffffff82a4113a #4 [ff61d23de260fc90] blk_cleanup_queue en ffffffff82a33006 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue en ffffffffc12686ce #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl en ffffffffc1268ced #7 [ff61d23de260fd28] nvme_rdma_create_ctrl en ffffffffc126919b #8 [ff61d23de260fd68] nvmf_dev_write en ffffffffc024f362 #9 [ff61d23de260fe38] vfs_write en ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 00000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b Esto se debe a que hemos silenciado admi_q antes de cancelar solicitudes, pero olvidamos reactivarlo antes de destruirlo, como resultado no podemos drenar las solicitudes pendientes y nos quedamos colgados en blk_mq_freeze_queue_wait() para siempre. Aquí intente reutilizar nvme_rdma_teardown_admin_queue() para solucionar este problema y simplificar el código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: revertir el reemplazo de IS_ERR_OR_NULL con IS_ERR nuevamente. El commit 028ddcac477b ("bcache: eliminar la comprobación innecesaria del punto NULL en las asignaciones de nodos") conduce a una deferencia de puntero NULL en cache_set_flush(). 1721 if (!IS_ERR_OR_NULL(c->root)) 1722 list_add(&c->root->list, &c->btree_cache); >Del código anterior en cache_set_flush(), si el código de registro anterior falla antes de asignar c->root, es posible que c->root sea NULL como lo que se inicializa. __bch_btree_node_alloc() nunca devuelve NULL, pero es posible que c->root sea NULL en la línea 1721 anterior. Este parche reemplaza IS_ERR() por IS_ERR_OR_NULL() para solucionar esto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Evitar bucle infinito de tailcall causado por freplace Existe un posible problema de bucle infinito que puede ocurrir al usar una combinación de llamadas de cola y freplace. En una próxima autoprueba, el objetivo de conexión para entry_freplace de tailcall_freplace.c es subprog_tc de tc_bpf2bpf.c, mientras que la llamada de cola en entry_freplace conduce a entry_tc. Esto da como resultado un bucle infinito: entry_tc -> subprog_tc -> entry_freplace --tailcall-> entry_tc. El problema surge porque tail_call_cnt en entry_freplace se restablece a cero cada vez que se ejecuta entry_freplace, lo que hace que el mecanismo de llamada de cola nunca finalice, lo que finalmente conduce a un pánico del kernel. Para solucionar este problema, la solución es doble: 1. Evitar actualizar un programa extendido por un programa freplace a un mapa prog_array. 2. Evite extender un programa que ya es parte de un mapa prog_array con un programa freplace. Esto garantiza que: * Si un programa o su subprograma ha sido extendido por un programa freplace, ya no puede actualizarse a un mapa prog_array. * Si un programa ha sido agregado a un mapa prog_array, ni él ni sus subprogramas pueden ser extendidos por un programa freplace. Además, un programa de extensión no debe ser llamado al final. Como tal, devuelva -EINVAL si el programa tiene un tipo de BPF_PROG_TYPE_EXT al agregarlo a un mapa prog_array. Además, solucione un problema menor de estilo de código reemplazando ocho espacios con una tabulación para un formato adecuado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: comprobar el valor de retorno de ieee80211_probereq_get() para RNR El valor de retorno de ieee80211_probereq_get() podría ser NULL, por lo que debe comprobarlo antes de usarlo para evitar el acceso al puntero NULL. Addresses-Coverity-ID: 1529805 ("Desreferenciar valor de retorno nulo")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no tome dev_replace rwsem en la tarea que ya lo contiene Al ejecutar fstests btrfs/011 con MKFS_OPTIONS="-O rst" para forzar el uso del árbol de bandas RAID, obtenemos el siguiente mensaje de lockdep: Información de BTRFS (dispositivo sdd): dev_replace de /dev/sdd (devid 1) a /dev/sdb iniciado ============================================ ADVERTENCIA: se detectó un posible bloqueo recursivo 6.11.0-rc3-btrfs-for-next #599 No contaminado -------------------------------------------- btrfs/2326 está intentando adquirir el bloqueo: ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, en: btrfs_map_block+0x39f/0x2250 pero la tarea ya tiene el bloqueo: ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, en: btrfs_map_block+0x39f/0x2250 otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 ---- lock(&fs_info->dev_replace.rwsem); lock(&fs_info->dev_replace.rwsem); *** BLOQUEO INTERMEDIO *** Puede deberse a la falta de notación de anidamiento de bloqueo 1 bloqueo mantenido por btrfs/2326: #0: ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, en: btrfs_map_block+0x39f/0x2250 seguimiento de pila: CPU: 1 UID: 0 PID: 2326 Comm: btrfs No contaminado 6.11.0-rc3-btrfs-for-next #599 Nombre del hardware: Bochs Bochs, BIOS Bochs 01/01/2011 Seguimiento de llamadas: dump_stack_lvl+0x5b/0x80 __lock_acquire+0x2798/0x69d0 ? __pfx___lock_acquire+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 lock_acquire+0x19d/0x4a0 ? btrfs_map_block+0x39f/0x2250 ? __pfx_lock_acquire+0x10/0x10 ? find_held_lock+0x2d/0x110 ? lock_is_held_type+0x8f/0x100 down_read+0x8e/0x440 ? btrfs_map_block+0x39f/0x2250 ? __pfx_down_read+0x10/0x10 ? do_raw_read_unlock+0x44/0x70 ? kmem_cache_alloc_noprof+0x1f2/0x300 ? bvec_alloc+0xd7/0x1b0 ? bio_add_folio+0x171/0x270 ? __pfx_bio_add_folio+0x10/0x10 ? __kasan_check_read+0x20/0x20 btrfs_submit_bio+0x37/0x80 lectura_extensión_búfer_páginas+0x3df/0x6c0 btrfs_lectura_extensión_búfer+0x13e/0x5f0 lectura_árbol_bloque+0x81/0xe0 lectura_bloque_para_búsqueda+0x4bd/0x7a0 ? __pfx_lectura_bloque_para_búsqueda+0x10/0x10 btrfs_búsqueda_slot+0x78d/0x2720 ? __pfx_btrfs_búsqueda_slot+0x10/0x10 ? bloqueo_se_retiene_tipo+0x8f/0x100 ? kasan_guardar_pista+0x14/0x30 ? __kasan_slab_alloc+0x6e/0x70 ? kmem_cache_alloc_noprof+0x1f2/0x300 btrfs_get_raid_extent_offset+0x181/0x820 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_btrfs_get_raid_extent_offset+0x10/0x10 ? down_read+0x194/0x440 ? __pfx_down_read+0x10/0x10 ? do_raw_read_unlock+0x44/0x70 ? _raw_read_unlock+0x23/0x40 btrfs_map_block+0x5b5/0x2250 ? liberación de bloqueo+0x20e/0x710 ? __pfx_scrub_stripe+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? hacer_desbloqueo_lectura_sin_encriptar+0x44/0x70 ? _desbloqueo_lectura_sin_encriptar+0x23/0x40 fragmento_de_scruzamiento+0x257/0x4a0 fragmento_de_scruzamiento_enumerar+0x64c/0xf70 ? __mutex_unlock_slowpath+0x147/0x5f0 ? __pfx_scrub_enumerar_chunks+0x10/0x10 ? tiempo_de_espera_bit+0xb0/0x170 ? __up_read+0x189/0x700 ? obtención_trabajadores_de_scruzamiento+0x231/0x300 ? up_write+0x490/0x4f0 btrfs_scrub_dev+0x52e/0xcd0 ? create_pending_snapshots+0x230/0x250 ? __pfx_btrfs_scrub_dev+0x10/0x10 btrfs_dev_replace_by_ioctl+0xd69/0x1d00 ? lock_acquire+0x19d/0x4a0 ? __pfx_btrfs_dev_replace_by_ioctl+0x10/0x10 ? ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-debug: corrige un posible bloqueo en radix_lock radix_lock() no se debe mantener mientras se mantiene dma_hash_entry[idx].lock de lo contrario, existe un posible escenario de bloqueo cuando se llama a la API de depuración de dma manteniendo rq_lock(): CPU0 CPU1 CPU2 dma_free_attrs() check_unmap() add_dma_entry() __schedule() //out (A) rq_lock() get_hash_bucket() (A) dma_entry_hash check_sync() (A) radix_lock() (W) dma_entry_hash dma_entry_free() (W) radix_lock() // El único rq_lock() de CPU2 (W) La situación de CPU1 puede ocurrir cuando extiende el árbol de radix e intenta despertar a kswapd a través de wake_all_kswapd(). La situación de CPU2 puede ocurrir mientras se ejecuta perf_event_task_sched_out() (es decir, se llama a la operación de sincronización de dma mientras se elimina perf_event usando etm y etr tmc, que son backends del controlador hwtracing de Arm Coresight). Para eliminar esta posible situación, llame a dma_entry_free() después de put_hash_bucket() en check_unmap().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: comprobar smcd_v2_ext_offset al recibir un mensaje de propuesta Al recibir un mensaje de propuesta en el servidor, el campo smcd_v2_ext_offset en el mensaje de propuesta es del cliente remoto y no se puede confiar completamente en él. Una vez que el valor de smcd_v2_ext_offset excede el valor máximo, existe la posibilidad de acceder a una dirección incorrecta y puede ocurrir un bloqueo. Este parche verifica el valor de smcd_v2_ext_offset antes de usarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dlm: arregla posible desreferencia nula de lkb_resource Este parche corrige una posible desreferencia de puntero nulo cuando se llama a esta función desde request_lock() ya que lkb->lkb_resource aún no está asignado, solo después de validar_lock_args() llamando a attached_lkb(). Otro problema es que un nombre de recurso podría ser un bytearray no imprimible y no podemos asumir que esté codificado en ASCII. Es probable que la funcionalidad de registro nunca se vea afectada cuando se usa DLM de forma normal y no se habilita ningún registro de depuración. La desreferencia de puntero nulo solo puede ocurrir en un lkb creado recientemente que aún no tenga el recurso asignado, probablemente nunca llegue a la desreferencia de puntero nulo, pero debemos estar seguros de que otros cambios podrían no cambiar este comportamiento y realmente podemos llegar a la desreferencia de puntero nulo mencionada. En este parche simplemente omitimos la impresión del nombre del recurso, el id de lkb es suficiente para hacer una posible conexión con un nombre de recurso si existe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para reducir el nodo de extensión de lectura en lotes Usamos rwlock para proteger los datos de la estructura central del árbol de extensión durante su reducción, sin embargo, si hay una gran cantidad de nodos de extensión en el árbol de extensión, durante la reducción del árbol de extensión, puede mantener rwlock durante mucho tiempo, lo que puede desencadenar un problema de bloqueo del kernel. Este parche corrige la reducción del nodo de extensión de lectura en lotes, de modo que la región crítica de rwlock se pueda reducir para evitar su retención de tiempo extremadamente largo.