Vulnerabilidad en kernel de Linux (CVE-2025-22115)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrección de la ejecución de recuento de referencias de grupos de bloques en btrfs_create_pending_block_groups(). La creación de grupos de bloques se realiza en dos fases, lo que resulta en una propiedad poco intuitiva: un grupo de bloques se puede asignar/desasignar después de que btrfs_make_block_group() lo añada a space_info con btrfs_add_bg_to_space_info(), pero antes de que la creación se complete por completo en btrfs_create_pending_block_groups(). Como resultado, es posible que un grupo de bloques quede sin usar y que se invoque 'btrfs_mark_bg_unused' simultáneamente con 'btrfs_create_pending_block_groups'. Esto causa varios problemas, que se solucionaron con la bandera de grupo de bloques 'BLOCK_GROUP_FLAG_NEW'. Sin embargo, esta corrección no está del todo completa. Dado que no utiliza el bloqueo de bloques no utilizados (unused_bg_lock), es posible que se produzca la siguiente ejecución: btrfs_create_pending_block_groups btrfs_mark_bg_unused if list_empty // false list_del_init clear_bit else if (test_bit) // true list_move_tail. Y llegamos al mismo estado de recuento de referencias erróneo y new_bgs no válido para la limpieza de transacciones, que BLOCK_GROUP_FLAG_NEW pretendía evitar. El aspecto de recuento de referencias erróneo generará una advertencia como: [1272.943527] refcount_t: underflow; use-after-free. [1272.943967] ADVERTENCIA: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs] [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G W 6.14.0-rc5+ #108 [1272.946368] Tainted: [W]=WARN [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs] [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110 [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282 [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000 [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268 [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0 [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0 [1272.952850] FS: 0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000 [1272.953458] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0 [1272.954474] Call Trace: [1272.954655] [1272.954812] ? refcount_warn_saturate+0xba/0x110 [1272.955173] ? __warn.cold+0x93/0xd7 [1272.955487] ? refcount_warn_saturate+0xba/0x110 [1272.955816] ? report_bug+0xe7/0x120 [1272.956103] ? handle_bug+0x53/0x90 [1272.956424] ? exc_invalid_op+0x13/0x60 [1272.956700] ? asm_exc_invalid_op+0x16/0x20 [1272.957011] ? refcount_warn_saturate+0xba/0x110 [1272.957399] btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs] [1272.957853] btrfs_put_block_group.cold+0x5d/0x8e [btrfs] [1272.958289] btrfs_discard_workfn+0x194/0x380 [btrfs] [1272.958729] process_one_work+0x130/0x290 [1272.959026] worker_thread+0x2ea/0x420 [1272.959335] ? __pfx_worker_thread+0x10/0x10 [1272.959644] kthread+0xd7/0x1c0 [1272.959872] ? __pfx_kthread+0x10/0x10 [1272.960172] ret_from_fork+0x30/0x50 [1272.960474] ? __pfx_kthread+0x10/0x10 [1272.960745] ret_from_fork_asm+0x1a/0x30 [1272.961035] [1272.961238] ---[ end trace 0000000000000000 ]--- Aunque también los hemos visto en la función de trabajo de descarte asíncrono. Es más probable que ocurra después de finalizar una reubicación que cancela el descarte, desmantela el grupo de bloques, etc. Solucione esto completamente desmantelando el bloqueo de ---truncated---