Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige el error al reconstruir el árbol de espacio libre utilizando múltiples transacciones Si estamos reconstruyendo un árbol de espacio libre, mientras modificamos el árbol de espacio libre, es posible que necesitemos asignar un nuevo grupo de bloques de metadatos. Si terminamos utilizando múltiples transacciones para la reconstrucción, cuando llamamos a btrfs_end_transaction() ingresamos btrfs_create_pending_block_groups() que llama a add_block_group_free_space() para agregar elementos al árbol de espacio libre para el grupo de bloques. Luego, más tarde durante la reconstrucción del árbol de espacio libre, en btrfs_rebuild_free_space_tree(), podemos encontrar dichos nuevos grupos de bloques y llamar a populate_free_space_tree() para ellos, lo que falla con -EEXIST porque ya hay elementos en el árbol de espacio libre. Luego abortamos la transacción con -EEXIST en btrfs_rebuild_free_space_tree(). Tenga en cuenta que decimos "puede encontrar" los nuevos grupos de bloques porque se puede insertar un nuevo grupo de bloques en el árbol de grupos de bloques, que está siendo iterado por el proceso de reconstrucción, antes o después del nodo actual en el que se encuentra actualmente el proceso de reconstrucción. Syzbot informó recientemente de un caso similar que produce un seguimiento como el siguiente: ------------[ cut here ]------------ BTRFS: Transaction aborted (error -17) WARNING: CPU: 1 PID: 7626 at fs/btrfs/free-space-tree.c:1341 btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 Modules linked in: CPU: 1 UID: 0 PID: 7626 Comm: syz.2.25 Not tainted 6.15.0-rc7-syzkaller-00085-gd7fa1af5b33e-dirty #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 lr : btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 sp : ffff80009c4f7740 x29: ffff80009c4f77b0 x28: ffff0000d4c3f400 x27: 0000000000000000 x26: dfff800000000000 x25: ffff70001389eee8 x24: 0000000000000003 x23: 1fffe000182b6e7b x22: 0000000000000000 x21: ffff0000c15b73d8 x20: 00000000ffffffef x19: ffff0000c15b7378 x18: 1fffe0003386f276 x17: ffff80008f31e000 x16: ffff80008adbe98c x15: 0000000000000001 x14: 1fffe0001b281550 x13: 0000000000000000 x12: 0000000000000000 x11: ffff60001b281551 x10: 0000000000000003 x9 : 1c8922000a902c00 x8 : 1c8922000a902c00 x7 : ffff800080485878 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff80008047843c x2 : 0000000000000001 x1 : ffff80008b3ebc40 x0 : 0000000000000001 Call trace: btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 (P) btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074 btrfs_remount_rw fs/btrfs/super.c:1319 [inline] btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543 reconfigure_super+0x1d4/0x6f0 fs/super.c:1083 do_remount fs/namespace.c:3365 [inline] path_mount+0xb34/0xde0 fs/namespace.c:4200 do_mount fs/namespace.c:4221 [inline] __do_sys_mount fs/namespace.c:4432 [inline] __se_sys_mount fs/namespace.c:4409 [inline] __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 irq event stamp: 330 hardirqs last enabled at (329): [] raw_spin_rq_unlock_irq kernel/sched/sched.h:1525 [inline] hardirqs last enabled at (329): [] finish_lock_switch+0xb0/0x1c0 kernel/sched/core.c:5130 hardirqs last disabled at (330): [] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:511 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: Comprobar la disponibilidad de la cola de trabajo asignada por el controlador wq de idxd antes de usarla. Ejecutar cargas de trabajo IDXD en un contenedor con el directorio /dev montado puede provocar un seguimiento de llamadas o incluso un pánico del kernel cuando finaliza el proceso principal del contenedor. Este problema se produce porque, en ciertas configuraciones, Docker no propaga correctamente la réplica de montaje al punto de montaje original. En este caso, al desconectarse el controlador de usuario, la cola de trabajo se destruye, pero sigue llamando a destroy_workqueue() para intentar completar todo el trabajo pendiente. Es necesario comprobar wq->wq y omitir el vaciado si ya no existe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige una ejecución entre los cambios de nombre y el registro de directorios Tenemos una ejecución entre un cambio de nombre y el registro del inodo del directorio que, si ocurre y nos bloqueamos o falla la energía antes de que se complete el cambio de nombre, la próxima vez que se monte el sistema de archivos, el código de reproducción del registro terminará eliminando el archivo que se estaba cambiando de nombre. Esto se explica mejor siguiendo un análisis paso a paso de un intercalado de pasos que conducen a esta situación. Considere las condiciones iniciales: 1) Estamos en la transacción N; 2) Tenemos los directorios A y B creados en una transacción anterior (< N); 3) Tenemos el inodo X correspondiente a un archivo que tiene 2 enlaces duros, uno en el directorio A y el otro en el directorio B, por lo que los nombraremos como "A/foo_link1" y "B/foo_link2". Ambos enlaces duros persistieron en una transacción anterior (< N); 4) Tenemos el inodo Y, correspondiente a un archivo con un único enlace físico ubicado en el directorio A, al que llamaremos "A/bar". Este archivo también se conservó en una transacción anterior (< N). Los pasos que conducen a la pérdida del archivo son los siguientes, y para todos ellos, estamos en la transacción N: 1) Se elimina el enlace "A/foo_link1", por lo que el campo X last_unlink_trans del inodo se actualiza a N mediante btrfs_unlink() -> btrfs_record_unlink_dir(); 2) La tarea A inicia un cambio de nombre para el inodo Y, con el objetivo de cambiar de "A/bar" a "A/baz", por lo que introducimos btrfs_rename(); 3) La tarea A inserta la nueva clave BTRFS_INODE_REF_KEY para el inodo Y mediante la llamada a btrfs_insert_inode_ref(); 4) Debido a que el cambio de nombre ocurre en el mismo directorio, no establecemos el campo last_unlink_trans del inodo del directorio A en el id de transacción actual, es decir, no llamamos a btrfs_record_unlink_dir(); 5) Luego, la tarea A elimina las entradas del directorio A (elementos BTRFS_DIR_ITEM_KEY y BTRFS_DIR_INDEX_KEY) cuando llama a __btrfs_unlink_inode() (en realidad, el elemento de índice del directorio se agrega como un elemento retrasado, pero el efecto es el mismo); 6) Ahora, antes de que la tarea A agregue la nueva entrada "A/baz" al directorio A llamando a btrfs_add_link(), otra tarea, la tarea B, está registrando el inodo X; 7) La tarea B inicia una sincronización fsync del inodo X y, tras registrarlo, en btrfs_log_inode_parent() llama a btrfs_log_all_parents(), ya que el inodo X tiene un valor de last_unlink_trans de N, establecido en el paso 1. 8) En btrfs_log_all_parents() buscamos todos los directorios padre del inodo X utilizando un root commit, por lo que encontramos los directorios A y B y los registramos. Sin embargo, al registrar directamente A, ya no tenemos un elemento de índice de directorio para el inodo Y, ni para el nombre antiguo "A/bar" ni para el nuevo nombre "A/baz", ya que el cambio de nombre ha eliminado el nombre antiguo, pero aún no ha insertado el nuevo. La tarea A aún no ha llamado a btrfs_add_link() para hacerlo. Tenga en cuenta que registrar el directorio A no recurre a un commit de transacción porque su valor de last_unlink_trans es menor que el ID de la transacción actual (véase el paso 4). 9) La tarea B finaliza el registro de los directorios A y B y regresa a btrfs_sync_file(), donde invoca btrfs_sync_log() para persistir el árbol de registro. 10) La tarea B persistió correctamente el árbol de registro, btrfs_sync_log() se completó correctamente y se produjo un corte de energía. Tenemos un árbol de registro sin ninguna entrada de directorio para el inodo Y, por lo que el código de reproducción del registro elimina la entrada del inodo Y, llamada "A/bar", del árbol de subvolumen, ya que no existe en el árbol de registro y este es autoritario para su índice (registramos un elemento BTRFS_DIR_LOG_INDEX_KEY que cubre el rango de índices de la entrada dentry correspondiente a "A/bar"). ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: maple_tree: corrección del indicador MA_STATE_PREALLOC en mas_preallocate(). Borra temporalmente el indicador de preasignación al solicitar asignaciones explícitamente. Las asignaciones preexistentes ya se contabilizan en la solicitud mediante mas_node_count_gfp(), pero las asignaciones no se realizarán si el indicador MA_STATE_PREALLOC está activado. Este indicador evita la reasignación en modo de asignación masiva y detecta problemas con los cálculos de preasignación. El indicador MA_STATE_PREALLOC debe estar siempre activado en asignaciones cero para que la detección de asignaciones por desbordamiento imprima un WARN_ON() durante el consumo. El efecto visible para el usuario de esta falla es un WARN_ON() seguido de una desreferencia de puntero nulo cuando se ignoran solicitudes posteriores de un mayor número de nodos, como el reintento de fusión de vma en mmap_region() causado por controladores que alteran los indicadores de vma (al menos en la versión 6.6).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/tegra: Se corrige una posible desreferencia de puntero nulo. En tegra_crtc_reset(), se asigna nueva memoria con kzalloc(), pero no se realiza ninguna comprobación. Antes de llamar a __drm_atomic_helper_crtc_reset, se debe comprobar el estado para evitar una posible desreferencia de puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se ha añadido una comprobación de puntero nulo para get_first_active_display(). La función mod_hdcp_hdcp1_enable_encryption() llama a la función get_first_active_display(), pero no comprueba su valor de retorno. El valor de retorno es un puntero nulo si la lista de visualización está vacía. Esto provocará una desreferencia de puntero nulo en mod_hdcp_hdcp2_enable_encryption(). Se ha añadido una comprobación de puntero nulo para get_first_active_display() y se ha devuelto MOD_HDCP_STATUS_DISPLAY_NOT_FOUND si la función devuelve un valor nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/guc: Salida explícita del modo seguro CT al desenrollar. Durante la prueba del controlador, podríamos usar brevemente el modo seguro CT, que se basa en un trabajo retrasado, pero normalmente podemos detenerlo una vez que IRQ esté completamente operativo. Sin embargo, si cancelamos la prueba antes de tiempo, durante la desenrollación podríamos intentar destruir la cola de trabajos mientras aún haya un trabajo retrasado pendiente que intenta reiniciarse, lo que activa una advertencia. Esto se observó recientemente durante una inicialización de VF fallida: [ ] xe 0000:00:02.1: probe with driver xe failed with error -62 [ ] ------------[ cut here ]------------ [ ] workqueue: cannot queue safe_mode_worker_func [xe] on wq xe-g2h-wq [ ] WARNING: CPU: 9 PID: 0 at kernel/workqueue.c:2257 __queue_work+0x287/0x710 [ ] RIP: 0010:__queue_work+0x287/0x710 [ ] Call Trace: [ ] delayed_work_timer_fn+0x19/0x30 [ ] call_timer_fn+0xa1/0x2a0 Salga del modo seguro de CT al desenrollar para evitar esa advertencia. (seleccionado del commit 2ddbb73ec20b98e70a5200cb85deade22ccea2ec)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Proceso diferido de eliminaciones de nodos GGTT al desenrollar el dispositivo Mientras drenamos indirectamente nuestra cola de trabajo dedicada ggtt->wq que usamos para completar la eliminación asincrónica de algunos nodos GGTT, esto sucede como parte del desenrollado de managed-drm (ggtt_fini_early), que podría ser posterior al desenrollado de managed-device, donde ya podríamos desasignar nuestra asignación MMIO/GMS (mmio_fini). Esto se observó recientemente durante una inicialización de VF fallida: [ ] xe 0000:00:02.1: probe with driver xe failed with error -62 [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747340 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747540 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747240 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747040 tiles_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746840 mmio_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747f40 xe_bo_pinned_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746b40 devm_drm_dev_init_release (16 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] drmres release begin [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef81640 __fini_relay (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80d40 guc_ct_fini (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80040 __drmm_mutex_release (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80140 ggtt_fini_early (8 bytes) and this was leading to: [ ] BUG: unable to handle page fault for address: ffffc900058162a0 [ ] #PF: supervisor write access in kernel mode [ ] #PF: error_code(0x0002) - not-present page [ ] Oops: Oops: 0002 [#1] SMP NOPTI [ ] Tainted: [W]=WARN [ ] Workqueue: xe-ggtt-wq ggtt_node_remove_work_func [xe] [ ] RIP: 0010:xe_ggtt_set_pte+0x6d/0x350 [xe] [ ] Call Trace: [ ] [ ] xe_ggtt_clear+0xb0/0x270 [xe] [ ] ggtt_node_remove+0xbb/0x120 [xe] [ ] ggtt_node_remove_work_func+0x30/0x50 [xe] [ ] process_one_work+0x22b/0x6f0 [ ] worker_thread+0x1e8/0x3d Se agregó una acción de dispositivo administrado que drenará explícitamente la cola de trabajo con todas las eliminaciones de nodos pendientes antes de liberar la asignación de MMIO/GSM. (Seleccionado del commit 89d2835c3680ab1938e22ad81b1c9f8c686bd391)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se han añadido más comprobaciones para las garantías de DSC/HUBP ONO [WHY] En instancias DSC con valores distintos de cero, es posible que no se cumpla el dominio HUBP necesario para controlarlas en ASIC ONO secuenciales, lo que podría provocar que la lógica del mosaico entre en un estado indefinido y provoque un bloqueo del sistema. [HOW] Se han añadido más comprobaciones para garantizar que el dominio HUBP correspondiente a la instancia DSC reciba la alimentación adecuada. (Seleccionado del commit da63df07112e5a9857a8d2aaa04255c4206754ec)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/mm: Se corrige la gestión de in_atomic() en do_secure_storage_access(). Los accesos a espacios de usuario del kernel a páginas no exportadas en contexto atómico intentan resolver incorrectamente el fallo de página. Con las opciones de depuración habilitadas, se pueden observar seguimientos de llamadas como este: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39 preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. Preemption disabled at: [<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0 CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39 Tainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT Tainted: [W]=WARN Hardware name: IBM 3931 A01 703 (LPAR) Call Trace: [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8 [<00000383e99bf152>] __might_resched+0x292/0x2d0 [<00000383eaa7c374>] down_read+0x34/0x2d0 [<00000383e99432f8>] do_secure_storage_access+0x108/0x360 [<00000383eaa724b0>] __do_pgm_check+0x130/0x220 [<00000383eaa842e4>] pgm_check_handler+0x114/0x160 [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0 ([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0) [<00000383e9c45eae>] generic_perform_write+0x16e/0x310 [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160 [<00000383e9da0de4>] vfs_write+0x1c4/0x460 [<00000383e9da123c>] ksys_write+0x7c/0x100 [<00000383eaa7284e>] __do_syscall+0x15e/0x280 [<00000383eaa8417e>] system_call+0x6e/0x90 INFO: lockdep is turned off. No se permite usar mmap_lock en contexto atómico. Por lo tanto, se gestiona un fallo de acceso al almacenamiento seguro como si la página accedida no estuviera mapeada: la función uaccess devolverá -EFAULT, y el usuario que realiza la llamada debe gestionarlo. Normalmente, esto significa que se reintenta el acceso en contexto de proceso, lo que permite resolver el fallo de página (o, en este caso, exportar la página).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de la ejecución entre el trabajador de recuperación asíncrono y close_ctree() Syzbot informó de un error de aserción debido a un intento de agregar una entrada retrasada después de que hayamos establecido BTRFS_FS_STATE_NO_DELAYED_IPUT en el estado WARNING: CPU: 0 PID: 65 at fs/btrfs/inode.c:3420 btrfs_add_delayed_iput+0x2f8/0x370 fs/btrfs/inode.c:3420 Modules linked in: CPU: 0 UID: 0 PID: 65 Comm: kworker/u8:4 Not tainted 6.15.0-next-20250530-syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Workqueue: btrfs-endio-write btrfs_work_helper RIP: 0010:btrfs_add_delayed_iput+0x2f8/0x370 fs/btrfs/inode.c:3420 Code: 4e ad 5d (...) RSP: 0018:ffffc9000213f780 EFLAGS: 00010293 RAX: ffffffff83c635b7 RBX: ffff888058920000 RCX: ffff88801c769e00 RDX: 0000000000000000 RSI: 0000000000000100 RDI: 0000000000000000 RBP: 0000000000000001 R08: ffff888058921b67 R09: 1ffff1100b12436c R10: dffffc0000000000 R11: ffffed100b12436d R12: 0000000000000001 R13: dffffc0000000000 R14: ffff88807d748000 R15: 0000000000000100 FS: 0000000000000000(0000) GS:ffff888125c53000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 ---truncado--- Call Trace: btrfs_put_ordered_extent+0x19f/0x470 fs/btrfs/ordered-data.c:635 btrfs_finish_one_ordered+0x11d8/0x1b10 fs/btrfs/inode.c:3312 btrfs_work_helper+0x399/0xc20 fs/btrfs/async-thread.c:312 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x70e/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Esto puede suceder debido a una ejecución con el trabajador de recuperación asíncrono como este: 1) El trabajador de recuperación de metadatos asíncrono ingresa a shrink_delalloc(), que llama a btrfs_start_delalloc_roots() con un argumento nr_pages que tiene un valor menor que LONG_MAX, y que a su vez ingresa a start_delalloc_inodes(), que establece la variable local 'full_flush' en falso porque wbc->nr_to_write es menor que LONG_MAX; 2) Allí encuentra el inodo X en una lista delalloc de la raíz, toma una referencia para el inodo X (con igrab()), y activa la escritura diferida para él con filemap_fdatawrite_wbc(), que crea una extensión ordenada para el inodo X; 3) La secuencia de desmontaje comienza desde otra tarea, ingresamos close_ctree() y limpiamos la cola de trabajo fs_info->endio_write_workers, que espera a que se complete la extensión ordenada para el inodo X y cuando eliminamos la última referencia de la extensión ordenada, con btrfs_put_ordered_extent(), cuando llamamos a btrfs_add_delayed_iput() no agregamos el inodo a la lista de entradas retrasadas porque tiene un refcount de 2, por lo que lo decrementamos a 1 y regresamos; 4) Poco después, en close_ctree(), llamamos a btrfs_run_delayed_iputs(), que ejecuta todas las entradas retrasadas, y luego establecemos BTRFS_FS_STATE_NO_DELAYED_IPUT en el estado fs_info. 5) El trabajador de recuperación asíncrono, después de llamar a filemap_fdatawrite_wbc(), ahora llama a btrfs_add_delayed_iput() para el inodo X y allí desencadenamos un error de aserción, ya que el estado fs_info tiene el indicador BTRFS_FS_STATE_NO_DELAYED_IPUT establecido. Solucione esto estableciendo BTRFS_FS_STATE_NO_DELAYED_IPUT solo después de esperar a que finalicen los trabajadores de recuperación asíncronos, después de llamar a cancel_work_sync() para ellos en close_ctree(), y ejecutando las entradas retrasadas después de esperar a que finalicen los trabajadores de recuperación y antes de establecer el bit. Esta ejecución se introdujo recientemente mediante el commit 19e60b2a95f5 ("btrfs: añadir una advertencia adicional si se añade una entrada retardada cuando no está permitida"). Sin la nueva validación en btrfs_add_delayed_iput(), ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fuse: corrección de la advertencia de tiempo de ejecución en truncate_folio_batch_exceptionals(). Se introduce WARN_ON_ONCE en truncate_folio_batch_exceptionals() para detectar si el sistema de archivos ha eliminado todas las entradas DAX. La corrección se ha aplicado a los sistemas de archivos xfs y ext4 mediante el commit 0e2f80afcfa6 ("fs/dax: asegurar que todas las páginas estén inactivas antes de desmontar el sistema de archivos"). Aplique la corrección que faltó en el fusible del sistema de archivos para corregir la advertencia de tiempo de ejecución: [ 2.011450] ------------[ cut here ]------------ [ 2.011873] WARNING: CPU: 0 PID: 145 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0x272/0x2b0 [ 2.012468] Modules linked in: [ 2.012718] CPU: 0 UID: 1000 PID: 145 Comm: weston Not tainted 6.16.0-rc2-WSL2-STABLE #2 PREEMPT(undef) [ 2.013292] RIP: 0010:truncate_folio_batch_exceptionals+0x272/0x2b0 [ 2.013704] Code: 48 63 d0 41 29 c5 48 8d 1c d5 00 00 00 00 4e 8d 6c 2a 01 49 c1 e5 03 eb 09 48 83 c3 08 49 39 dd 74 83 41 f6 44 1c 08 01 74 ef <0f> 0b 49 8b 34 1e 48 89 ef e8 10 a2 17 00 eb df 48 8b 7d 00 e8 35 [ 2.014845] RSP: 0018:ffffa47ec33f3b10 EFLAGS: 00010202 [ 2.015279] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 2.015884] RDX: 0000000000000000 RSI: ffffa47ec33f3ca0 RDI: ffff98aa44f3fa80 [ 2.016377] RBP: ffff98aa44f3fbf0 R08: ffffa47ec33f3ba8 R09: 0000000000000000 [ 2.016942] R10: 0000000000000001 R11: 0000000000000000 R12: ffffa47ec33f3ca0 [ 2.017437] R13: 0000000000000008 R14: ffffa47ec33f3ba8 R15: 0000000000000000 [ 2.017972] FS: 000079ce006afa40(0000) GS:ffff98aade441000(0000) knlGS:0000000000000000 [ 2.018510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.018987] CR2: 000079ce03e74000 CR3: 000000010784f006 CR4: 0000000000372eb0 [ 2.019518] Call Trace: [ 2.019729] [ 2.019901] truncate_inode_pages_range+0xd8/0x400 [ 2.020280] ? timerqueue_add+0x66/0xb0 [ 2.020574] ? get_nohz_timer_target+0x2a/0x140 [ 2.020904] ? timerqueue_add+0x66/0xb0 [ 2.021231] ? timerqueue_del+0x2e/0x50 [ 2.021646] ? __remove_hrtimer+0x39/0x90 [ 2.022017] ? srso_alias_untrain_ret+0x1/0x10 [ 2.022497] ? psi_group_change+0x136/0x350 [ 2.023046] ? _raw_spin_unlock+0xe/0x30 [ 2.023514] ? finish_task_switch.isra.0+0x8d/0x280 [ 2.024068] ? __schedule+0x532/0xbd0 [ 2.024551] fuse_evict_inode+0x29/0x190 [ 2.025131] evict+0x100/0x270 [ 2.025641] ? _atomic_dec_and_lock+0x39/0x50 [ 2.026316] ? __pfx_generic_delete_inode+0x10/0x10 [ 2.026843] __dentry_kill+0x71/0x180 [ 2.027335] dput+0xeb/0x1b0 [ 2.027725] __fput+0x136/0x2b0 [ 2.028054] __x64_sys_close+0x3d/0x80 [ 2.028469] do_syscall_64+0x6d/0x1b0 [ 2.028832] ? clear_bhb_loop+0x30/0x80 [ 2.029182] ? clear_bhb_loop+0x30/0x80 [ 2.029533] ? clear_bhb_loop+0x30/0x80 [ 2.029902] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 2.030423] RIP: 0033:0x79ce03d0d067 [ 2.030820] Code: b8 ff ff ff ff e9 3e ff ff ff 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 c3 a7 f8 ff [ 2.032354] RSP: 002b:00007ffef0498948 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ 2.032939] RAX: ffffffffffffffda RBX: 00007ffef0498960 RCX: 000079ce03d0d067 [ 2.033612] RDX: 0000000000000003 RSI: 0000000000001000 RDI: 000000000000000d [ 2.034289] RBP: 00007ffef0498a30 R08: 000000000000000d R09: 0000000000000000 [ 2.034944] R10: 00007ffef0498978 R11: 0000000000000246 R12: 0000000000000001 [ 2.035610] R13: 00007ffef0498960 R14: 000079ce03e09ce0 R15: 0000000000000003 [ 2.036301] [ 2.036532] ---[ end trace 0000000000000000 ]---