Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i3c: master: Se corrige la falta de liberación de init_dyn_addr en i3c_master_put_i3c_addrs() if (dev->boardinfo && dev->boardinfo->init_dyn_addr) ^^^ aquí comprobar "init_dyn_addr" i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...) ^^^^ libera "dyn_addr" Se corrige el error de copiar/pegar "dyn_addr" reemplazándolo por "init_dyn_addr".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ad7780: se corrige la división por cero en ad7780_write_raw() En ad7780_write_raw(), val2 puede ser cero, lo que podría provocar un error de división por cero en DIV_ROUND_CLOSEST(). ad7780_write_raw() se basa en write_raw de iio_info. Si bien se declara explícitamente que val puede ser cero (en modo de lectura), no se especifica que val2 sea distinto de cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/arm-smmu: Aplazar la sonda de los clientes después del límite del dispositivo smmu. Se produce una desreferencia de puntero nulo debido a una ejecución entre la sonda del controlador smmu y la sonda del controlador del cliente, cuando se llama a of_dma_configure() para el cliente después de que se haya ejecutado la sonda iommu_device_register() para el controlador smmu pero antes de que se haya llamado a driver_bound() para el controlador smmu. A continuación se muestra cómo se produce la ejecución: T1: sonda de dispositivo Smmu T2: sonda de dispositivo cliente really_probe() arm_smmu_device_probe() iommu_device_register() really_probe() platform_dma_configure() of_dma_configure() of_dma_configure_id() of_iommu_configure() iommu_probe_device() iommu_init_device() arm_smmu_probe_device() arm_smmu_get_by_fwnode() driver_find_device_by_fwnode() driver_find_device() next_device() klist_next() /* puntero nulo asignado a smmu */ /* desreferencia de puntero nulo mientras smmu->streamid_mask */ driver_bound() klist_add_tail() Cuando este puntero smmu nulo se desreferencia más adelante arm_smmu_probe_device, el dispositivo falla. Para solucionar este problema, postergue la prueba del dispositivo cliente hasta que el dispositivo smmu se haya vinculado al controlador smmu de arm. [will: Agregar comentario]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Fix regression with module command in stack_trace_filter Al ejecutar el siguiente comando: # echo "write*:mod:ext3" > /sys/kernel/tracing/stack_trace_filter El comando mod actual provoca una desreferencia de puntero nulo. Si bien el commit 0f17976568b3f ("ftrace: Fix regression with module command in stack_trace_filter") ha solucionado parte del problema, dejó un caso extremo sin resolver, que aún da como resultado un bloqueo del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ovl: Filtrar inodos no válidos con función de búsqueda faltante Agregue una verificación a la función ovl_dentry_weird() para evitar el procesamiento de inodos de directorio que carecen de la función de búsqueda. Esto es importante porque dichos inodos pueden causar errores en overlayfs cuando se pasan a lowerstack.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: corrige pérdida de memoria de proc->delivered_freeze Si se borra una notificación de congelamiento con BC_CLEAR_FREEZE_NOTIFICATION antes de llamar a binder_freeze_notification_done(), entonces se separa de su referencia (por ejemplo, ref->freeze) pero el trabajo permanece en cola en proc->delivered_freeze. Esto genera una pérdida de memoria cuando el proceso finaliza, ya que no se liberan las entradas pendientes en proc->delivered_freeze: objeto sin referencia 0xffff38e8cfa36180 (tamaño 64): comm "binder-util", pid 655, jiffies 4294936641 volcado hexadecimal (primeros 32 bytes): b8 e9 9e c8 e8 38 ff ff b8 e9 9e c8 e8 38 ff ff .....8.......8.. 0b 00 00 00 00 00 00 00 3c 1f 4b 00 00 00 00 00 ........<.K..... backtrace (crc 95983b32): [<000000000d0582cf>] kmemleak_alloc+0x34/0x40 [<000000009c99a513>] __kmalloc_cache_noprof+0x208/0x280 [<00000000313b1704>] binder_thread_write+0xdec/0x439c [<000000000cbd33bb>] binder_ioctl+0x1b68/0x22cc [<000000002bbedeeb>] __arm64_sys_ioctl+0x124/0x190 [<00000000b439adee>] invocar_syscall+0x6c/0x254 [<00000000173558fc>] Este parche corrige la fuga al garantizar que todas las entradas pendientes en proc->delivered_freeze se liberen durante binder_deferred_release().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: corrección del UAF congelado en binder_release_work() Cuando se limpia una referencia de binder, cualquier trabajo congelado en cola en el proceso asociado también debe eliminarse. De lo contrario, la referencia se libera mientras su ref->freeze.work todavía está en cola en proc->work, lo que genera un problema de use-after-free, como lo muestra el siguiente informe de KASAN: ====================================================================== ERROR: KASAN: slab-use-after-free en binder_release_work+0x398/0x3d0 Lectura de tamaño 8 en la dirección ffff31600ee91488 por la tarea kworker/5:1/211 CPU: 5 UID: 0 PID: 211 Comm: kworker/5:1 No contaminado 6.11.0-rc7-00382-gfc6c92196396 #22 Hardware nombre: linux,dummy-virt (DT) Cola de trabajo: eventos binder_deferred_func Rastreo de llamadas: binder_release_work+0x398/0x3d0 binder_deferred_func+0xb60/0x109c process_one_work+0x51c/0xbd4 worker_thread+0x608/0xee8 Asignado por la tarea 703: __kmalloc_cache_noprof+0x130/0x280 binder_thread_write+0xdb4/0x42a0 binder_ioctl+0x18f0/0x25ac __arm64_sys_ioctl+0x124/0x190 activate_syscall+0x6c/0x254 Liberado por la tarea 211: kfree+0xc4/0x230 binder_deferred_func+0xae8/0x109c process_one_work+0x51c/0xbd4 worker_thread+0x608/0xee8 ======================================================================= Este commit corrige el problema al garantizar que cualquier trabajo de congelamiento en cola se elimine al limpiar una referencia de binder.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: corrección de OOB en binder_add_freeze_work() En binder_add_freeze_work() iteramos sobre proc->nodes con el proc->inner_lock retenido. Sin embargo, este bloqueo se elimina temporalmente para adquirir primero el node->lock (orden de anidación de bloqueos). Esto puede competir con binder_deferred_release() que elimina los nodos del proc->nodes rbtree y los agrega a la lista binder_dead_nodes. Esto genera una iteración rota en binder_add_freeze_work() ya que rb_next() usará datos de binder_dead_nodes, lo que activa un acceso fuera de los límites: ====================================================================== ERROR: KASAN: global fuera de los límites en rb_next+0xfc/0x124 Lectura de tamaño 8 en la dirección ffffcb84285f7170 por la tarea freeze/660 CPU: 8 UID: 0 PID: 660 Comm: freeze No contaminado 6.11.0-07343-ga727812a8d45 #18 Nombre del hardware: linux,dummy-virt (DT) Rastreo de llamadas: rb_next+0xfc/0x124 binder_add_freeze_work+0x344/0x534 binder_ioctl+0x1e70/0x25ac __arm64_sys_ioctl+0x124/0x190 La dirección con errores pertenece a la variable: binder_dead_nodes+0x10/0x40 [...] =================================================================== Esto es posible porque proc->nodes (rbtree) y binder_dead_nodes (lista) comparten entradas en binder_node a través de una unión: struct binder_node { [...] union { struct rb_node rb_node; struct hlist_node dead_node; }; Corrija la ejecución comprobando que el procedimiento sigue activo. Si no es así, simplemente salga de la iteración.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: reparar el UAF del nodo en binder_add_freeze_work() En binder_add_freeze_work() iteramos sobre proc->nodes con el proc->inner_lock retenido. Sin embargo, este bloqueo se elimina temporalmente para adquirir primero el node->lock (orden de anidamiento de bloqueos). Esto puede competir con binder_node_release() y activar un use-after-free: ====================================================================== ERROR: KASAN: use-after-free de losa en _raw_spin_lock+0xe4/0x19c Escritura de tamaño 4 en la dirección ffff53c04c29dd04 por la tarea freeze/640 CPU: 5 UID: 0 PID: 640 Comm: freeze No contaminado 6.11.0-07343-ga727812a8d45 #17 Nombre del hardware: linux,dummy-virt (DT) Rastreo de llamadas: _raw_spin_lock+0xe4/0x19c binder_add_freeze_work+0x148/0x478 binder_ioctl+0x1e70/0x25ac __arm64_sys_ioctl+0x124/0x190 Asignado por la tarea 637: __kmalloc_cache_noprof+0x12c/0x27c binder_new_node+0x50/0x700 binder_transaction+0x35ac/0x6f74 binder_thread_write+0xfb8/0x42a0 binder_ioctl+0x18f0/0x25ac __arm64_sys_ioctl+0x124/0x190 Liberado por la tarea 637: kfree+0xf0/0x330 binder_thread_read+0x1e88/0x3a68 binder_ioctl+0x16d8/0x25ac __arm64_sys_ioctl+0x124/0x190 == ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vmalloc: combina todas las operaciones de vaciado de TLB de la dirección virtual de sombra de KASAN en una sola operación. Al compilar la fuente del kernel 'make -j $(nproc)' con el kernel habilitado para KASAN en funcionamiento en una máquina de 256 núcleos, se muestra el siguiente bloqueo suave: watchdog: BUG: soft lockup - ¡CPU n.º 28 atascada durante 22 s! [kworker/28:1:1760] CPU: 28 PID: 1760 Comm: kworker/28:1 Kdump: cargado No contaminado 6.10.0-rc5 #95 Cola de trabajo: eventos drain_vmap_area_work RIP: 0010:smp_call_function_many_cond+0x1d8/0xbb0 Código: 38 c8 7c 08 84 c9 0f 85 49 08 00 00 8b 45 08 a8 01 74 2e 48 89 f1 49 89 f7 48 c1 e9 03 41 83 e7 07 4c 01 e9 41 83 c7 03 f3 90 <0f> b6 01 41 38 c7 7c 08 84 c0 0f 85 d4 06 00 00 8b 45 08 a8 01 75 RSP: 0018:ffffc9000cb3fb60 EFLAGS: 00000202 RAX: 0000000000000011 RBX: ffff8883bc4469c0 RCX: ffffed10776e9949 RDX: 0000000000000002 RSI: ffff8883bb74ca48 RDI: ffffffff8434dc50 RBP: ffff8883bb74ca40 R08: ffff888103585dc0 R09: ffff8884533a1800 R10: 0000000000000004 R11: ffffffffffffffff R12: ffffed1077888d39 R13: dffffc0000000000 R14: ffffed1077888d38 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8883bc400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005577b5c8d158 CR3: 0000000004850000 CR4: 0000000000350ef0 Rastreo de llamadas: ? watchdog_timer_fn+0x2cd/0x390 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x300/0x6d0 ? sched_clock_cpu+0x69/0x4e0 ? __pfx___hrtimer_run_queues+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? ktime_get_update_offsets_now+0x7f/0x2a0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? hrtimer_interrupt+0x2ca/0x760 ? __sysvec_apic_timer_interrupt+0x8c/0x2b0 ? sysvec_apic_timer_interrupt+0x6a/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? smp_call_function_many_cond+0x1d8/0xbb0 ? __pfx_do_kernel_range_flush+0x10/0x10 en_cada_máscara_de_cond_de_cpu+0x20/0x40 flush_tlb_kernel_range+0x19b/0x250 ? srso_return_thunk+0x5/0x5f ? kasan_release_vmalloc+0xa7/0xc0 purga_vmap_node+0x357/0x820 ? __pfx_purge_vmap_node+0x10/0x10 __purge_vmap_area_lazy+0x5b8/0xa10 drenaje_vmap_area_work+0x21/0x30 proceso_uno_work+0x661/0x10b0 subproceso_trabajador+0x844/0x10e0 ? srso_return_thunk+0x5/0x5f ? __kthread_parkme+0x82/0x140 ? __pfx_worker_thread+0x10/0x10 kthread+0x2a5/0x370 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Análisis de depuración: 1. El siguiente registro de ftrace muestra que la CPU de bloqueo pasa demasiado tiempo iterando vmap_nodes y vaciando TLB al purgar estructuras vm_area. (Parte de la información está recortada). kworker: funcgraph_entry: | drain_vmap_area_work() { kworker: funcgraph_entry: | mutex_lock() { kworker: funcgraph_entry: 1.092 us | __cond_resched(); kworker: funcgraph_exit: 3.306 us | } ... ... kworker: funcgraph_entry: | flush_tlb_kernel_range() { ... ... kworker: funcgraph_exit: # 7533.649 us | } ... ... kworker: funcgraph_entry: 2.344 us | mutex_unlock(); kworker: funcgraph_exit: $ 23871554 us | } La función drain_vmap_area_work() tarda más de 23 segundos. Hay 2805 llamadas a flush_tlb_kernel_range() en el registro de ftrace. * Una se llama en __purge_vmap_area_lazy(). * Las demás se llaman mediante purge_vmap_node->kasan_release_vmalloc. purge_vmap_node() libera iterativamente las asignaciones de vmalloc de kasan y vacía la TLB para cada vmap_area. - [Cálculo aproximado] Cada flush_tlb_kernel_range() se ejecuta alrededor de 7,5 ms. -- 2804 * 7,5 ms = 21,03 segundos. -- Por eso se activa un bloqueo suave. 2. Extender el tiempo de bloqueo suave puede solucionar el problema (por ejemplo, # echo ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: slab: Se corrige una comprobación de alineación demasiado estricta en create_cache() En m68k, donde la alineación mínima de unsigned long es de 2 bytes: Pánico del kernel: no se sincroniza: __kmem_cache_create_args: No se pudo crear slab 'io_kiocb'. Error -22 CPU: 0 UID: 0 PID: 1 Comm: swapper No contaminado 6.12.0-atari-03776-g7eaa1f99261a #1783 Pila de 0102fe5c: 0102fe5c 00514a2b 00514a2b ffffff00 00000001 0051f5ed 00425e78 00514a2b 0041eb74 ffffffea 00000310 0051f5ed ffffffea ffffffea 00601f60 00000044 0102ff20 000e7a68 0051ab8e 004383b8 0051f5ed ffffffea 000000b8 00000007 01020c00 00000000 000e77f0 0041e5f0 005f67c0 0051f5ed 000000b6 0102fef4 00000310 0102fef4 00000000 00000016 005f676c 0060a34c 00000010 00000004 00000038 0000009a 01000000 000000b8 005f668e 0102e000 00001372 0102ff88 Seguimiento de llamadas: [<00425e78>] dump_stack+0xc/0x10 [<0041eb74>] panic+0xd8/0x26c [<000e7a68>] __kmem_cache_create_args+0x278/0x2e8 [<000e77f0>] __kmem_cache_create_args+0x0/0x2e8 [<0041e5f0>] memset+0x0/0x8c [<005f67c0>] io_uring_init+0x54/0xd2 La alineación mínima de un tipo integral puede diferir de su tamaño, por lo tanto, no es seguro asumir que un freeptr_t arbitrario (que es básicamente un unsigned long) siempre está alineado a 4 u 8 bytes. Como nada parece requerir una alineación adicional, es seguro solucionar esto relajando la verificación a la alineación mínima real de freeptr_t.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: endpoint: Fix PCI domain ID release in pci_epc_destroy() pci_epc_destroy() invoca pci_bus_release_domain_nr() para liberar el ID de dominio PCI, pero hay dos problemas: - 'epc->dev' se pasa a pci_bus_release_domain_nr() que ya fue liberado por device_unregister(), lo que genera un problema de use-after-free. - El ID de dominio corresponde al dispositivo EPC principal, por lo que pasar 'epc->dev' también es incorrecto. Solucione estos problemas pasando 'epc->dev.parent' a pci_bus_release_domain_nr() y también hágalo antes de device_unregister(). [mani: asunto y descripción reformulados]