Vulnerabilidades

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.

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: 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: 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---

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: net/tipc: corrección de lectura slab-use-after-free en tipc_aead_encrypt_done Syzbot informó de una lectura slab-use-after-free con el siguiente seguimiento de llamada: ======================================================================= ERROR: KASAN: slab-use-after-free en tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Lectura de tamaño 8 en la dirección ffff88807a733000 por la tarea kworker/1:0/25 Seguimiento de llamada: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Asignado por la tarea 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Liberado por la tarea 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Después de liberar la transacción tipc_crypto al eliminar el espacio de nombres, tipc_aead_encrypt_done aún puede visitarla en cryptd_queue_worker workqueue. Reproduzco este problema mediante: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disabled media eth dev veth1 ip netns del ns1 La clave de reproducción es que simd_aead_encrypt se interrumpe, lo que lleva a que crypto_simd_usable() devuelva falso. Por lo tanto, se activa cryptd_queue_worker y se visita la transacción tipc_crypto. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // cifrar() simd_aead_encrypt // crypto_simd_usable() es falso child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // cifrar() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // desencadenador cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work) Solucione esto manteniendo el recuento de referencias de red antes de cifrar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: ti: k3-udma-glue: Eliminar argumento skip_fdq de k3_udma_glue_reset_rx_chn El usuario de k3_udma_glue_reset_rx_chn(), p. ej., ti_am65_cpsw_nuss, puede ejecutarse en múltiples plataformas que tengan diferentes arquitecturas DMA. En algunas plataformas puede haber un FDQ para todos los flujos en el canal RX, mientras que en otras hay un FDQ independiente para cada flujo en el canal RX. Hasta ahora, hemos dependido del argumento skip_fdq de k3_udma_glue_reset_rx_chn(). En lugar de depender de que el usuario proporcione esta información, infiérala en función de la arquitectura DMA durante k3_udma_glue_request_rx_chn() y guárdela en un indicador interno 'single_fdq'. Utilice esa bandera en k3_udma_glue_reset_rx_chn() para decidir si el FDQ necesita ser borrado para cada flujo o sólo para el flujo 0. Corrige el siguiente problema en el controlador ti_am65_cpsw_nuss en AM62-SK. > enlace ip establecer eth1 inactivo > enlace ip establecer eth0 inactivo > ethtool -L eth0 rx 8 > enlace ip establecer eth0 activo > modprobe -r ti_am65_cpsw_nuss [ 103.045726] ------------[ cortar aquí ]------------ [ 103.050505] k3_knav_desc_pool tamaño 512000 != avail 64000 [ 103.050703] ADVERTENCIA: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcas p drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 r fkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool] [ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011 [ 103.119968] Hardware name: Texas Instruments AM625 SK (DT) [ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [ 103.154709] sp : ffff8000826ebbc0 [ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000 [ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0 [ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88 [ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000 [ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde [ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000 [ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20 [ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100 [ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000 [ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000 [ 103.229274] Call trace: [ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P) [ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss] [ 103.244942] devm_action_release+0x14/0x20 [ 103.249040] release_nodes+0x3c/0x68 [ 103.252610] devres_release_all+0x8c/0xdc [ 103.256614] device_unbind_cleanup+0x18/0x60 [ 103.260876] device_release_driver_internal+0xf8/0x178 [ 103.266004] driver_detach+0x50/0x9c [ 103.269571] bus_remove_driver+0x6c/0xbc [ 103.273485] driver_unregister+0x30/0x60 [ 103.277401] platform_driver_unregister+0x14/0x20 [ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss] [ 103.288620] __arm64_sys_delete_module+0x17c/0x25c [ 103.293404] invoke_syscall+0x44/0x100 [ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0 [ 103.301845] do_el0_svc+0x1c/0x28 [ 103.305155] el0_svc+0x28/0x98 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: sunxi-ng: h616: Reasignación del reloj de la GPU durante cambios de frecuencia. El manual de H616 no indica que el PLL de la GPU admita la configuración dinámica de frecuencia, por lo que debemos tener especial cuidado al cambiarla. Actualmente, cualquier intento de realizar la configuración dinámica de frecuencia (DVFS) del dispositivo en la GPU provoca varios errores de panfrost y bloqueos de la GPU. El manual describe el algoritmo para cambiar la frecuencia del PLL, que ya es compatible con el código del notificador del PLL de la CPU, por lo que lo reutilizamos para reasignar el reloj de la GPU al reloj de la GPU1 durante los cambios de frecuencia.