Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: genirq/msi: Almacenar el IOVA de IOMMU directamente en msi_desc en lugar de en iommu_cookie La traducción de IOMMU para direcciones de mensajes MSI ha sido un proceso de 2 pasos, separados en el tiempo: 1) iommu_dma_prepare_msi(): Un puntero de cookie que contiene la dirección IOVA se almacena en el descriptor MSI cuando se asigna una interrupción MSI. 2) iommu_dma_compose_msi_msg(): este puntero de cookie se utiliza para calcular una dirección de mensaje traducida. Esto tiene un problema de vida útil inherente para el puntero almacenado en la cookie que debe seguir siendo válido entre los dos pasos. Sin embargo, no hay bloqueo en la capa irq que ayude a proteger la vida útil. Hoy en día, esto funciona bajo el supuesto de que el dominio iommu no cambia mientras se programan las interrupciones MSI. Esto aplica a los usuarios normales de la API de DMA dentro del kernel, ya que el dominio iommu se conecta antes de sondear el controlador y no se puede cambiar mientras esté conectado. El tipo 1 de VFIO clásico también impedía cambiar el dominio iommu mientras VFIO se ejecutaba, ya que no admite cambiar el "contenedor" después del inicio. Sin embargo, iommufd ha mejorado esto para que el dominio iommu se pueda cambiar durante la operación de VFIO. Esto potencialmente permite que el espacio de usuario compita directamente con VFIO_DEVICE_ATTACH_IOMMUFD_PT (que llama a iommu_attach_group()) y VFIO_DEVICE_SET_IRQS (que llama a iommu_dma_compose_msi_msg()). Esto potencialmente provoca que tanto el puntero de cookie como la llamada desbloqueada a iommu_get_domain_for_dev() en la ruta de traducción MSI se conviertan en UAF. Corrija el UAF de la cookie MSI eliminando el puntero de cookie. La dirección IOVA traducida ya se conoce durante iommu_dma_prepare_msi() y no puede modificarse. Por lo tanto, puede almacenarse simplemente como un entero en el descriptor MSI. El resto de UAF relacionado con iommu_get_domain_for_dev() se abordará en el parche "iommu: Convertir iommu_dma_prepare_msi() en una operación genérica" mediante el mutex del grupo IOMMU.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/intel: Corrección de una falla de segmentación con PEBS-via-PT con sample_freq. Actualmente, usar PEBS-via-PT con una frecuencia de muestreo en lugar de un periodo de muestreo provoca una falla de segmentación. Por ejemplo: Error: Desreferencia de puntero nulo del kernel, dirección: 0000000000000195 ? __die_body.cold+0x19/0x27 ? page_fault_oops+0xca/0x290 ? exc_page_fault+0x7e/0x1b0 ? asm_exc_page_fault+0x26/0x30 ? intel_pmu_pebs_event_update_no_drain+0x40/0x60 ? intel_pmu_pebs_event_update_no_drain+0x32/0x60 intel_pmu_drain_pebs_icl+0x333/0x350 handle_pmi_common+0x272/0x3c0 intel_pmu_handle_irq+0x10a/0x2e0 perf_event_nmi_handler+0x2a/0x50 Esto sucede porque intel_pmu_pebs_event_update_no_drain() asume que todos los bits pebs_enabled representan índices de contador, lo que no siempre es el caso. En este caso particular, los bits 60 y 61 se establecen para fines de PEBS a través de PT. El comportamiento de PEBS a través de PT con frecuencia de muestreo es cuestionable porque, aunque se genera un PMI (PEBS_PMI_AFTER_EACH_RECORD), el período no se ajusta de todos modos. Dejando eso de lado, corrija intel_pmu_pebs_event_update_no_drain() pasando la máscara de bits del contador en lugar de 'size'. Tenga en cuenta que, antes de el commit de las correcciones, 'size' estaba limitado al índice máximo del contador, por lo que el problema no se solucionó.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ptp: ocp: Limitar el conteo de señales/frecuencias en las funciones de salida de resumen. La salida de resumen de debugfs podría acceder a elementos no inicializados en las matrices freq_in[] y signal_out[], lo que causa desreferencias de punteros nulos y desencadena un error de kernel (page_fault_oops). Este parche agrega campos u8 (nr_freq_in, nr_signal_out) para rastrear el número de elementos inicializados, con un máximo de 4 por matriz. Las funciones de salida de resumen se actualizan para respetar estos límites, lo que evita el acceso fuera de los límites y garantiza el manejo seguro de la matriz. Amplíe las variables de etiqueta porque el cambio confunde a GCC sobre la longitud máxima de las cadenas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: copy_verifier_state() debería copiar el campo 'loop_entry'. El estado bpf_verifier_state.loop_entry debería ser copiado por copy_verifier_state(). De lo contrario, los valores .loop_entry de estados no relacionados envenenarían env->cur_state. Además, env->stack no debería contener ningún estado con .loop_entry != NULL. Los estados en env->stack aún están por verificar, mientras que .loop_entry está configurado para estados que alcanzaron un estado equivalente. Esto significa que env->cur_state->loop_entry siempre debería ser NULL después de pop_stack(). Vea la autoprueba en la siguiente confirmación para un ejemplo del programa que no es seguro pero es aceptado por el verificador sin esta corrección. Este cambio tiene algún impacto en el rendimiento de la verificación para las autopruebas: Archivo Programa Insns (A) Insns (B) Insns (DIFF) Estados (A) Estados (B) Estados (DIFF) ---------------------------------- ---------------------------- --------- --------- -------------- ---------- ---------- ------------- arena_htab.bpf.o arena_htab_llvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%) arena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%) arena_list.bpf.o arena_list_del 309 279 -30 (-9.71%) 23 14 -9 (-39.13%) iters.bpf.o iter_subprog_check_stacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%) iters.bpf.o iter_subprog_iters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%) iters.bpf.o loop_state_deps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%) kmem_cache_iter.bpf.o open_coded_iter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%) verifier_bits_iter.bpf.o max_words 92 84 -8 (-8.70%) 8 7 -1 (-12.50%) verifier_iterating_callbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%)Y un impacto negativo significativo para sched_ext: Archivo Programa Insns (A) Insns (B) Insns (DIFF) Estados (A) Estados (B) Estados (DIFF) ----------------- ---------------------- --------- --------- -------------------- ---------- ---------- ------------------ bpf.bpf.o lavd_init 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%) bpf.bpf.o layered_dispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%) bpf.bpf.o layered_dump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%) bpf.bpf.o layered_enqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%) bpf.bpf.o p2dq_dispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%) bpf.bpf.o p2dq_init 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%) bpf.bpf.o refresh_layer_cpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%) bpf.bpf.o rusty_select_cpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%) scx_central.bpf.o central_dispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%) scx_nest.bpf.o nest_init 636 815 +179 (+28.14%) 60 73 +13 (+21.67%) scx_qmap.bpf.o qmap_dispatch ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: evitar la desreferencia de puntero NULL si no hay un árbol csum válido [ERROR] Al intentar una limpieza de solo lectura en un btrfs con la opción de montaje rescue=idatacsums, se bloqueará con el siguiente seguimiento de llamada: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000208 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: GO 6.15.0-rc3-custom+ #236 PREEMPT(full) Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS desconocido 02/02/2022 RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs] Seguimiento de llamadas: scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs] scrub_simple_mirror+0x175/0x290 [btrfs] scrub_stripe+0x5f7/0x6f0 [btrfs] scrub_chunk+0x9a/0x150 [btrfs] scrub_enumerate_chunks+0x333/0x660 [btrfs] btrfs_scrub_dev+0x23e/0x600 [btrfs] btrfs_ioctl+0x1dcf/0x2f80 [btrfs] __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e [CAUSE] La opción de montaje "rescue=idatacsums" omitirá por completo la carga del árbol de sumas de comprobación (CSUM), por lo que los datos leídos no encontrarán ninguna CSU, por lo que se ignorará la verificación de la suma de comprobación de datos. Normalmente, los sitios de llamada que utilizan el árbol de CSU comprueban el bit NO_DATA_CSUMS del indicador de estado del sistema de archivos, pero lamentablemente, scrub no lo comprueba en absoluto. Esto provoca que scrub llame a btrfs_search_slot() en un puntero nulo, lo que provocó el bloqueo mencionado anteriormente. [CORRECCIÓN] Compruebe la extensión y la raíz del árbol de CSU antes de realizar cualquier búsqueda en el árbol.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: Intel: hda: Se corrige el UAF al recargar el módulo. hda_generic_machine_select() añade -idisp al nombre de archivo tplg asignando una nueva cadena con devm_kasprintf() y luego la almacena directamente en la variable global snd_soc_acpi_intel_hda_machines. Al descargar el módulo, se libera esta memoria, lo que genera una variable global que apunta a la memoria liberada. Recargar el módulo luego activa un use-after-free: ERROR: KFENCE: use-after-free read in string+0x48/0xe0 Use-after-free read at 0x00000000967e0109 (in kfence-#99): string+0x48/0xe0 vsnprintf+0x329/0x6e0 devm_kvasprintf+0x54/0xb0 devm_kasprintf+0x58/0x80 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] sof_probe_work+0x7f/0x600 [snd_sof] process_one_work+0x17b/0x330 worker_thread+0x2ce/0x3f0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 kfence-#99: 0x00000000198a940f-0x00000000ace47d9d, size=64, cache=kmalloc-64 allocated by task 333 on cpu 8 at 17.798069s (130.453553s ago): devm_kmalloc+0x52/0x120 devm_kvasprintf+0x66/0xb0 devm_kasprintf+0x58/0x80 hda_machine_select.cold+0x198/0x17a2 [snd_sof_intel_hda_generic] sof_probe_work+0x7f/0x600 [snd_sof] process_one_work+0x17b/0x330 worker_thread+0x2ce/0x3f0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 freed by task 1543 on cpu 4 at 141.586686s (6.665010s ago): release_nodes+0x43/0xb0 devres_release_all+0x90/0xf0 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c1/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x42/0xb0 __do_sys_delete_module+0x1d1/0x310 do_syscall_64+0x82/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e Corríjalo copiando la matriz de coincidencia con devm_kmemdup_array() antes de modificarla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: pktgen: corrige el acceso fuera del búfer dado por el usuario en pktgen_thread_write() Respeta el tamaño del búfer dado por el usuario para las llamadas strn_len() (de lo contrario, strn_len() accederá a la memoria fuera del búfer dado por el usuario).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: __legitimize_mnt(): la comprobación de MNT_SYNC_UMOUNT debe estar bajo mount_lock... o corremos el riesgo de robar la mntput final de sync umount, lo que genera mnt_count después de que umount(2) haya verificado que la víctima no está ocupada, pero antes de que haya establecido MNT_SYNC_UMOUNT. En ese caso, __legitimize_mnt() no considera que sea seguro deshacer silenciosamente el incremento de mnt_count y continúa eliminando la referencia al llamador, donde se ejecutará una mntput() completa. Es necesaria la comprobación bajo mount_lock; dejar la actual activada antes de tomarla no tiene sentido; no es lo suficientemente común como para molestarse en hacerlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: espintcp: corrige fugas de skb. En algunas rutas de error falta un kfree_skb.

