Vulnerabilidades

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: 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: espintcp: corrige fugas de skb. En algunas rutas de error falta un kfree_skb.

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: 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: 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: 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: wifi: iwlwifi: corregir el orden de las acciones de depuración. El orden de las acciones de depuración se implementó incorrectamente. Ahora implementamos la división del volcado y el reinicio del firmware se realiza solo en medio del volcado (en lugar de que el firmware se autodestruya en caso de error). Como resultado, algunas acciones al aplicar la configuración ahora bloquearán el dispositivo, por lo que debemos corregir el orden.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fred: Se solucionó el bloqueo del sistema durante la reanudación de S4 con FRED habilitado. Al reactivarse desde S4, el kernel de restauración se inicia e inicializa los MSR de FRED según sea necesario. A continuación, carga una imagen de hibernación, incluyendo el kernel de imagen, e intenta cargar las páginas de la imagen directamente en los marcos de página originales utilizados antes de la hibernación, a menos que dichos marcos estén en uso. Una vez que todas las páginas se mueven a sus ubicaciones originales, se accede a una página "trampolín" en el kernel de imagen. En este punto, el kernel de imagen toma el control, pero los MSR de FRED aún contienen valores establecidos por el kernel de restauración, que pueden diferir de los establecidos por el kernel de imagen antes de la hibernación. Por lo tanto, el kernel de imagen debe garantizar que los MSR de FRED tengan los mismos valores que antes de la hibernación. Dado que estos valores dependen únicamente de la ubicación del texto y los datos del kernel, pueden recalcularse desde cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_ring: corrige la ejecución de datos etiquetando event_triggered como racy para KCSAN syzbot informa una ejecución de datos al acceder a event_triggered, aquí está la pila simplificada cuando ocurrió el problema: ===================================================================== ERROR: KCSAN: ejecución de datos en virtqueue_disable_cb / virtqueue_enable_cb_delayed escribe en 0xffff8881025bc452 de 1 byte por la tarea 3288 en la CPU 0: virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring.c:2653 start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264 __netdev_start_xmit include/linux/netdevice.h:5151 [en línea] netdev_start_xmit include/linux/netdevice.h:5160 [en línea] xmit_one net/core/dev.c:3800 [en línea] lectura a 0xffff8881025bc452 de 1 byte por interrupción en la CPU 1: virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [en línea] virtqueue_disable_cb+0x92/0x180 drivers/virtio/virtio_ring.c:2566 skb_xmit_done+0x5f/0x140 drivers/net/virtio_net.c:777 vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715 __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158 handle_irq_event_percpu kernel/irq/handle.c:193 [inline] valor cambiado: 0x01 -> 0x00 ===================================================================== Cuando ocurre la ejecución de datos, la función virtqueue_enable_cb_delayed() establece event_triggered en falso, y virtqueue_disable_cb_split/packed() lo lee como falso debido a la condición de ejecución. Dado que event_triggered es una indicación poco fiable utilizada para la optimización, esto solo debería provocar que el controlador sugiera temporalmente que el dispositivo no envíe una notificación de interrupción cuando se utilice el índice de evento. Solucione este problema de ejecución de datos informado por KCSAN etiquetando explícitamente el acceso como data_racy.

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: Se corrige el use-after-free en cifs_fill_dirent Hay una condición de ejecución en el proceso de concurrencia readdir, que puede acceder al búfer rsp después de que se haya liberado, lo que activa la siguiente advertencia KASAN. ======================================================================== ERROR: KASAN: slab-use-after-free en cifs_fill_dirent+0xb03/0xb60 [cifs] Lectura de tamaño 4 en la dirección ffff8880099b819c por la tarea a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out No contaminado 6.15.0-rc6+ #240 PREEMPT(full) Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e La dirección con errores pertenece al objeto en ffff8880099b8000 que pertenece a la caché cifs_request de tamaño 16588 La dirección con errores se encuentra a 412 bytes dentro de la región liberada de 16588 bytes [ffff8880099b8000, ffff8880099bc0cc) La dirección con errores pertenece a la página física: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== La prueba de concepto (POC) está disponible en el enlace [1]. El proceso que desencadena el problema es el siguiente: Proceso 1 Proceso 2 ----------------------------------- ---truncado---