Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: corrige la descarga del programa XDP mientras se elimina el controlador La confirmación 6533e558c650 ("i40e: corrige la ruta de reinicio mientras se elimina el controlador") introdujo un nuevo estado de PF "__I40E_IN_REMOVE" para bloquear la modificación del programa XDP mientras se elimina el controlador. Desafortunadamente, tal cambio es útil sólo si la devolución de llamada ".ndo_bpf()" fue llamada fuera del contexto rmmod porque descargar el programa XDP existente también es parte del procedimiento de eliminación del controlador. En otras palabras, desde el contexto rmmod se espera que el controlador descargue el programa XDP sin informar ningún error. De lo contrario, la advertencia del kernel con la pila de llamadas se imprime en dmesg. Ejemplo de escenario de error: 1. Cargue el controlador i40e. 2. Cargue el programa XDP. 3. Descargue el controlador i40e (usando el comando "rmmod"). El registro de advertencia del kernel de ejemplo: [ +0.004646] ADVERTENCIA: CPU: 94 PID: 10395 en net/core/dev.c:9290 unregister_netdevice_many_notify+0x7a9/0x870 [...] [ +0.010959] RIP: 0010:unregister_netdevice_many_notify+0x7a9/ 0x870 [...] [ +0.002726] Seguimiento de llamadas: [ +0.002457] [ +0.002119] ? __advertir+0x80/0x120 [ +0.003245] ? unregister_netdevice_many_notify+0x7a9/0x870 [+0.005586]? report_bug+0x164/0x190 [+0.003678] ? handle_bug+0x3c/0x80 [+0.003503]? exc_invalid_op+0x17/0x70 [+0.003846]? asm_exc_invalid_op+0x1a/0x20 [+0.004200]? unregister_netdevice_many_notify+0x7a9/0x870 [+0.005579]? unregister_netdevice_many_notify+0x3cc/0x870 [ +0.005586] unregister_netdevice_queue+0xf7/0x140 [ +0.004806] unregister_netdev+0x1c/0x30 [ +0.003933] i40e_vsi_release+0x87/0x2f0 [i40e] [ + 0.004604] i40e_remove+0x1a1/0x420 [i40e] [ +0.004220 ] pci_device_remove+0x3f/0xb0 [ +0.003943] device_release_driver_internal+0x19f/0x200 [ +0.005243] driver_detach+0x48/0x90 [ +0.003586] bus_remove_driver+0x6d/0xf0 [ +0.003939] ister_driver+0x2e/0xb0 [ +0.004278] i40e_exit_module+0x10/ 0x5f0 [i40e] [ +0.004570] __do_sys_delete_module.isra.0+0x197/0x310 [ +0.005153] do_syscall_64+0x85/0x170 [ +0.003684] ? syscall_exit_to_user_mode+0x69/0x220 [+0.004886]? do_syscall_64+0x95/0x170 [ +0.003851] ? exc_page_fault+0x7e/0x180 [ +0.003932] Entry_SYSCALL_64_after_hwframe+0x71/0x79 [ +0.005064] RIP: 0033:0x7f59dc9347cb [ +0.003648] Código: 73 01 c3 48 8b 0d 65 16 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 16 0c 00 f7 d8 64 89 01 48 [ +0. 018753] RSP : 002b:00007ffffac99048 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ +0.007577] RAX: ffffffffffffffda RBX: 0000559b9bb2f6e0 RCX: 00007f59dc9347cb [ +0. 007140] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000559b9bb2f748 [ +0.007146] RBP: 00007ffffac99070 R08: 1999999999999999 R09: 0000000000000 [ +0.007133] R10: 00007f59dc9a5ac0 R11: 0000000000000206 R12: 0000000000000000 [ +0.007141] R13: 00007ffffac992d8 R14: 0000559b9bb2f6e0 5: 0000000000000000 [+0.007151] [+0.002204] ---[ final de seguimiento 0000000000000000 ]--- Solucionar esto comprobando si el programa XDP se está cargando o descargando. Luego, bloquee solo la carga de un nuevo programa mientras "__I40E_IN_REMOVE" esté configurado. Además, mueva el indicador de prueba "__I40E_IN_REMOVE" al comienzo de la devolución de llamada XDP_SETUP para evitar operaciones y comprobaciones innecesarias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: skmsg: omitir skb de longitud cero en sk_msg_recvmsg Al ejecutar autopruebas de BPF (./test_progs -t sockmap_basic) en una plataforma Loongarch, se produce el siguiente pánico del kernel: [...] Ups[ #1]: CPU: 22 PID: 2824 Comm: test_progs Contaminado: G OE 6.10.0-rc2+ #18 Nombre del hardware: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018 ... ... ra: 90000000048bf6c0 sk_msg_recvmsg+0x120 /0x560 ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 0000000c (PPLV0 +PIE +PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EssubCode=0) BADV: 00000000000000040 PRID: 0014c011 (Loongson-64bit, Loongson -3C5000) Módulos vinculados en: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack Procesar test_progs (pid: 2824, threadinfo=0000000000863a31, task=...) Pila: ... Seguimiento de llamadas: [<9000000004162774>] 1c0 [ <90000000048bf6c0>] sk_msg_recvmsg+0x120/0x560 [<90000000049f2b90>] tcp_bpf_recvmsg_parser+0x170/0x4e0 [<90000000049aae34>] 0x54/0x100 [<900000000481ad5c>] sock_recvmsg+0x7c/0xe0 [<900000000481e1a8>] __sys_recvfrom+0x108/0x1c0 [ <900000000481e27c>] sys_recvfrom+0x1c/0x40 [<9000000004c076ec>] do_syscall+0x8c/0xc0 [<9000000003731da4>] handle_syscall+0xc4/0x160 Código: ... ---[ end trace 0000000 000000000 ]--- Pánico del kernel: no se sincroniza : Excepción fatal Kernel reubicado por 0x3510000 .text @ 0x9000000003710000 .data @ 0x9000000004d70000 .bss @ 0x9000000006469400 ---[ fin del pánico del kernel - no se sincroniza: excepción fatal ]--- [...] Este bloqueo ocurre cada vez que se ejecuta sockmap_ subprueba skb_verdict_shutdown en sockmap_basic. Este bloqueo se debe a que se pasa un puntero NULL a page_address() en sk_msg_recvmsg(). Debido a las diferentes implementaciones según la arquitectura, page_address(NULL) provocará un pánico en la plataforma Loongarch pero no en la plataforma x86. Entonces, este error estuvo oculto en la plataforma x86 por un tiempo, pero ahora está expuesto en la plataforma Loongarch. La causa principal es que se colocó en la cola un skb de longitud cero (skb->len == 0). Este skb de longitud cero es un paquete TCP FIN, que fue enviado por apagado(), invocado en test_sockmap_skb_verdict_shutdown(): apagado(p1, SHUT_WR); En este caso, en sk_psock_skb_ingress_enqueue(), num_sge es cero y no se coloca ninguna página en este sge (consulte sg_set_page en sg_set_page), pero este sge vacío se pone en cola en la lista ingress_msg. Y en sk_msg_recvmsg(), se usa este sge vacío, y sg_page(sge) obtiene una página NULL. Pase esta página NULL a copy_page_to_iter(), que la pasa a kmap_local_page() y a page_address(), luego el kernel entra en pánico. Para resolver esto, debemos omitir este skb de longitud cero. Entonces, en sk_msg_recvmsg(), si la copia es cero, eso significa que es un skb de longitud cero, omita la invocación de copy_page_to_iter(). Estamos utilizando el retorno EFAULT activado por copy_page_to_iter para verificar is_fin en tcp_bpf.c.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: filelock: corrige el posible use after free en posix_lock_inode Light Hsieh informó una advertencia de KASAN UAF en trace_posix_lock_inode(). El puntero de solicitud se había cambiado anteriormente para apuntar a una entrada de bloqueo que se agregó a la lista del inodo. Sin embargo, antes de que el punto de rastreo pudiera activarse, otra tarea entró rápidamente y liberó ese bloqueo. Solucione este problema moviendo el punto de seguimiento dentro del spinlock, lo que debería garantizar que esto no suceda.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: archivos de caché: asignación cíclica de msg_id para evitar la reutilización La reutilización de msg_id después de una solicitud de reapertura completada maliciosamente puede causar que una solicitud de lectura permanezca sin procesar y resulte en un bloqueo, como se muestra a continuación: t1 | t2 | t3 ------------------------------------------------- cachefiles_ondemand_select_req cachefiles_ondemand_object_is_close(A) cachefiles_ondemand_set_object_reopening(A) queue_work(fscache_object_wq, &info->work) ondemand_object_worker cachefiles_ondemand_init_object(A) cachefiles_ondemand_send_req(OPEN) // obtener msg_id 6 _completion(&req_A->done) cachefiles_ondemand_daemon_read // leer msg_id 6 req_A cachefiles_ondemand_get_fd copy_to_user // Finalización maliciosa msg_id 6 copen 6,-1 cachefiles_ondemand_copen complete(&req_A->done) // no configurará el objeto para que se cierre // porque ondemand_id && fd es válido. // ondemand_object_worker() está listo // pero el objeto aún se está reabriendo. // new open req_B cachefiles_ondemand_init_object(B) cachefiles_ondemand_send_req(OPEN) // reutilizar msg_id 6 process_open_req copen 6,A.size // El copen fallido esperado se ejecutó con éxito Se espera que copen falle y, cuando lo hace, cierra fd, lo que establece el objeto se cierra y luego el cierre activa nuevamente. Sin embargo, debido a que la reutilización de msg_id da como resultado un copen exitoso, el fd anónimo no se cierra hasta que el demonio sale. Por lo tanto, las solicitudes de lectura que esperan que se complete la reapertura pueden desencadenar una tarea colgada. Para evitar este problema, asigne msg_id cíclicamente para evitar reutilizar msg_id durante un período de tiempo muy corto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: espere a que finalice ondemand_object_worker al soltar el objeto Al poner en cola ondemand_object_worker() para volver a abrir el objeto, cachefiles_object no está fijado. El objeto cachefiles_object se puede liberar cuando la solicitud de lectura pendiente se completa intencionalmente y se desmontan los erofs relacionados. Si ondemand_object_worker() se ejecuta después de liberar el objeto, incurrirá en un problema de use after free como se muestra a continuación. proceso A procesos B proceso C proceso D cachefiles_ondemand_send_req() // envía una solicitud de lectura X // espera a que se complete // cierra ondemand fd cachefiles_ondemand_fd_release() // establece el objeto como CERRAR cachefiles_ondemand_daemon_read() // establece el objeto como REAPERTURA queue_work(fscache_wq , &info->ondemand_work) // cerrar /dev/cachefiles cachefiles_daemon_release cachefiles_flush_reqs complete(&req->done) // leer la solicitud X está completa // desmontar el erofs fs cachefiles_put_object() // el objeto será liberado cachefiles_ondemand_deinit_obj_info() kmem_cache_free(object ) // tanto la información como el objeto se liberan ondemand_object_worker() Cuando se suelta un objeto, ya no es necesario volver a abrirlo, así que use cancel_work_sync() para cancelar o espere a que finalice ondemand_object_worker().

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.