Razón rechazado: esta identificación de CVE ha sido rechazada o retirada por su autoridad de numeración de CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: corrección de null-ptr-deref en idpf_features_check idpf_features_check se utiliza para validar el paquete TX. La longitud del encabezado skb se compara con el valor admitido por el hardware recibido del plano de control del dispositivo. El valor se almacena en la estructura del adaptador y para acceder a él, se utiliza el puntero vport. Durante el reinicio, se liberan todos los vports y el puntero vport al que apunta la estructura privada netdev es NULL. Para evitar null-ptr-deref, almacene el valor de longitud máxima del encabezado en la estructura privada netdev. Esto también ayuda a almacenar en caché el valor y evitar el acceso al puntero del adaptador en la ruta activa. ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000068 ... RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf] Rastreo de llamadas: ? __die+0x23/0x70 ? page_fault_oops+0x154/0x520 ? exc_page_fault+0x76/0x190 ? asm_exc_page_fault+0x26/0x30 ? idpf_features_check+0x6d/0xe0 [idpf] netif_skb_features+0x88/0x310 validate_xmit_skb+0x2a/0x2b0 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x19d/0x3a0 __dev_queue_xmit+0xb74/0xe70 ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: corrección de la desreferencia del puntero NULL del kernel al reemplazar folios hugetlb libres Se observó un fallo del kernel al reemplazar folios hugetlb libres: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000028 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 28 UID: 0 PID: 29639 Comm: test_cma.sh Tainted 6.15.0-rc6-zp #41 PREEMPT(voluntario) RIP: 0010:alloc_and_dissolve_hugetlb_folio+0x1d/0x1f0 RSP: 0018:ffffc9000b30fa90 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000342cca RCX: ffffea0043000000 RDX: ffffc9000b30fb08 RSI: ffffea0043000000 RDI: 0000000000000000 RBP: ffffc9000b30fb20 R08: 0000000000001000 R09: 0000000000000000 R10: ffff88886f92eb00 R11: 000000000000000000 R12: ffffea0043000000 R13: 0000000000000000 R14: 00000000010c0200 R15: 0000000000000004 FS: 00007fcda5f14740(0000) GS:ffff8888ec1d8000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000028 CR3: 0000000391402000 CR4: 0000000000350ef0 Rastreo de llamadas: replace_free_hugepage_folios+0xb6/0x100 alloc_contig_range_noprof+0x18a/0x590 ? srso_return_thunk+0x5/0x5f ? down_read+0x12/0xa0 ? srso_return_thunk+0x5/0x5f cma_range_alloc.constprop.0+0x131/0x290 __cma_alloc+0xcf/0x2c0 cma_alloc_write+0x43/0xb0 simple_attr_write_xsigned.constprop.0.isra.0+0xb2/0x110 debugfs_attr_write+0x46/0x70 full_proxy_write+0x62/0xa0 vfs_write+0xf8/0x420 ? srso_return_thunk+0x5/0x5f ? filp_flush+0x86/0xa0 ? srso_return_thunk+0x5/0x5f ? filp_close+0x1f/0x30 ? srso_return_thunk+0x5/0x5f ? do_dup2+0xaf/0x160 ? srso_return_thunk+0x5/0x5f ksys_write+0x65/0xe0 do_syscall_64+0x64/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e There is a potential race between __update_and_free_hugetlb_folio() and replace_free_hugepage_folios(): CPU1 CPU2 __update_and_free_hugetlb_folio replace_free_hugepage_folios folio_test_hugetlb(folio) -- It's still hugetlb folio. __folio_clear_hugetlb(folio) hugetlb_free_folio(folio) h = folio_hstate(folio) -- Aquí, h es un puntero NULL Cuando ocurre la condición de ejecución anterior, folio_hstate(folio) devuelve NULL y el acceso posterior a este puntero NULL provocará que el sistema se bloquee. Para resolver este problema, ejecute folio_hstate(folio) bajo la protección del bloqueo hugetlb_lock, asegurándose de que folio_hstate(folio) no devuelva NULL.