Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atm: clip: previene la deref NULL en clip_push(). El commit responsable no detectó que vcc_destroy_socket() llama a clip_push() con un skb NULL. Si clip_devs es NULL, clip_push() se bloquea al leer skb->truesize.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/pkey: Evitar el desbordamiento en el cálculo del tamaño para memdup_user() El número de entradas de la lista de destino apqn contenidas en la variable 'nr_apqns' está determinado por el espacio de usuario a través de una llamada ioctl, por lo que el resultado del producto en el cálculo del tamaño pasado a memdup_user() puede desbordarse. En este caso, el tamaño real del área asignada y el valor que lo describe no estarán sincronizados, lo que provocará varios tipos de comportamiento impredecible más adelante. Utilice un ayudante memdup_array_user() adecuado que devuelva un error si se detecta un desbordamiento. Tenga en cuenta que es diferente de cuando nr_apqns es inicialmente cero: ese caso se considera válido y debe manejarse en implementaciones posteriores de pkey_handler. Encontrado por el Centro de verificación de Linux (linuxtesting.org).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxl/ras: Corregir confusión de dispositivo del controlador CPER Por inspección, cxl_cper_handle_prot_err() está haciendo una serie de suposiciones frágiles que pueden llevar a caídas: 1/ Supone que los endpoints identificados en el registro son un dispositivo CXL-type-3, nada lo garantiza. 2/ Supone que el dispositivo está enlazado al controlador cxl_pci, nada lo garantiza. 3/ Leve, mantiene el bloqueo del dispositivo sobre el seguimiento del puerto del conmutador sin ninguna razón ya que el seguimiento se genera 100% a partir de los datos en el registro. Corrija aquellos comprobando que el endpoint PCIe engendre un cxl_memdev antes de asumir el formato de los datos del controlador y mueva el bloqueo a donde se requiere. En consecuencia, esto también hace que la implementación esté lista para aceleradores CXL que no están enlazados a cxl_pci.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: wacom: corrección de fallo en wacom_aes_battery_handler(). El commit fd2a9b29dc9c ("HID: wacom: Eliminar la fuente de alimentación AES tras una inactividad prolongada") introdujo wacom_aes_battery_handler(), que está programado como un trabajo retrasado (aes_battery_work). En wacom_remove(), aes_battery_work no se cancela. Por lo tanto, si se retira el dispositivo mientras aes_battery_work está pendiente, se producen fallos graves o el error "Uy: fallo de protección general..." al ejecutar wacom_aes_battery_handler(). Por ejemplo, esto ocurre con dispositivos USB integrados tras la reanudación de la hibernación cuando aes_battery_work estaba pendiente en ese momento. Por lo tanto, tenga cuidado de cancelar aes_battery_work en wacom_remove().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se han añadido comprobaciones de seguridad para drm_edid_raw(). Cuando se recupera el EDID mediante drm_edid_raw(), no se garantiza la devolución de los bytes de EDID correctos que el usuario solicita: puede ser nulo (lo que provoca un error) o con bytes demasiado largos que exceden el tamaño fijo de la matriz raw_edid (lo que puede provocar corrupción de memoria). Esto último se informó al conectar con un adaptador defectuoso. Se han añadido comprobaciones de seguridad para drm_edid_raw() para abordar los casos especiales mencionados y devolver EDID_BAD_INPUT en consecuencia. (Seleccionado del commit 648d3f4d209725d51900d6a3ed46b7b600140cdf)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: lib/group_cpus: corrección de la desreferencia de puntero NULL de group_cpus_evenly() Al probar null_blk con configfs, echo 0 > poll_queues activará el siguiente pánico: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000010 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 27 UID: 0 PID: 920 Comm: bash No contaminado 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef) Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__bitmap_or+0x48/0x70 Rastreo de llamadas: __group_cpus_evenly+0x822/0x8c0 group_cpus_evenly+0x2d9/0x490 blk_mq_map_queues+0x1e/0x110 null_map_queues+0xc9/0x170 [null_blk] blk_mq_update_queue_map+0xdb/0x160 blk_mq_update_nr_hw_queues+0x22b/0x560 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_poll_queues_store+0xa4/0x130 [null_blk] configfs_write_iter+0x109/0x1d0 vfs_write+0x26e/0x6f0 ksys_write+0x79/0x180 __x64_sys_write+0x1d/0x30 x64_sys_call+0x45c4/0x45f0 do_syscall_64+0xa5/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e La causa principal es que numgrps está establecido en 0 y se devuelve ZERO_SIZE_PTR desde kcalloc(); posteriormente, se aplicará ZERO_SIZE_PTR. Solucione el problema comprobando primero numgrps en group_cpus_evenly() y devolviendo NULL directamente si numgrps es cero. [yukuai3@huawei.com: corrija también la versión sin SMP]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/rsrc: se corrige la desanclaje de folio. syzbot se queja de un error de desasignación: [ 108.070381][ T14] ¡ERROR del kernel en mm/gup.c:71! [ 108.070502][ T14] Error interno: Ups - ERROR: 00000000f2000800 [#1] SMP [ 108.123672][ T14] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250221-8.fc42 02/21/2025 [ 108.127458][ T14] Workqueue: iou_exit io_ring_exit_work [ 108.174205][ T14] Call trace: [ 108.175649][ T14] sanity_check_pinned_pages+0x7cc/0x7d0 (P) [ 108.178138][ T14] unpin_user_page+0x80/0x10c [ 108.180189][ T14] io_release_ubuf+0x84/0xf8 [ 108.182196][ T14] io_free_rsrc_node+0x250/0x57c [ 108.184345][ T14] io_rsrc_data_free+0x148/0x298 [ 108.186493][ T14] io_sqe_buffers_unregister+0x84/0xa0 [ 108.188991][ T14] io_ring_ctx_free+0x48/0x480 [ 108.191057][ T14] io_ring_exit_work+0x764/0x7d8 [ 108.193207][ T14] process_one_work+0x7e8/0x155c [ 108.195431][ T14] worker_thread+0x958/0xed8 [ 108.197561][ T14] kthread+0x5fc/0x75c [ 108.199362][ T14] ret_from_fork+0x10/0x20 Podemos anclar la página final de un folio, pero entonces io_uring intentará desanclar la página principal. Si bien esto debería funcionar correctamente para mantener la página activa, los usuarios de mm indican que es incorrecto y genera una advertencia de depuración. Use unpin_user_folio() en lugar de unpin_user_page*. [axboe: adaptar al árbol actual, modificar el mensaje de confirmación]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: userfaultfd: corrige la ejecución de userfaultfd_move y la caché de intercambio. Esta confirmación corrige dos tipos de ejecuciones, pueden tener resultados diferentes: Barry informó un BUG_ON en el commit c50f8e6053b0, podemos ver el mismo BUG_ON si la búsqueda del mapa de archivos devolvió NULL y folio se agrega a la caché de intercambio después de eso. Si se activa otro tipo de ejecución (folio modificado tras la búsqueda), es posible que el contador RSS esté dañado: [406.893936] ERROR: Estado incorrecto del contador RSS mm:ffff0000c5a9ddc0 tipo:MM_ANONPAGES val:-1 [406.894071] ERROR: Estado incorrecto del contador RSS mm:ffff0000c5a9ddc0 tipo:MM_SHMEMPAGES val:1 Porque el folio se está contabilizando en la VMA incorrecta. No estoy seguro de si habrá alguna corrupción de datos, aunque parece que no. Los problemas anteriores ya son críticos. Al ver un PTE de entrada de intercambio, userfaultfd_move realiza una búsqueda de caché de intercambio sin bloqueo e intenta mover el folio encontrado a la VMA que falla. Actualmente, se basa en la comprobación del valor de PTE para garantizar que el folio movido siga perteneciendo a la entrada de intercambio src y que no se haya añadido ningún folio nuevo a la caché de intercambio, lo cual resulta poco fiable. Al trabajar y revisar la serie de tablas de intercambio con Barry, se observan y reproducen las siguientes ejecuciones existentes [1]: En el siguiente ejemplo, move_pages_pte mueve src_pte a dst_pte, donde src_pte es una PTE de entrada de intercambio que contiene la entrada de intercambio S1, y S1 no está en la caché de intercambio: CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Aquí tiene entrada = S1 ... ... // folio A es un nuevo folio asignado // y se instala en src_pte // src_pte ahora apunta al folio A, S1 // tiene conteo de intercambio == 0, puede liberarse // mediante folio_swap_swap o la recuperación del asignador de intercambio. // folio B es un folio en otro VMA. // S1 se libera, el folio B puede usarlo // para intercambiar sin problemas. ... folio = filemap_get_folio(S1) // ¡¡¡Tengo el folio B aquí!!! ... ... // Ahora S1 está libre para volver a usarse. // Ahora src_pte es una entrada de intercambio PTE // que mantiene S1 de nuevo. folio_trylock(folio) move_swap_pte double_pt_lock is_pte_pages_stable // Comprobación aprobada porque src_pte == S1 folio_move_anon_rmap(...) // ¡¡¡Se movió el folio B inválido aquí!!! La ventana de ejecución es muy corta y requiere múltiples colisiones de múltiples eventos raros, por lo que es muy improbable que suceda, pero con un reproductor construido deliberadamente y una ventana de tiempo mayor, se puede reproducir fácilmente. Esto se puede arreglar comprobando si el folio devuelto por filemap es el folio de caché de intercambio válido después de adquirir el bloqueo de folio. Otra ejecución similar es posible: filemap_get_folio puede devolver NULL, pero el folio (A) podría intercambiarse dentro y fuera de nuevo usando la misma entrada de intercambio después de la búsqueda. En tal caso, el folio (A) puede permanecer en el caché de intercambio, por lo que también debe moverse: CPU1 CPU2 userfaultfd_move move_pages_pte() entry = pte_to_swp_entry(orig_src_pte); // Aquí obtuvo entry = S1, y S1 no está en el caché de intercambio folio = filemap_get ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de desreferencias de punteros inodos no válidos durante la reproducción de registros. En algunos casos, al ejecutar read_one_inode(), si se obtiene un puntero nulo, se accede a una ruta de error o a una ruta de paso en el caso de __add_inode_ref(). En este caso, se realiza algo como: iput(&inode->vfs_inode);, lo que genera un puntero inodo no válido que desencadena un acceso no válido a memoria y provoca un fallo. Para solucionar esto, es necesario asegurarse de no realizar dichas desreferencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atm: Liberar atm_dev_mutex después de eliminar procfs en atm_dev_deregister(). syzbot reportó una advertencia a continuación durante atm_dev_register(). [0] Antes de crear un nuevo dispositivo y procfs/sysfs para él, atm_dev_register() busca un dispositivo duplicado por __atm_dev_lookup(). Estas operaciones se realizan bajo atm_dev_mutex. Sin embargo, al eliminar un dispositivo en atm_dev_deregister(), libera el mutex justo después de eliminar el dispositivo de la lista que __atm_dev_lookup() itera. Por lo tanto, habrá una pequeña ventana de ejecución donde el dispositivo no existe en la lista de dispositivos pero los procfs/sysfs aún no se eliminan, lo que activa el splat. Mantengamos el mutex hasta que se eliminen procfs/sysfs en atm_dev_deregister(). [0]: proc_dir_entry 'atm/atmtcp:0' ya está registrado ADVERTENCIA: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377 Modules linked in: CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377 Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48 RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248 RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001 RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140 R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444 FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: proc_create_data+0xbe/0x110 fs/proc/generic.c:585 atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361 atm_dev_register+0x46d/0x890 net/atm/resources.c:113 atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369 atmtcp_attach drivers/atm/atmtcp.c:403 [inline] atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x115/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f38b3b74459 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 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 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459 RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005 RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0ac R13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt: vaciar correctamente las listas de redireccionamiento de XDP Encontramos el siguiente fallo al probar una característica XDP_REDIRECT en producción: [56251.579676] corrupción de list_add. next->prev debería ser prev (ffff93120dd40f30), pero era ffffb301ef3a6740. (next=ffff93120dd 40f30). [56251.601413] ------------[ cortar aquí ]------------ [56251.611357] kernel BUG at lib/list_debug.c:29! [56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P O 6.12.33-cloudflare-2025.6. 3 #1 [56251.653155] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE [56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025 [56251.682626] RIP: 0010:__list_add_valid_or_report+0x4b/0xa0 [56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48 89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89 [56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246 [56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000 [56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80 [56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18 [56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000 [56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40 [56251.796278] FS: 0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000 [56251.809133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0 [56251.831365] PKRU: 55555554 [56251.838653] Call Trace: [56251.845560] [56251.851943] cpu_map_enqueue.cold+0x5/0xa [56251.860243] xdp_do_redirect+0x2d9/0x480 [56251.868388] bnxt_rx_xdp+0x1d8/0x4c0 [bnxt_en] [56251.877028] bnxt_rx_pkt+0x5f7/0x19b0 [bnxt_en] [56251.885665] ? cpu_max_write+0x1e/0x100 [56251.893510] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.902276] __bnxt_poll_work+0x190/0x340 [bnxt_en] [56251.911058] bnxt_poll+0xab/0x1b0 [bnxt_en] [56251.919041] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.927568] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.935958] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.944250] __napi_poll+0x2b/0x160 [56251.951155] bpf_trampoline_6442548651+0x79/0x123 [56251.959262] __napi_poll+0x5/0x160 [56251.966037] net_rx_action+0x3d2/0x880 [56251.973133] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.981265] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.989262] ? __hrtimer_run_queues+0x162/0x2a0 [56251.996967] ? srso_alias_return_thunk+0x5/0xfbef5 [56252.004875] ? srso_alias_return_thunk+0x5/0xfbef5 [56252.012673] ? bnxt_msix+0x62/0x70 [bnxt_en] [56252.019903] handle_softirqs+0xcf/0x270 [56252.026650] irq_exit_rcu+0x67/0x90 [56252.032933] common_interrupt+0x85/0xa0 [56252.039498] [56252.044246] [56252.048935] asm_common_interrupt+0x26/0x40 [56252.055727] RIP: 0010:cpuidle_enter_state+0xb8/0x420 [56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae 01 00 00 fb 45 85 f6 <0f> 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29 [56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202 [56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000 [56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000 [56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e [56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860 [56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000 [56252.146667] ? cpuidle_enter_state+0xab/0x420 [56252.153909] cpuidle_enter+0x2d/0x40 [56252.160360] do_idle+0x176/0x1c0 [56252.166456 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/shmem, swap: corregir bloqueo suave con swapin mTHP El siguiente bloqueo suave se puede reproducir fácilmente en mi máquina de prueba con: echo always > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled swapon /dev/zram0 # zram0 es un dispositivo de intercambio de 48G mkdir -p /sys/fs/cgroup/memory/test echo 1G > /sys/fs/cgroup/test/memory.max echo $BASHPID > /sys/fs/cgroup/test/cgroup.procs while true; hacer dd if=/dev/zero of=/tmp/test.img bs=1M count=5120 cat /tmp/test.img > /dev/null rm /tmp/test.img done Luego de un rato: watchdog: BUG: bloqueo suave - ¡CPU#0 bloqueada durante 763 s! [cat:5787] Módulos vinculados: zram virtiofs CPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: cargado Contaminado: GL 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntario)· Contaminado: [L]=SOFTLOCKUP Nombre del hardware: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015 RIP: 0010:mpol_shared_policy_lookup+0xd/0x70 Code: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 <48> 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8 RSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202 RAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001 RDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518 RBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001 R13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000 FS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: shmem_alloc_folio+0x31/0xc0 shmem_swapin_folio+0x309/0xcf0 ? filemap_get_entry+0x117/0x1e0 ? xas_load+0xd/0xb0 ? filemap_get_entry+0x101/0x1e0 shmem_get_folio_gfp+0x2ed/0x5b0 shmem_file_read_iter+0x7f/0x2e0 vfs_read+0x252/0x330 ksys_read+0x68/0xf0 do_syscall_64+0x4c/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f03f9a46991 Code: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec RSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991 RDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003 RBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 R13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000 La razón es simple, la lectura anticipada trajo algún folio de orden 0 en la caché de intercambio y El folio mTHP de intercambio que se está asignando entra en conflicto con él, por lo que swapcache_prepare falla y provoca que shmem_swap_alloc_folio devuelva -EEXIST, y shmem simplemente reintenta una y otra vez, causando este bucle. Se puede solucionar aplicando una solución similar para el intercambio mTHP anónimo. El cambio de rendimiento es muy leve; tiempo de intercambio 10g cero folios con shmem (prueba realizada 12 veces): Antes: 2.47 s Después: 2.48 s [kasong@tencent.com: añadir comentario]