Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: evita la eliminación de la referencia NULL ptr en pfn_section_valid() La confirmación 5ec8e8ea8b77 ("mm/sparsemem: corrige la ejecución al acceder a la sección_memoria->uso") cambió pfn_section_valid() para agregar un READ_ONCE() llame a "ms->usage" para arreglar una ejecución con section_deactivate() donde se puede borrar ms->usage. La llamada READ_ONCE(), por sí sola, no es suficiente para evitar la desreferencia al puntero NULL. Necesitamos comprobar su valor antes de desreferenciarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: cs_dsp: use strnlen() en los campos de nombre en archivos wmfw V1. Use strnlen() en lugar de strlen() en las matrices de cadenas de nombres de algoritmos y coeficientes en archivos wmfw V1. En los archivos wmfw V1, el nombre es una cadena terminada en NUL en una matriz de tamaño fijo. cs_dsp debería proteger contra el desbordamiento de la matriz si falta el terminador NUL.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie() Recibimos el siguiente problema en nuestra prueba de estrés de inyección de fallos: ============ ==================================================== ==== ERROR: KASAN: slab-use-after-free en cachefiles_withdraw_cookie+0x4d9/0x600 Lectura de tamaño 8 en la dirección ffff888118efc000 por tarea kworker/u78:0/109 CPU: 13 PID: 109 Comm: kworker/u78:0 No contaminado 6.8.0-dirty #566 Seguimiento de llamadas: kasan_report+0x93/0xc0 cachefiles_withdraw_cookie+0x4d9/0x600 fscache_cookie_state_machine+0x5c8/0x1230 fscache_cookie_worker+0x91/0x1c0 Process_one_work+0x7fa/0x1800 [...] Asignado por la tarea 117: kmalloc_trace+0x1b3/0x3c0 cachefiles_acquire_volume+0xf3/0x9c0 fscache_create_volume_work+0x97/0x150 Process_one_work+0x7fa/0x1800 [...] Liberado por la tarea 120301: kfree+0xf1/0x2c0 cachefiles_withdraw_cache+0x3fa/0x92 0 cachefiles_put_unbind_pincount+0x1f6/0x250 cachefiles_daemon_release+0x13b/0x290 __fput+0x204/0xa00 task_work_run+0x139/0x230 do_exit+0x87a/0x29b0 [...] ================================ ==================================== El siguiente es el proceso que desencadena el problema: p1 | p2 ------------------------------------------------- ----------- fscache_begin_lookup fscache_begin_volume_access fscache_cache_is_live(fscache_cache) cachefiles_daemon_release cachefiles_put_unbind_pincount cachefiles_daemon_unbind cachefiles_withdraw_cache fscache_withdraw_cache fscache_set_cache_state(cache, FSCACHE_CACHE_IS_WITHDRAWN); cachefiles_withdraw_objects(cache) fscache_wait_for_objects(fscache) atomic_read(&fscache_cache->object_count) == 0 fscache_perform_lookup cachefiles_lookup_cookie cachefiles_alloc_object refcount_set(&object->ref, 1); objeto->volumen = volumen fscache_count_object(vcookie->cache); atomic_inc(&fscache_cache->object_count) cachefiles_withdraw_volumes cachefiles_withdraw_volume fscache_withdraw_volume __cachefiles_free_volume kfree(cachefiles_volume) fscache_cookie_state_machine cachefiles_withdraw_cookie cache = objeto->volumen->cache; // archivos_caché_volumen UAF !!! Después de configurar FSCACHE_CACHE_IS_WITHDRAWN, primero espere a que se completen todas las búsquedas de cookies y luego espere a que fscache_cache->object_count == 0 para evitar que la cookie salga después de que se haya liberado el volumen y desencadene el problema anterior. Por lo tanto, llame a fscache_withdraw_volume() antes de llamar a cachefiles_withdraw_objects(). De esta manera, después de configurar FSCACHE_CACHE_IS_WITHDRAWN, solo ocurrirán los dos casos siguientes: 1) fscache_begin_lookup falla en fscache_begin_volume_access(). 2) fscache_withdraw_volume() garantizará que fscache_count_object() se haya ejecutado antes de llamar a fscache_wait_for_objects().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cachefiles: fix slab-use-after-free in fscache_withdraw_volume() Obtuvimos el siguiente problema en nuestra prueba de estrés de inyección defallos: ============ ==================================================== ==== ERROR: KASAN: slab-use-after-free en fscache_withdraw_volume+0x2e1/0x370 Lectura de tamaño 4 en la dirección ffff88810680be08 por tarea ondemand-04-dae/5798 CPU: 0 PID: 5798 Comm: ondemand-04-dae No contaminado 6.8.0-dirty #565 Seguimiento de llamadas: kasan_check_range+0xf6/0x1b0 fscache_withdraw_volume+0x2e1/0x370 cachefiles_withdraw_volume+0x31/0x50 cachefiles_withdraw_cache+0x3ad/0x900 cachefiles_put_unbind_pincount+0x1f6/0x25 0 cachefiles_daemon_release+0x13b/0x290 __fput+0x204/0xa00 task_work_run+0x139 /0x230 Asignado por la tarea 5820: __kmalloc+0x1df/0x4b0 fscache_alloc_volume+0x70/0x600 __fscache_acquire_volume+0x1c/0x610 erofs_fscache_register_volume+0x96/0x1a0 erofs_fscache_register_fs+0x49a/0 x690 erofs_fc_fill_super+0x6c0/0xcc0 vfs_get_super+0xa9/0x140 vfs_get_tree+0x8e/0x300 do_new_mount+0x28c /0x580 [...] Liberado por la tarea 5820: kfree+0xf1/0x2c0 fscache_put_volume.part.0+0x5cb/0x9e0 erofs_fscache_unregister_fs+0x157/0x1b0 erofs_kill_sb+0xd9/0x1c0 deactivate_locked_super+0xa3/0x100 _super+0x105/0x140 vfs_get_tree+0x8e/ 0x300 do_new_mount+0x28c/0x580 [...] ======================================== =========================== El siguiente es el proceso que desencadena el problema: montaje fallido | salida del daemon ------------------------------------------------ ------------ deactivate_locked_super cachefiles_daemon_release erofs_kill_sb erofs_fscache_unregister_fs fscache_relinquish_volume __fscache_relinquish_volume fscache_put_volume(fscache_volume, fscache_volume_put_relinquish) zero = __refcount_dec_and_test(&fscache_volume->ref, &ref); cachefiles_put_unbind_pincount cachefiles_daemon_unbind cachefiles_withdraw_cache cachefiles_withdraw_volumes list_del_init(&volume->cache_link) fscache_free_volume(fscache_volume) cache->ops->free_volume cachefiles_free_volume list_del_init(&cachefiles_volume->cache_link); kfree(fscache_volume) cachefiles_withdraw_volume fscache_withdraw_volume fscache_volume->n_accesses // fscache_volume UAF !!! El fscache_volume en cache->volumes no debe haberse liberado todavía, pero su recuento de referencias puede ser 0. Por lo tanto, utilice la nueva función auxiliar fscache_try_get_volume() para intentar obtener su recuento de referencias. Si el recuento de referencia de fscache_volume es 0, fscache_put_volume() lo está liberando, así que espere a que se elimine de caché->volúmenes. Si su recuento de referencias no es 0, llame a cachefiles_withdraw_volume() con protección de recuento de referencias para evitar el problema anterior.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hfsplus: corrige valor uninit en copy_name [syzbot informó] ERROR: KMSAN: valor uninit en sized_strscpy+0xc4/0x160 sized_strscpy+0xc4/0x160 copy_name+0x2af/0x320 fs/hfsplus /xattr.c:411 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfs_listxattr fs/xattr.c:493 [en línea] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c: 864 [en línea] __do_sys_listxattr fs/xattr.c:876 [en línea] __se_sys_listxattr fs/xattr.c:873 [en línea] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b5 0 arco/x86/incluir/generado /asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit se creó en slab_post_alloc_ gancho mm/slub.c:3877 [en línea] slab_alloc_node mm/slub.c:3918 [en línea] kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [en línea] hfsplus_listxattr+0x4cc/ 0x1a50 fs/hfsplus/xattr.c:699 vfs_listxattr fs/xattr.c:493 [en línea] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [en línea] __do_sys_listxattr fs/xattr.c :876 [en línea] __se_sys_listxattr fs/xattr.c:873 [en línea] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:1 95 do_syscall_x64 arco /x86/entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f [Solución] Al asignar memoria a strbuf, inicialice la memoria a 0.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: SOF: Intel: hda: corrige el deref nulo en la entrada de suspensión del sistema Cuando el sistema entra en suspensión con una secuencia activa, el núcleo de SOF llama a hw_params_upon_resume(). En las plataformas Intel con HDA DMA utilizado para administrar el enlace DMA, esto conduce a la cadena de llamadas de hda_dsp_set_hw_params_upon_resume() -> hda_dsp_dais_suspend() -> hda_dai_suspend() -> hda_ipc4_post_trigger() Se detecta un error en hda_dai_suspend() como hda_link_dma_cleanup() ejecutar primero, lo que borra hext_stream->link_substream, y luego se llama a hda_ipc4_post_trigger() con un puntero NULL snd_pcm_substream.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nfnetlink_queue: drop bogus WARN_ON Ocurre cuando las reglas se vacían/eliminan mientras el paquete está fuera, así que elimine este WARN_ON. Esta ADVERTENCIA existe de una forma u otra desde la versión 4.14, no es necesario realizar un backport a versiones anteriores, por lo tanto, utilice una etiqueta de correcciones más reciente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Aplazar el trabajo en bpf_timer_cancel_and_free Actualmente, el mismo caso del parche anterior (dos devoluciones de llamada de temporizador que intentan cancelarse entre sí) también se puede invocar a través de bpf_map_update_elem, o más precisamente, liberando mapa elementos que contienen temporizadores. Dado que esto también depende de hrtimer_cancel, es propenso a la misma situación de punto muerto que el parche anterior. Sería suficiente usar hrtimer_try_to_cancel para solucionar este problema, ya que el temporizador no se puede poner en cola después de async_cancel_and_free. Una vez que se haya realizado async_cancel_and_free, el temporizador debe reinicializarse antes de poder armarse nuevamente. La devolución de llamada que se ejecuta en paralelo al intentar armar el temporizador fallará, y liberar bpf_hrtimer sin esperar es suficiente (dado kfree_rcu), y bpf_timer_cb devolverá HRTIMER_NORESTART, evitando que el temporizador se rearme nuevamente. Sin embargo, existe un escenario UAF en el que la devolución de llamada arma el temporizador antes de ingresar a esta función, de modo que si la cancelación falla (debido a que la devolución de llamada del temporizador invoca esta rutina o la devolución de llamada del temporizador de destino se ejecuta simultáneamente). En tal caso, si la expiración del temporizador está significativamente lejos en el futuro, la expiración del período de gracia de RCU que ocurra antes liberará el estado bpf_hrtimer y junto con él la estructura hrtimer, que está en cola. Por lo tanto, está claro que la cancelación debe ocurrir después de async_cancel_and_free y, sin embargo, no se puede realizar en línea debido a problemas de interbloqueo. Por lo tanto, modificamos bpf_timer_cancel_and_free para diferir el trabajo a la cola de trabajo global, agregando un work_struct junto con rcu_head (ambos usados en _diferentes_ puntos de tiempo, por lo que pueden compartir espacio). Actualice los comentarios del código existente para reflejar la nueva situación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: core: corrige el error de endpoint duplicado borrando los bits reservados en el descriptor Syzbot ha identificado un error en usbcore (consulte la etiqueta Closes: a continuación) causado por nuestra suposición de que los bits reservados en el campo bEndpointAddress de un descriptor de endpoint siempre será 0. Como resultado del error, la rutina endpoint_is_duplicate() en config.c (y posiblemente también otras rutinas) puede creer que dos descriptores son para endpoints distintos, aunque tengan la misma dirección y número de endpoint. Esto puede generar confusión, incluido el error identificado por syzbot (dos descriptores con direcciones y números de endpoint coincidentes, donde uno era de interrupción y el otro era masivo). Para corregir el error, borraremos los bits reservados en bEndpointAddress cuando analicemos el descriptor. (Tenga en cuenta que las especificaciones de USB-2.0 y USB-3.1 dicen que estos bits están "Reservados, restablecidos a cero"). Esto requiere que hagamos una copia del descriptor anteriormente en usb_parse_endpoint() y usemos la copia en lugar del original cuando buscando duplicados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ks8851: Se corrige el interbloqueo con la variante del chip SPI Cuando SMP está habilitado y los spinlocks son realmente funcionales, entonces hay un interbloqueo con el spinlock 'statelock' entre ks8851_start_xmit_spi y ks8851_irq: watchdog: ERROR: bloqueo suave: ¡CPU n.° 0 se atascó durante 27 segundos! seguimiento de llamadas: queued_spin_lock_slowpath+0x100/0x284 do_raw_spin_lock+0x34/0x44 ks8851_start_xmit_spi+0x30/0xb8 ks8851_start_xmit+0x14/0x20 netdev_start_xmit+0x40/0x6c 0xbc sch_direct_xmit+0xa4/0x22c __qdisc_run+0x138/0x3fc qdisc_run+0x24/0x3c net_tx_action+ 0xf8/0x130 handle_softirqs+0x1ac/0x1f0 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x3c/0x58 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x54/0x9c _exit_rcu+0x10/0x1c el1_interrupt+0x38/0x50 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+ 0x64/0x68 __netif_schedule+0x6c/0x80 netif_tx_wake_queue+0x38/0x48 ks8851_irq+0xb8/0x2c8 irq_thread_fn+0x2c/0x74 irq_thread+0x10c/0x1b0 kthread+0xc8/0xd8 k+0x10/0x20 Este problema no se identificó anteriormente porque se realizaron pruebas en un dispositivo con SMP deshabilitado y, por lo tanto, los spinlocks eran en realidad NOP. Ahora use spin_(un)lock_bh para el bloqueo relacionado con la cola TX para evitar la ejecución del trabajo de softirq de forma sincrónica que conduciría a un punto muerto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: cs_dsp: evita la saturación de búfer al procesar encabezados de alg V2. Verifique que todos los campos de un encabezado de algoritmo V2 encajen en el búfer de datos del firmware disponible. El formato wmfw V2 introdujo cadenas de longitud variable en el encabezado del bloque del algoritmo. Esto significa que la longitud total del encabezado es variable y la posición de la mayoría de los campos varía según la longitud de los campos de cadena. Se debe verificar cada campo para garantizar que no desborde el búfer de datos del firmware. Como se trata de un parche de corrección de errores, las correcciones evitan realizar cambios significativos en el código existente. Esto hace que sea más fácil de revisar y menos probable que se introduzcan nuevos errores.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: firmware: cs_dsp: corrige la verificación de desbordamiento del encabezado wmfw. Se corrige la verificación de que el búfer del archivo de firmware sea lo suficientemente grande para el encabezado wmfw, para evitar que se sobrecargue el búfer. El código original probó que el búfer de datos del firmware contenía suficientes bytes para las sumas del tamaño de las estructuras wmfw_header + wmfw_adsp1_sizes + wmfw_footer. Pero wmfw_adsp1_sizes solo se usa en el firmware ADSP1. Para ADSP2 y Halo Core, la estructura equivalente es wmfw_adsp2_sizes, que es 4 bytes más larga. Por lo tanto, la verificación de longitud no garantiza que haya suficientes bytes en el búfer del firmware para un encabezado con wmfw_adsp2_sizes. Este parche divide el control de longitud en tres partes separadas. Cada uno de los wmfw_header, wmfw_adsp?_sizes y wmfw_footer se verifican por separado antes de usarse.