Vulnerabilidades

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: 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: 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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinmux: usar acceso secuencial para acceder a los datos de desc->pinmux Cuando dos clientes del mismo gpio llaman a pinctrl_select_state() para la misma funcionalidad, vemos un problema de puntero NULL al acceder a desc->mux_owner. Digamos que dos procesos A, B se ejecutan en pin_request() para el mismo pin y el proceso A actualiza desc->mux_usecount pero aún no actualiza desc->mux_owner mientras que el proceso B ve desc->mux_usecount que fue actualizado por la ruta A y luego ejecuta strcmp y mientras accede a desc->mux_owner se bloquea con el puntero NULL. Serialice el acceso a la configuración relacionada con mux con un bloqueo de mutex. cpu0 (proceso A) cpu1 (proceso B) pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } de lo contrario { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, propietario)) { si (desc->mux_usecount > 1) devuelve 0; desc->mux_owner = propietario; } }

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i3c: Use i3cdev->desc->info en lugar de llamar a i3c_device_get_info() para evitar un bloqueo. Puede ocurrir un bloqueo porque i3c_master_register() adquiere &i3cbus->lock dos veces. Vea el registro a continuación. Use i3cdev->desc->info en lugar de llamar a i3c_device_info() para evitar adquirir el bloqueo dos veces. v2: - Se modificaron el título y el mensaje de confirmación ============================================= ADVERTENCIA: se detectó un posible bloqueo recursivo 6.11.0-mainline -------------------------------------------- init/1 is trying to acquire lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_bus_normaluse_lock but task is already holding lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&i3cbus->lock); lock(&i3cbus->lock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by init/1: #0: fcffff809b6798f8 (&dev->mutex){....}-{3:3}, at: __driver_attach #1: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register stack backtrace: CPU: 6 UID: 0 PID: 1 Comm: init Call trace: dump_backtrace+0xfc/0x17c show_stack+0x18/0x28 dump_stack_lvl+0x40/0xc0 dump_stack+0x18/0x24 print_deadlock_bug+0x388/0x390 __lock_acquire+0x18bc/0x32ec lock_acquire+0x134/0x2b0 down_read+0x50/0x19c i3c_bus_normaluse_lock+0x14/0x24 i3c_device_get_info+0x24/0x58 i3c_device_uevent+0x34/0xa4 dev_uevent+0x310/0x384 kobject_uevent_env+0x244/0x414 kobject_uevent+0x14/0x20 device_add+0x278/0x460 device_register+0x20/0x34 i3c_master_register_new_i3c_devs+0x78/0x154 i3c_master_register+0x6a0/0x6d4 mtk_i3c_master_probe+0x3b8/0x4d8 platform_probe+0xa0/0xe0 really_probe+0x114/0x454 __driver_probe_device+0xa0/0x15c driver_probe_device+0x3c/0x1ac __driver_attach+0xc4/0x1f0 bus_for_each_dev+0x104/0x160 driver_attach+0x24/0x34 bus_add_driver+0x14c/0x294 driver_register+0x68/0x104 __platform_driver_register+0x20/0x30 init_module+0x20/0xfe4 do_one_initcall+0x184/0x464 do_init_module+0x58/0x1ec load_module+0xefc/0x10c8 __arm64_sys_finit_module+0x238/0x33c invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x50/0xac el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i3c: mipi-i3c-hci: Enmascarar interrupciones del anillo antes de la solicitud de detención del anillo La ruta de desinfección del bus en modo DMA puede activar una interrupción RING_OP_STAT cuando se detiene el anillo. Dependiendo del tiempo entre la finalización de la solicitud de detención del anillo, la eliminación del controlador de interrupciones y la ejecución del código, esto puede provocar una desreferencia de puntero NULL en hci_dma_irq_handler() si se ejecuta después de que el puntero io_data se establezca en NULL en hci_dma_cleanup(). Evite esto enmascarando las interrupciones del anillo antes de la solicitud de detención del anillo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: no acceder a sched no válido Desde 2320c9e6a768 ("drm/sched: memset() 'job' en drm_sched_job_init()") acceder a job->base.sched puede producir resultados inesperados ya que la inicialización de (*job)->base.sched realizada en amdgpu_job_alloc es sobrescrita por memset. Esta confirmación corrige un problema cuando un CS fallaría la validación y sería rechazado después de que se incremente job->num_ibs. En este caso, se llamará a amdgpu_ib_free(ring->adev, ...), lo que bloquearía la máquina porque el valor de ring es falso. Para corregir esto, pase un puntero NULL a amdgpu_ib_free(): podemos hacer esto porque el dispositivo en realidad no se usa en esta función. La próxima confirmación eliminará el argumento ring por completo. (seleccionado del commit 2ae520cb12831d264ceb97c61f72c59d33c0dbd7)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched: corrección de advertencia en sched_setaffinity El commit 8f9ea86fdf99b agregó algo de lógica a sched_setaffinity que incluía una ADVERTENCIA cuando una asignación de afinidad por tarea compite con una actualización de cpuset. Específicamente, podemos tener una ejecución donde una actualización de cpuset da como resultado que la afinidad de la tarea ya no sea un subconjunto del cpuset. Eso está bien; tenemos una alternativa para usar la máscara de cpuset. Sin embargo, tenemos una ADVERTENCIA configurada que se activará si la máscara de cpuset no se superpone en absoluto con la afinidad de la tarea solicitada. Esto no debería ser una condición de advertencia; es trivial crear esta condición. Se reprodujo la advertencia con la siguiente configuración: - $PID dentro de un cgroup de cpuset - otro hilo que cambia repetidamente las CPU de cpuset de 1-2 a solo 1 - otro hilo que establece repetidamente la afinidad $PID (a través del conjunto de tareas) en 2

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: evitar reutilizar `hctx` no eliminado de la lista de devolución de llamadas de cpuhp Si 'hctx' no se elimina de la lista de devolución de llamadas de cpuhp, no podemos reutilizarlo, de lo contrario, se puede activar el use after free.

Se ha encontrado una vulnerabilidad clasificada como crítica en Guangzhou Huayi Intelligent Technology Jeewms hasta 20241229. La función datagridGraph del archivo /graphReportController.do está afectada. La manipulación del argumento store_code provoca una inyección SQL. Es posible lanzar el ataque de forma remota. El exploit se ha hecho público y puede utilizarse. La actualización a la versión 20250101 puede solucionar este problema. Se recomienda actualizar el componente afectado.

Se ha encontrado una vulnerabilidad, que se ha clasificado como crítica, en Guangzhou Huayi Intelligent Technology Jeewms hasta 20241229. Este problema afecta a la función saveOrUpdate del archivo org/jeecgframework/web/cgform/controller/build/CgFormBuildController.java. La manipulación conduce a una inyección SQL. El ataque puede iniciarse de forma remota. El exploit se ha divulgado al público y puede utilizarse. La actualización a la versión 20250101 puede solucionar este problema. Se recomienda actualizar el componente afectado.