Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: topología: corrige referencias a la memoria liberada. La mayoría de los usuarios, después de analizar un archivo de topología, liberan la memoria utilizada por este, por lo que tener referencias de puntero directamente al contenido del archivo de topología es incorrecto. Utilice devm_kmemdup() para asignar memoria según sea necesario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: PPC: Book3S HV: Prevenir UAF en kvm_spapr_tce_attach_iommu_group() Al informó un posible use after free (UAF) en kvm_spapr_tce_attach_iommu_group(). Busca `stt` en tablefd, pero luego continúa usándolo después de realizar fdput() en el fd devuelto. Después de fdput(), otro hilo puede cerrar el tablefd. El cierre llama a kvm_spapr_tce_release() y luego a release_spapr_tce_table() (a través de call_rcu()) que libera `stt`. Aunque hay llamadas a rcu_read_lock() en kvm_spapr_tce_attach_iommu_group(), no son suficientes para evitar la UAF, porque `stt` se usa fuera de las regiones bloqueadas. Con un retraso artificial después de fdput() y un programa de espacio de usuario que desencadena la ejecución, KASAN detecta la UAF: ERROR: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] Lectura de tamaño 4 en dirección c000200027552c30 por tarea kvm-vfio/2505 CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1 Nombre de hardware: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35 -g1851b2a06 Seguimiento de llamadas de PowerNV: dump_stack_lvl+0xb4/0x108 (no confiable) print_report+0x2b4/0x6ec kasan_report+0x118/0x2b0 __asan_load4+0xb8/0xd0 kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] kvm_vfio_set_attr+0x524/0xac0 [kvm] kvm_device_ioctl+0x144/0x240 [kvm] sys_ioctl+0x62c/0x1810 system_call_exception+0x190/0x440 system_call_vectored_common+0x15c/0x2ec ... Liberado por la tarea 0: ... kfree+0xec/0x3e0 release_spapr_tce_table+0xd4/0x11c [rcu_core+0x568/0 x16a0 handle_softirqs+0x23c /0x920 do_softirq_own_stack+0x6c/0x90 do_softirq_own_stack+0x58/0x90 __irq_exit_rcu+0x218/0x2d0 irq_exit+0x30/0x80 arch_local_irq_restore+0x128/0x230 arch_local_irq_enable+0x1c/0x 30 cpuidle_enter_state+0x134/0x5cc cpuidle_enter+0x6c/0xb0 call_cpuidle+0x7c/0x100 do_idle+0x394 /0x410 cpu_startup_entry+0x60/0x70 start_secondary+0x3fc/0x410 start_secondary_prolog+0x10/0x14 Solucionarlo retrasando fdput() hasta que `stt` ya no esté en uso, que es efectivamente toda la función. Para mantener el parche mínimo, agregue una llamada a fdput() en cada una de las rutas de retorno existentes. El trabajo futuro puede convertir la función a limpieza de estilo goto o __cleanup. Con la solución implementada, el caso de prueba ya no activa la UAF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: wext: agregue verificación de datos SIOCSIWSCAN adicional En 'cfg80211_wext_siwscan()', agregue verificación adicional si el número de canales pasados a través de 'ioctl(sock, SIOCSIWSCAN, ...) ' no excede IW_MAX_FREQUENCIES y rechaza la solicitud no válida con -EINVAL en caso contrario.

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.