Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: qcom: Solo libera MSI de plataforma cuando ESI está habilitado De lo contrario, resultará en una desreferencia de puntero NULL como se muestra a continuación: No se puede gestionar la desreferencia de puntero NULL del kernel en la dirección virtual 0000000000000008 Rastreo de llamadas: mutex_lock+0xc/0x54 platform_device_msi_free_irqs_all+0x14/0x20 ufs_qcom_remove+0x34/0x48 [ufs_qcom] platform_remove+0x28/0x44 device_remove+0x4c/0x80 device_release_driver_internal+0xd8/0x178 driver_detach+0x50/0x9c bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 ufs_qcom_pltform_exit+0x18/0xb94 [ufs_qcom] __arm64_sys_delete_module+0x180/0x260 invocar_llamada_al_sistema+0x44/0x100 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xdc el0t_64_sync_handler+0xc0/0xc4 el0t_64_sync+0x190/0x194

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Cancelar el trabajo de RTC durante ufshcd_remove() Actualmente, el trabajo de RTC solo se cancela durante __ufshcd_wl_suspend(). Cuando se elimina ufshcd en ufshcd_remove(), el trabajo de RTC no se cancela. Debido a esto, cualquier activación adicional del trabajo de RTC después de ufshcd_remove() daría como resultado una desreferencia de puntero NULL como se muestra a continuación: No se puede gestionar la desreferencia de puntero NULL del núcleo en la dirección virtual 00000000000002a4 Cola de trabajo: eventos ufshcd_rtc_work Rastreo de llamadas: _raw_spin_lock_irqsave+0x34/0x8c pm_runtime_get_if_active+0x24/0xb4 ufshcd_rtc_work+0x124/0x19c process_scheduled_works+0x18c/0x2d8 worker_thread+0x144/0x280 kthread+0x11c/0x128 ret_from_fork+0x10/0x20 Dado que el trabajo de RTC accede a las estructuras internas de ufshcd, se debe cancelar cuando se elimina ufshcd. Haga esto en ufshcd_remove(), según el orden en ufshcd_init().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommufd: Arreglar out_fput en iommufd_fault_alloc() Como fput() llama a la operación file->f_op->release, donde se liberan los objetos de falla y ictx, no hay necesidad de liberar estos dos después de fput() una vez más, lo que daría como resultado recuentos de referencias desequilibrados: refcount_t: el decremento llega a 0; pérdida de memoria. ADVERTENCIA: CPU: 48 PID: 2369 en lib/refcount.c:31 refcount_warn_saturate+0x60/0x230 Rastreo de llamadas: refcount_warn_saturate+0x60/0x230 (P) refcount_warn_saturate+0x60/0x230 (L) iommufd_fault_fops_release+0x9c/0xe0 [iommufd] ... VFS: Cerrar: el recuento de archivos es 0 (f_op=iommufd_fops [iommufd]) ADVERTENCIA: CPU: 48 PID: 2369 en fs/open.c:1507 filp_flush+0x3c/0xf0 Rastreo de llamadas: filp_flush+0x3c/0xf0 (P) filp_flush+0x3c/0xf0 (L) __arm64_sys_close+0x34/0x98 ... desequilibrado en el recuento de referencias de archivo ADVERTENCIA: CPU: 48 PID: 2369 en fs/file.c:74 __file_ref_put+0x100/0x138 Rastreo de llamadas: __file_ref_put+0x100/0x138 (P) __file_ref_put+0x100/0x138 (L) __fput_sync+0x4c/0xd0 Omita esas dos líneas para corregir las advertencias anteriores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: arregla las escrituras OOB de devmap al eliminar elementos Jordy informó un problema contra XSKMAP que también se aplica a DEVMAP: el índice utilizado para acceder a la entrada del mapa, debido a que es un entero con signo, provoca las escrituras OOB. La solución es tan simple como cambiar el tipo de int a u32, sin embargo, en comparación con el caso de XSKMAP, hay que abordar una cosa más. Cuando el mapa se libera del sistema a través de dev_map_free(), iteramos a través de todas las entradas y una variable de iterador también es un int, lo que implica accesos OOB. Nuevamente, cámbielo a u32. Ejemplo de splat a continuación: [ 160.724676] ERROR: no se puede gestionar el error de página para la dirección: ffffc8fc2c001000 [ 160.731662] #PF: acceso de lectura del supervisor en modo kernel [ 160.736876] #PF: error_code(0x0000) - página no presente [ 160.742095] PGD 0 P4D 0 [ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP [ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 No contaminado 6.12.0-rc1+ #487 [ 160.757050] Nombre del hardware: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 19/03/2019 [ 160.767642] Cola de trabajo: events_unbound bpf_map_free_deferred [ 160.773308] RIP: 0010:dev_map_free+0x77/0x170 [ 160.777735] Código: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff [ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202 [ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 00000000000000024 [ 160.809331] RDX: 0000000000000000 RSI: 00000000000000024 RDI: ffffc9002c001000 [ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001 [ 160.823823] R10: 000000000000001 R11: 00000000000ee6b2 R12: muerto000000000122 [ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000 [ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000 [ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0 [ 160.859604] DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 160.874092] PKRU: 55555554 [ 160.876847] Rastreo de llamadas: [ 160.879338] [ 160.881477] ? __die+0x20/0x60 [ 160.884586] ? exc_page_fault+0xa9/0x140 [ 160.900973] ? asm_exc_page_fault+0x22/0x30 [ 160.905232] ? dev_map_free+0x77/0x170 [ 160.909043] ? dev_map_free+0x58/0x170 [ 160.912857] bpf_map_free_deferred+0x51/0x90 [ 160.917196] process_one_work+0x142/0x370 [ 160.921272] subproceso_trabajador+0x29e/0x3b0 [ 160.925082] ? subproceso_rescatador+0x4b0/0x4b0 [ 160.929157] kthread+0xd4/0x110 [ 160.932355] ? kthread_park+0x80/0x80 [ 160.936079] ret_from_fork+0x2d/0x50 [ 160.943396] ? kthread_park+0x80/0x80 [ 160.950803] ret_desde_fork_asm+0x11/0x20 [ 160.958482]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/dp_mst: Corregir la comprobación de longitud del cuerpo del mensaje de banda lateral MST Corrige la comprobación de longitud del cuerpo del mensaje de banda lateral MST, que debe ser de al menos 1 byte teniendo en cuenta el CRC del cuerpo del mensaje (también conocido como CRC de los datos del mensaje) al final del mensaje. Esto corrige un caso en el que un dispositivo de rama MST devuelve un encabezado con un CRC de encabezado correcto (que indica una longitud de cuerpo recibida correctamente), con la longitud del cuerpo configurada incorrectamente en 0. Esto luego provocará una corrupción de memoria en drm_dp_sideband_append_payload() y los siguientes errores en dmesg: UBSAN: array-index-out-of-bounds en drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type 'u8 [48]' Seguimiento de llamadas: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: se detectó una escritura que abarca el campo (tamaño 18446744073709551615) de un solo campo "&msg->msg[msg->curlen]" en drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (tamaño 256) Seguimiento de llamadas: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: se corrige un posible acceso a memoria fuera de los límites en nilfs_find_entry() Syzbot informó que al buscar registros en un directorio donde el i_size del inodo está dañado y tiene un valor grande, puede ocurrir un acceso a memoria fuera del rango de folio/página, o puede detectarse un error de use-after-free si KASAN está habilitado. Esto se debe a que nilfs_last_byte(), que es llamado por nilfs_find_entry() y otros para calcular la cantidad de bytes válidos de datos de directorio en una página a partir de i_size y el índice de página, pierde los 32 bits superiores de la información de tamaño de 64 bits debido a un tipo inadecuado de variable local a la que se asigna el valor de i_size. Esto causó un valor de desplazamiento de bytes grande debido al desbordamiento en el cálculo de la dirección final en la llamada nilfs_find_entry(), lo que resultó en un acceso a memoria que excede el tamaño de folio/página. Solucione este problema cambiando el tipo de la variable local que causa la pérdida de bits de "unsigned int" a "u64". El valor de retorno de nilfs_last_byte() también es del tipo "unsigned int", pero se trunca para no superar PAGE_SIZE y no se produce ninguna pérdida de bits, por lo que no se requiere ningún cambio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: sysfs: Evitar división por cero Evita una división por 0 cuando la monitorización no está habilitada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: Se corrige el use-after-free en la descarga Se observa un fallo del sistema con una advertencia de seguimiento de la pila de use-after-free. Hay 2 señales para indicar a dpc_thread que finalice (indicador UNLOADING y kthread_stop). Al establecer el indicador UNLOADING cuando dpc_thread se está ejecutando en ese momento y ve el indicador, esto hace que dpc_thread salga y se limpie a sí mismo. Cuando se llama a kthread_stop para la desinfección final, esto provoca el use-after-free. Eliminar la señal UNLOADING para finalizar dpc_thread. Usar kthread_stop como la señal principal para salir de dpc_thread. [596663.812935] ¡ERROR del kernel en mm/slub.c:294! [596663.812950] Código de operación no válido: 0000 [#1] SMP PTI [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: cargado Contaminado: G IOE --------- - - 4.18.0-240.el8.x86_64 #1 [596663.812960] Nombre del hardware: HP ProLiant DL380p Gen8, BIOS P70 20/08/2012 [596663.812974] RIP: 0010:__slab_free+0x17d/0x360 ... [596663.813008] Seguimiento de llamadas: [596663.813022] ? esperar_a_finalización+0x35/0x190 [596663.813048] ? intentar_activar+0x63/0x540 [596663.813055] tarea_libre+0x5a/0x60 [596663.813061] kthread_stop+0xf3/0x100 [596663.813103] qla2x00_eliminar_uno+0x284/0x440 [qla2xxx]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: arregla llamadas atómicas en ath12k_mac_op_set_bitrate_mask() Cuando intento configurar manualmente las tasas de bits: iw wlan0 set bitrates legacy-2.4 1 Me aparece un error de suspensión por contexto no válido, consulte a continuación. Solucione eso cambiando al uso de ieee80211_iterate_stations_mtx() introducido recientemente. Tenga en cuenta que el firmware WCN6855 sigue fallando, no estoy seguro de si ese firmware incluso admite comandos WMI de tasa de bits y ¿deberíamos considerar deshabilitar ath12k_mac_op_set_bitrate_mask() para WCN6855? Pero eso es para otro parche. ERROR: función inactiva llamada desde un contexto no válido en drivers/net/wireless/ath/ath12k/wmi.c:420 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 2236, name: iw preempt_count: 0, expected: 0 Profundidad de anidación de RCU: 1, expected: 0 3 bloqueos mantenidos por iw/2236: #0: ffffffffabc6f1d8 (cb_lock){++++}-{3:3}, en: genl_rcv+0x14/0x40 #1: ffff888138410810 (&rdev->wiphy.mtx){+.+.}-{3:3}, en: nl80211_pre_doit+0x54d/0x800 [cfg80211] #2: ffffffffab2cfaa0 (rcu_read_lock){....}-{1:2}, en: ieee80211_iterate_stations_atomic+0x2f/0x200 [mac80211] CPU: 3 UID: 0 PID: 2236 Comm: iw No contaminado 6.11.0-rc7-wt-ath+ #1772 Nombre del hardware: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 28/05/2021 Seguimiento de llamadas: dump_stack_lvl+0xa4/0xe0 dump_stack+0x10/0x20 __might_resched+0x363/0x5a0 ? __alloc_skb+0x165/0x340 __might_sleep+0xad/0x160 ath12k_wmi_cmd_send+0xb1/0x3d0 [ath12k] ? ath12k_wmi_init_wcn7850+0xa40/0xa40 [ath12k] ? __netdev_alloc_skb+0x45/0x7b0 ? __asan_memset+0x39/0x40 ? ath12k_wmi_alloc_skb+0xf0/0x150 [ath12k] ? ath12k_mac_vdev_stop+0x4f0/0x4f0 [ath12k] ieee80211_iterate_stations_atomic+0xd4/0x200 [mac80211] ath12k_mac_op_set_bitrate_mask+0x5d2/0x1080 [ath12k] ? __this_cpu_preempt_check+0x13/0x20 nl80211_set_tx_bitrate_mask+0x2bc/0x530 [cfg80211] ? nl80211_parse_tx_bitrate_mask+0x2320/0x2320 [cfg80211] ? trace_contention_end+0xef/0x140 ? rtnl_unlock+0x9/0x10 ? he_set_mcs_mask.isra.0+0x8d0/0x8d0 [cfg80211] ? genl_rcv_msg+0xa0/0x130 netlink_rcv_skb+0x14c/0x400 ? genl_family_rcv_msg+0x600/0x600 ? netlink_ack+0xd70/0xd70 ? rwsem_optimistic_spin+0x4f0/0x4f0 ? genl_rcv+0x14/0x40 ? down_read_killable+0x580/0x580 ? netlink_deliver_tap+0x13e/0x350 ? __esta_comprobación_previa_de_cpu+0x13/0x20 genl_rcv+0x23/0x40 netlink_unicast+0x45e/0x790 ? netlink_attachskb+0x7f0/0x7f0 netlink_sendmsg+0x7eb/0xdb0 ? netlink_unicast+0x790/0x790 ? __esta_comprobación_previa_de_cpu+0x13/0x20 ? selinux_socket_sendmsg+0x31/0x40 ? netlink_unicast+0x790/0x790 __sock_sendmsg+0xc9/0x160 ____sys_sendmsg+0x620/0x990 ? kernel_sendmsg+0x30/0x30 ? __copy_msghdr+0x410/0x410 ? __kasan_check_read+0x11/0x20 ? mark_lock+0xe6/0x1470 ___sys_sendmsg+0xe9/0x170 ? copy_msghdr_from_user+0x120/0x120 ? __lock_acquire+0xc62/0x1de0 ? do_fault_around+0x2c6/0x4e0 ? do_user_addr_fault+0x8c1/0xde0 ? volver a adquirir bloqueos retenidos+0x220/0x4d0 ? do_user_addr_fault+0x8c1/0xde0 ? __kasan_check_read+0x11/0x20 ? __fdget+0x4e/0x1d0 ? sockfd_lookup_light+0x1a/0x170 __sys_sendmsg+0xd2/0x180 ? __sys_sendmsg_sock+0x20/0x20 ? volver a adquirir bloqueos retenidos+0x4d0/0x4d0 ? debug_smp_processor_id+0x17/0x20 __x64_sys_sendmsg+0x72/0xb0 ? lockdep_hardirqs_on+0x7d/0x100 x64_sys_call+0x894/0x9f0 do_syscall_64+0x64/0x130 entrada_SYSCALL_64_after_ ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/mempolicy: se corrige el error de migrants_to_node() suponiendo que hay al menos un VMA en un MM. Actualmente, suponemos que hay al menos un VMA en un MM, lo que no es cierto. Por lo tanto, podríamos terminar haciendo que find_vma() devuelva NULL, para luego desreferenciarlo. Por lo tanto, se gestiona correctamente el error de que find_vma() devuelva NULL. Esto corrige el informe: Ups: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 No contaminado 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [en línea] RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194 Código: ... RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246 RAX: 000000000000000 RBX: ffffc9000375fd78 RCX: 000000000000000 RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044 RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1 R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003 R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8 FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [en línea] __se_sys_migrate_pages mm/mempolicy.c:1723 [en línea] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [akpm@linux-foundation.org: agregar improbable()]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/gup: gestionar páginas NULL en unpin_user_pages() La reciente incorporación dla gestión de "pofs" (páginas o folios) a gup tiene un defecto: supone que unpin_user_pages() gestiona páginas NULL en la matriz pages**. Ese no es el caso, como descubrí cuando ejecuté una nueva configuración en mi máquina de prueba. Solucione esto omitiendo las páginas NULL en unpin_user_pages(), tal como ya lo hace unpin_folios(). Detalles: al arrancar en x86 con "numa=fake=2 movablecore=4G" en Linux 6.12, y ejecutar esto: tools/testing/selftests/mm/gup_longterm ... obtengo el siguiente fallo: ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000008 RIP: 0010:sanity_check_pinned_pages+0x3a/0x2d0 ... Seguimiento de llamadas: ? __die_body+0x66/0xb0 ? page_fault_oops+0x30c/0x3b0 ? do_user_addr_fault+0x6c3/0x720 ? irqentry_enter+0x34/0x60 ? exc_page_fault+0x68/0x100 ? asm_exc_page_fault+0x22/0x30 ? comprobación de integridad de páginas fijadas+0x3a/0x2d0 desanclar páginas de usuario+0x24/0xe0 comprobar y migrar páginas o folios movibles+0x455/0x4b0 __gup_longterm_locked+0x3bf/0x820 ? mmap_read_lock_killable+0x12/0x50 ? __pfx_mmap_read_lock_killable+0x10/0x10 pin_usuario_páginas+0x66/0xa0 gup_test_ioctl+0x358/0xb20 __se_sys_ioctl+0x6b/0xc0 hacer_llamada_al_sistema_64+0x7b/0x150 entrada_SYSCALL_64_después_de_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/numa: se corrige la pérdida de memoria debido a la sobrescritura de vma->numab_state [Descripción del problema] Al ejecutar el programa hackbench de LTP, kmemleak informa la siguiente pérdida de memoria. # /opt/ltp/testcases/bin/hackbench 20 thread 1000 Se ejecuta con 20*40 (== 800) tareas. # dmesg | grep kmemleak ... kmemleak: 480 nuevas fugas de memoria sospechosas (consulte /sys/kernel/debug/kmemleak) kmemleak: 665 nuevas fugas de memoria sospechosas (consulte /sys/kernel/debug/kmemleak) # cat /sys/kernel/debug/kmemleak objeto sin referencia 0xffff888cd8ca2c40 (tamaño 64): comm "hackbench", pid 17142, jiffies 4299780315 volcado hexadecimal (primeros 32 bytes): ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00 .tI.....LI.... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ seguimiento inverso (crc bff18fd4): [] __kmalloc_cache_noprof+0x2f9/0x3f0 [] tarea_numa_work+0x725/0xa00 [] tarea_work_run+0x58/0x90 [] llamada_al_sistema_salir_al_modo_usuario+0x1c8/0x1e0 [] hacer_llamada_al_sistema_64+0x85/0x150 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e ... Este problema se puede reproducir consistentemente en tres servidores diferentes: * un servidor de 448 núcleos * un servidor de 256 núcleos * un servidor de 192 núcleos [Causa raíz] Dado que el programa hackbench crea múltiples subprocesos (junto con el argumento de comando 'thread'), dos o más núcleos pueden acceder simultáneamente a un VMA compartido. Cuando dos o más núcleos observan que vma->numab_state es NULL al mismo tiempo, se sobrescribirá vma->numab_state. Aunque el código actual garantiza que solo un subproceso escanee los VMA en un solo 'numa_scan_period', puede haber una posibilidad de que otro subproceso ingrese en el siguiente 'numa_scan_period' mientras no hayamos obtenido hasta la asignación de numab_state [1]. Tenga en cuenta que el comando `/opt/ltp/testcases/bin/hackbench 50 process 1000` no puede reproducir el problema. Esto se ha verificado con más de 200 ejecuciones de pruebas. [Solución] Utilice la operación atómica cmpxchg para asegurarse de que solo un subproceso ejecute la asignación vma->numab_state. [1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/