Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/mlx5: Arreglar un posible bloqueo en la anulación del registro de MR El problema surge cuando se invoca kzalloc() mientras se mantiene umem_mutex o cualquier otro bloqueo adquirido bajo umem_mutex. Esto es problemático porque kzalloc() puede activar fs_reclaim_aqcuire(), que puede, a su vez, invocar mmu_notifier_invalidate_range_start(). Esta función puede llevar a mlx5_ib_invalidate_range(), que intenta adquirir umem_mutex de nuevo, lo que resulta en un bloqueo. El flujo problemático: CPU0 | CPU1 ---------------------------------------|------------------------------------------------ mlx5_ib_dereg_mr() | ? revoke_mr() | ? mutex_lock(&umem_odp->umem_mutex) | | mlx5_mkey_cache_init() | ? mutex_lock(&dev->cache.rb_lock) | ? mlx5r_cache_create_ent_locked() | ? kzalloc(GFP_KERNEL) | ? fs_reclaim() | ? mmu_notifier_invalidate_range_start() | ? mlx5_ib_invalidate_range() | ? mutex_lock(&umem_odp->umem_mutex) ? cache_ent_find_and_store() | ? mutex_lock(&dev->cache.rb_lock) | Además, cuando se llama a kzalloc() desde dentro de cache_ent_find_and_store(), encontramos el mismo bloqueo debido a la readquisición de umem_mutex. Se resuelve liberando umem_mutex en dereg_mr() después de umr_revoke_mr() y antes de adquirir rb_lock. Esto garantiza que no se mantenga umem_mutex mientras se realizan asignaciones de memoria que podrían activar la ruta de recuperación. Este cambio previene el interbloqueo al asegurar el orden correcto de los bloqueos y evitar mantenerlos durante las operaciones de asignación de memoria que podrían activar la ruta de recuperación. La siguiente advertencia de lockdep demuestra el bloqueo: ython3/20557 is trying to acquire lock: ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at: mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib] but task is already holding lock: ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es:-> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x60/0xd0 mem_cgroup_css_alloc+0x6f/0x9b0 cgroup_init_subsys+0xa4/0x240 cgroup_init+0x1c8/0x510 start_kernel+0x747/0x760 x86_64_start_reservations+0x25/0x30 x86_64_start_kernel+0x73/0x80 common_startup_64+0x129/0x138 -> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x91/0xd0 __kmalloc_cache_noprof+0x4d/0x4c0 mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib] mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib] mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib] __mlx5_ib_add+0x4b/0x190 [mlx5_ib] mlx5r_probe+0xd9/0x320 [mlx5_ib] auxiliary_bus_probe+0x42/0x70 really_probe+0xdb/0x360 __driver_probe_device+0x8f/0x130 driver_probe_device+0x1f/0xb0 __driver_attach+0xd4/0x1f0 bus_for_each_dev+0x79/0xd0 bus_add_driver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliary_driver_register+0x6a/0xc0 do_one_initcall+0x5e/0x390 do_init_module+0x88/0x240 init_module_from_file+0x85/0xc0 idempotent_init_module+0x104/0x300 __x64_sys_finit_module+0x68/0xc0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib] mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib] ib_dereg_mr_user+0x85/0x1f0 [ib_core] ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: optee: ffa: corrección de suspensión en contexto atómico. El controlador OP-TEE registra la función notif_callback() para las notificaciones FF-A. Sin embargo, esta función se llama en un contexto atómico, lo que genera errores como este al procesar notificaciones asíncronas: | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0-00019-g657536ebe0aa #13 | Hardware name: linux,dummy-virt (DT) | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn | Call trace: | show_stack+0x18/0x24 (C) | dump_stack_lvl+0x78/0x90 | dump_stack+0x18/0x24 | __might_resched+0x114/0x170 | __might_sleep+0x48/0x98 | mutex_lock+0x24/0x80 | optee_get_msg_arg+0x7c/0x21c | simple_call_with_arg+0x50/0xc0 | optee_do_bottom_half+0x14/0x20 | notif_callback+0x3c/0x48 | handle_notif_callbacks+0x9c/0xe0 | notif_get_and_handle+0x40/0x88 | generic_exec_single+0x80/0xc0 | smp_call_function_single+0xfc/0x1a0 | notif_pcpu_irq_work_fn+0x2c/0x38 | process_one_work+0x14c/0x2b4 | worker_thread+0x2e4/0x3e0 | kthread+0x13c/0x210 | ret_from_fork+0x10/0x20 Solucione esto agregando una cola de trabajo para procesar la notificación en un contexto no atómico.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: chipidea: udc: desconectar/reconectar del host al suspender/reanudar Shawn y John informaron de un problema de cuelgue durante la suspensión del sistema como se muestra a continuación: - El dispositivo USB está habilitado como Ethernet - Hay transferencia de datos a través de USB Ethernet (scp un archivo grande entre el host y el dispositivo) - El dispositivo entra/sale de suspensión (echo mem > /sys/power/state) La causa raíz es que el controlador del dispositivo USB está suspendido, pero el bus USB sigue activo, lo que provocó que el host USB siguiera transfiriendo datos con el dispositivo y el dispositivo siguiera poniendo en cola las solicitudes USB (en este caso, un paquete TCP ACK retrasado desencadenó el problema) después de que el controlador se suspendiera; sin embargo, el reloj del controlador USB ya estaba desactivado. Entonces, si el acceso al controlador udc se registra después de ese punto, el sistema se colgará. La forma correcta de evitar este problema es desconectar el dispositivo del host cuando el bus USB no esté en estado de suspensión. Entonces, el host recibirá el evento de desconexión y detendrá la transferencia de datos a tiempo. Para que el dispositivo USB siga funcionando después de reanudar el sistema, esto volverá a conectar el dispositivo automáticamente. Para que la activación USB funcione si el bus USB ya está en estado de suspensión, esto mantendrá la conexión solo cuando el controlador del dispositivo USB haya habilitado la capacidad de activación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: appletb-kbd: corrección de use-after-free de slab en appletb_kbd_probe. En la sonda appletb_kbd_probe(), se asigna una estructura "struct appletb_kbd *kbd" mediante devm_kzalloc() para almacenar datos relacionados con el teclado de la barra táctil. Posteriormente, si backlight_device_get_by_name() encuentra un dispositivo de retroiluminación con el nombre "appletb_backlight", se configura un temporizador (kbd->inactivity_timer) con appletb_inactivity_timer() y se arma para que se ejecute después de appletb_tb_dim_timeout (60) segundos. Se activa un uso tras liberación cuando se produce un fallo después de que el temporizador esté armado. Esto, en última instancia, significa que se produce un fallo en la sonda y, como resultado, se libera la estructura "struct appletb_kbd *kbd", que es la memoria administrada por el dispositivo. Después de 60 segundos, el temporizador habrá expirado y __run_timers intentará acceder al temporizador (kbd->inactivity_timer); sin embargo, la estructura kdb se habrá liberado, lo que provocará un use-after-free. [ 71.636938] ================================================================== [ 71.637915] BUG: KASAN: slab-use-after-free in __run_timers+0x7ad/0x890 [ 71.637915] Write of size 8 at addr ffff8881178c5958 by task swapper/1/0 [ 71.637915] [ 71.637915] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.16.0-rc2-00318-g739a6c93cc75-dirty #12 PREEMPT(voluntary) [ 71.637915] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 71.637915] Call Trace: [ 71.637915] [ 71.637915] dump_stack_lvl+0x53/0x70 [ 71.637915] print_report+0xce/0x670 [ 71.637915] ? __run_timers+0x7ad/0x890 [ 71.637915] kasan_report+0xce/0x100 [ 71.637915] ? __run_timers+0x7ad/0x890 [ 71.637915] __run_timers+0x7ad/0x890 [ 71.637915] ? __pfx___run_timers+0x10/0x10 [ 71.637915] ? update_process_times+0xfc/0x190 [ 71.637915] ? __pfx_update_process_times+0x10/0x10 [ 71.637915] ? _raw_spin_lock_irq+0x80/0xe0 [ 71.637915] ? _raw_spin_lock_irq+0x80/0xe0 [ 71.637915] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 71.637915] run_timer_softirq+0x141/0x240 [ 71.637915] ? __pfx_run_timer_softirq+0x10/0x10 [ 71.637915] ? __pfx___hrtimer_run_queues+0x10/0x10 [ 71.637915] ? kvm_clock_get_cycles+0x18/0x30 [ 71.637915] ? ktime_get+0x60/0x140 [ 71.637915] handle_softirqs+0x1b8/0x5c0 [ 71.637915] ? __pfx_handle_softirqs+0x10/0x10 [ 71.637915] irq_exit_rcu+0xaf/0xe0 [ 71.637915] sysvec_apic_timer_interrupt+0x6c/0x80 [ 71.637915] [ 71.637915] [ 71.637915] Allocated by task 39: [ 71.637915] kasan_save_stack+0x33/0x60 [ 71.637915] kasan_save_track+0x14/0x30 [ 71.637915] __kasan_kmalloc+0x8f/0xa0 [ 71.637915] __kmalloc_node_track_caller_noprof+0x195/0x420 [ 71.637915] devm_kmalloc+0x74/0x1e0 [ 71.637915] appletb_kbd_probe+0x37/0x3c0 [ 71.637915] hid_device_probe+0x2d1/0x680 [ 71.637915] really_probe+0x1c3/0x690 [ 71.637915] __driver_probe_device+0x247/0x300 [ 71.637915] driver_probe_device+0x49/0x210 [...] [ 71.637915] [ 71.637915] Freed by task 39: [ 71.637915] kasan_save_stack+0x33/0x60 [ 71.637915] kasan_save_track+0x14/0x30 [ 71.637915] kasan_save_free_info+0x3b/0x60 [ 71.637915] __kasan_slab_free+0x37/0x50 [ 71.637915] kfree+0xcf/0x360 [ 71.637915] devres_release_group+0x1f8/0x3c0 [ 71.637915] hid_device_probe+0x315/0x680 [ 71.637915] really_probe+0x1c3/0x690 [ 71.637915] __driver_probe_device+0x247/0x300 [ 71.637915] driver_probe_device+0x49/0x210 [...] La causa principal del problema es que el temporizador no se desactiva en rutas de fallo, lo que provoca que permanezca activo y acceda a la memoria liberada. Para solucionar esto, llame a timer_delete_sync() para desactivarlo. Otro pequeño problema es que timer_delete_sync se llama incondicionalmente en appletb_kbd_remove(). Para solucionarlo, compruebe si hay un `kbd->backlight_dev` válido antes de llamar a timer_delete_sync.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/mlx5: Se corrige el acceso inseguro a la matriz x en la gestión implícita de ODP. __xa_store() y __xa_erase() se usaban sin mantener el bloqueo adecuado, lo que generaba una advertencia de bloqueo debido al uso inseguro de RCU. Este parche los reemplaza con xa_store() y xa_erase(), que realizan el bloqueo necesario internamente. ============================= WARNING: suspicious RCPU usage 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1 Not tainted ----------------------------- ./include/linux/xarray.h:1211 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by kworker/u136:0/219: at: process_one_work+0xbe4/0x15f0 process_one_work+0x75c/0x15f0 pagefault_mr+0x9a5/0x1390 [mlx5_ib] stack backtrace: CPU: 14 UID: 0 PID: 219 Comm: kworker/u136:0 Not tainted 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib] Call Trace: dump_stack_lvl+0xa8/0xc0 lockdep_rcu_suspicious+0x1e6/0x260 xas_create+0xb8a/0xee0 xas_store+0x73/0x14c0 __xa_store+0x13c/0x220 ? xa_store_range+0x390/0x390 ? spin_bug+0x1d0/0x1d0 pagefault_mr+0xcb5/0x1390 [mlx5_ib] ? _raw_spin_unlock+0x1f/0x30 mlx5_ib_eqe_pf_action+0x3be/0x2620 [mlx5_ib] ? lockdep_hardirqs_on_prepare+0x400/0x400 ? mlx5_ib_invalidate_range+0xcb0/0xcb0 [mlx5_ib] process_one_work+0x7db/0x15f0 ? pwq_dec_nr_in_flight+0xda0/0xda0 ? assign_work+0x168/0x240 worker_thread+0x57d/0xcd0 ? rescuer_thread+0xc40/0xc40 kthread+0x3b3/0x800 ? kthread_is_per_cpu+0xb0/0xb0 ? lock_downgrade+0x680/0x680 ? do_raw_spin_lock+0x12d/0x270 ? spin_bug+0x1d0/0x1d0 ? finish_task_switch.isra.0+0x284/0x9e0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? kthread_is_per_cpu+0xb0/0xb0 ret_from_fork+0x2d/0x70 ? kthread_is_per_cpu+0xb0/0xb0 ret_from_fork_asm+0x11/0x20

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio-net: garantizar que la longitud recibida no supere el tamaño asignado. En xdp_linearize_page, al leer los siguientes búferes del anillo, se olvida verificar la longitud recibida con el tamaño asignado real. Esto puede provocar una lectura fuera de los límites. Este commit añade esta verificación faltante.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/v3d: Deshabilitar interrupciones antes de reiniciar la GPU Actualmente, se puede activar una interrupción durante un reinicio de la GPU, lo que puede provocar bloqueos de la GPU y desreferenciación del puntero NULL en un contexto de interrupción como se muestra en el siguiente seguimiento: [ 314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0 [ 314.043822] Mem abort info: [ 314.046606] ESR = 0x0000000096000005 [ 314.050347] EC = 0x25: DABT (current EL), IL = 32 bits [ 314.055651] SET = 0, FnV = 0 [ 314.058695] EA = 0, S1PTW = 0 [ 314.061826] FSC = 0x05: level 1 translation fault [ 314.066694] Data abort info: [ 314.069564] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 314.075039] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 314.080080] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000 [ 314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1 [ 314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 314.152165] pc : v3d_irq+0xec/0x2e0 [v3d] [ 314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d] [ 314.160198] sp : ffffffc080003ea0 [ 314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000 [ 314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0 [ 314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000 [ 314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000 [ 314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000 [ 314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001 [ 314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874 [ 314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180 [ 314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb [ 314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 314.234807] Call trace: [ 314.237243] v3d_irq+0xec/0x2e0 [v3d] [ 314.240906] __handle_irq_event_percpu+0x58/0x218 [ 314.245609] handle_irq_event+0x54/0xb8 [ 314.249439] handle_fasteoi_irq+0xac/0x240 [ 314.253527] handle_irq_desc+0x48/0x68 [ 314.257269] generic_handle_domain_irq+0x24/0x38 [ 314.261879] gic_handle_irq+0x48/0xd8 [ 314.265533] call_on_irq_stack+0x24/0x58 [ 314.269448] do_interrupt_handler+0x88/0x98 [ 314.273624] el1_interrupt+0x34/0x68 [ 314.277193] el1h_64_irq_handler+0x18/0x28 [ 314.281281] el1h_64_irq+0x64/0x68 [ 314.284673] default_idle_call+0x3c/0x168 [ 314.288675] do_idle+0x1fc/0x230 [ 314.291895] cpu_startup_entry+0x3c/0x50 [ 314.295810] rest_init+0xe4/0xf0 [ 314.299030] start_kernel+0x5e8/0x790 [ 314.302684] __primary_switched+0x80/0x90 [ 314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017) [ 314.312775] ---[ end trace 0000000000000000 ]--- [ 314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 314.324249] SMP: stopping secondary CPUs [ 314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000 [ 314.334076] PHYS_OFFSET: 0x0 [ 314.336946] CPU features: 0x08,00002013,c0200000,0200421b [ 314.342337] Memory Limit: none [ 314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- Before resetting the G ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rose: corrección de punteros vecinos colgantes en rose_rt_device_down(). Hay dos errores en rose_rt_device_down() que pueden causar un use-after-free: 1. El límite del bucle `t->count` se modifica dentro del bucle, lo que puede provocar que el bucle termine antes de tiempo y se pierdan algunas entradas. 2. Al eliminar una entrada de la matriz de vecinos, las entradas posteriores se mueven hacia arriba para llenar el espacio vacío, pero el índice del bucle `i` aún se incrementa, lo que hace que se omita la siguiente entrada. Por ejemplo, si un nodo tiene tres vecinos (A, A, B) con count=3 y se está eliminando A, no se comprueba el segundo A. i=0: (A, A, B) -> (A, B) con count=2 ^ comprobado i=1: (A, B) -> (A, B) con count=2 ^ comprobado (¡B, no A!) i=2: (no ocurre porque i < count es falso) Esto deja la segunda A en el array con count=2, pero la estructura rose_neigh se ha liberado. El código que accede a estas entradas asume que las primeras entradas de `count` son punteros válidos, lo que provoca un use-after-free al acceder al puntero colgante. Solucione ambos problemas iterando sobre el array en orden inverso con un límite de bucle fijo. Esto garantiza que se examinen todas las entradas y que la eliminación de una entrada no afecte a las iteraciones posteriores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: KVM: verificar la validez de "num_cpu" desde el espacio del usuario. El número máximo de CPU admitido es EIOINTC_ROUTE_MAX_VCPUS sobre irqchip EIOINTC, aquí agregue validación sobre el número de CPU para evitar el desbordamiento del puntero de la matriz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: KVM: Evitar el desbordamiento con el índice de la matriz. La variable índice se modifica y se reutiliza como índice de la matriz al modificar el registro EIOINTC_ENABLE. Se producirá un problema de desbordamiento del índice de la matriz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: tps6594-pfsm: Se ha añadido una comprobación de puntero nulo en tps6594_pfsm_probe(). El valor devuelto, pfsm->miscdev.name, desde devm_kasprintf() podría ser nulo. Se ha añadido una comprobación de puntero para evitar posibles desreferencias de punteros nulos. Esto es similar a la corrección en el commit 3027e7b15b02 ("ice: Se corrigen algunos problemas de desreferencia de puntero nulo en ice_ptp.c"). Nuestra herramienta de análisis estático ha detectado este problema.

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