Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: Corrección de índice de matriz fuera de los límites en dml2/FCLKChangeSupport [Por qué] Posible acceso fuera de los límites en dml2_calculate_rq_and_dlg_params() porque se usó el valor de out_lowest_state_idx como índice para la matriz FCLKChangeSupport puede ser mayor que 1. [Cómo] Actualmente, el núcleo dml2 especifica valores idénticos para todos los elementos FCLKChangeSupport. Utilice siempre el índice 0 en la condición para evitar el acceso fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfio/pci: inicia la variable de conteo al recopilar dispositivos de reinicio en caliente. La variable de conteo se usa sin inicialización, genera errores en el conteo de dispositivos y bloquea el espacio de usuario si se calienta. Se activa el restablecimiento de la ruta de información.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: ufs: core: solucione el problema de ejecución de ufshcd_abort_one Cuando ufshcd_abort_one se ejecuta con el ISR de finalización, ISR establecerá la etiqueta completada del puntero mq_hctx de la solicitud en NULL. Devuelve el éxito cuando ISR completa la solicitud porque ufshcd_abort_one no necesita hacer nada. El flujo de ejecucuones es: Hilo A ufshcd_err_handler paso 1 ... ufshcd_abort_one ufshcd_try_to_abort_task ufshcd_cmd_inflight(true) paso 3 ufshcd_mcq_req_to_hwq blk_mq_unique_tag rq->mq_hctx->queue_num paso 5 Hilo B (cq completar ISR) paso 2 scsi_done... __blk_mq_free_request rq-> mq_hctx = NULO; paso 4 A continuación se muestra el seguimiento de KE. ufshcd_try_to_abort_task: cmd en la etiqueta 41 no está pendiente en el dispositivo. ufshcd_try_to_abort_task: cmd en la etiqueta = 41 se borra. Anulación de la etiqueta 41 / CDB 0x28 exitosa No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000194 pc: [0xffffffddd7a79bf8] blk_mq_unique_tag+0x8/0x14 lr: [0xffffffddd6155b84] x1c/0x40 [ufs_mediatek_mod_ise] do_mem_abort+0x58/0x118 el1_abort+0x3c/ 0x5c el1h_64_sync_handler+0x54/0x90 el1h_64_sync+0x68/0x6c blk_mq_unique_tag+0x8/0x14 ufshcd_err_handler+0xae4/0xfa8 [ufs_mediatek_mod_ise] Process_one_work+0x208/0x4fc trabajador_thread+0x228/0 x438 kthread+0x104/0x1d4 ret_from_fork+0x10/0x20

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: ufs: core: solucione el problema de ejecución de ufshcd_clear_cmd Cuando ufshcd_clear_cmd corre con el ISR de finalización, el ISR establecerá la etiqueta completada del puntero mq_hctx de la solicitud en NULL. Y la llamada de ufshcd_clear_cmd a ufshcd_mcq_req_to_hwq obtendrá un puntero NULL KE. Devuelve el éxito cuando ISR completa la solicitud porque sq no necesita limpieza. El flujo de ejecución es: Hilo A ufshcd_err_handler paso 1 ufshcd_try_to_abort_task ufshcd_cmd_inflight(true) paso 3 ufshcd_clear_cmd ... ufshcd_mcq_req_to_hwq blk_mq_unique_tag rq->mq_hctx->queue_num paso 5 Hilo ufs_mtk_mcq_int r(cq completar ISR) paso 2 scsi_done ... __blk_mq_free_request rq-> mq_hctx = NULO; paso 4 A continuación se muestra el rastreo de KE: ufshcd_try_to_abort_task: cmd pendiente en el dispositivo. etiqueta = 6 No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000194 pc: [0xffffffd589679bf8] blk_mq_unique_tag+0x8/0x14 lr: [0xffffffd5862f95b4] ufshcd_mcq_sq_cleanup+0x6c/0x1cc _mod_ise] Cola de trabajo: ufs_eh_wq_0 ufshcd_err_handler [ufs_mediatek_mod_ise] Seguimiento de llamadas: dump_backtrace+0xf8 /0x148 show_stack+0x18/0x24 dump_stack_lvl+0x60/0x7c dump_stack+0x18/0x3c mrdump_common_die+0x24c/0x398 [mrdump] ipanic_die+0x20/0x34 [mrdump] notify_die+0x80/0xd8 die+0x94/0x2b8 __do_kernel_fault+0x264/0x298 do_page_fault+ 0xa4/0x4b8 do_translation_fault+0x38/0x54 do_mem_abort+0x58/0x118 el1_abort+0x3c/0x5c el1h_64_sync_handler+0x54/0x90 el1h_64_sync+0x68/0x6c blk_mq_unique_tag+0x8/0x14 clear_cmd+0x34/0x118 [ufs_mediatek_mod_ise] ufshcd_try_to_abort_task+0x2c8/0x5b4 [ufs_mediatek_mod_ise] ufshcd_err_handler +0xa7c/0xfa8 [ufs_mediatek_mod_ise] process_one_work+0x208/0x4fc trabajador_hilo+0x228/0x438 kthread+0x104/0x1d4 ret_from_fork+0x10/0x20

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().