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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: manejar correctamente el error del árbol csum con rescue=ibadroots [ERROR] Hay un reproductor basado en syzbot que puede hacer caer el kernel, con el siguiente seguimiento de llamada: (Con alguna salida de depuración agregada) DEBUG: rescue=ibadroots analizó BTRFS: dispositivo fsid 14d642db-7b15-43e4-81e6-4b8fac6a25f8 devid 1 transid 8 /dev/loop0 (7:0) escaneado por repro (1010) Información de BTRFS (dispositivo loop0): primer montaje del sistema de archivos 14d642db-7b15-43e4-81e6-4b8fac6a25f8 Información de BTRFS (dispositivo loop0): usando el algoritmo de suma de comprobación blake2b (blake2b-256-generic) Información de BTRFS (dispositivo loop0): usando el algoritmo de suma de comprobación blake2b (blake2b-256-generic) Advertencia de BTRFS de árbol de espacio libre (dispositivo loop0): la verificación de suma de comprobación falló en el espejo lógico 5312512 1 deseado 0xb043382657aede36608fd3386d6b001692ff406164733d94e2d9a180412c6003 encontrado 0x810ceb2bacb7f0f9eb2bf3b2b15c02af867cb35ad450898169f3b1f0bd818651 nivel 0 DEBUG: la lectura de la ruta raíz del árbol falló para el csum del árbol, ret=-5 Advertencia de BTRFS (dispositivo loop0): la verificación de suma de comprobación falló en el espejo lógico 5328896 1 deseado Se encontró 0x51be4e8b303da58e6340226815b70e3a93592dac3f30dd510c7517454de8567a. Advertencia BTRFS de nivel 0 (bucle de dispositivo 0): la verificación de suma de comprobación falló en el espejo lógico 5292032 deseado 1. Se encontró 0x1924ccd683be9efc2fa98582ef58760e3848e9043db8649ee382681e220cdee4. 0x0cb6184f6e8799d9f8cb335dccd1d1832da1071d12290dab3b85b587ecacca6e proceso de nivel 0 'repro' lanzado './file2' con NULL argv: cadena vacía agregada DEBUG: sin raíz csum, idatacsums=0 ibadroots=134217728 Oops: error de protección general, probablemente para dirección no canónica 0xdffffc0000000041: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x0000000000000208-0x000000000000020f] CPU: 5 UID: 0 PID: 1010 Comm: repro Tainted: G OE 6.15.0-custom+ #249 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csum+0x93/0x3d0 [btrfs] Call Trace: btrfs_lookup_bio_sums+0x47a/0xdf0 [btrfs] btrfs_submit_bbio+0x43e/0x1a80 [btrfs] submit_one_bio+0xde/0x160 [btrfs] btrfs_readahead+0x498/0x6a0 [btrfs] read_pages+0x1c3/0xb20 page_cache_ra_order+0x4b5/0xc20 filemap_get_pages+0x2d3/0x19e0 filemap_read+0x314/0xde0 __kernel_read+0x35b/0x900 bprm_execve+0x62e/0x1140 do_execveat_common.isra.0+0x3fc/0x520 __x64_sys_execveat+0xdc/0x130 do_syscall_64+0x54/0x1d0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]--- [CAUSE] En primer lugar, el sistema de archivos tiene una raíz de árbol csum dañada, por lo tanto, para montar el sistema de archivos tenemos que usar la opción de montaje "ro,rescue=ibadroots". Normalmente, con esa opción de montaje, una raíz de árbol de sumas de confianza incorrecta debería activar la bandera BTRFS_FS_STATE_NO_DATA_CSUMS, de modo que cualquier lectura de datos futura ignore la búsqueda de sumas de confianza. Sin embargo, en este caso particular, tenemos el siguiente seguimiento de llamada que generó una raíz de sumas de confianza nula, pero no activó BTRFS_FS_STATE_NO_DATA_CSUMS: load_global_roots_objectid(): ret = btrfs_search_slot(); /* Correcto */ btrfs_item_key_to_cpu() found = true; /* Se encontró el elemento raíz del árbol de sumas de confianza. */ root = read_tree_root_path(); if (IS_ERR(root)) { if (!btrfs_test_opt(fs_info, IGNOREBADROOTS)) /* * Dado que tenemos la opción de montaje rescue=ibadroots, * @ret sigue siendo 0. */ break; if (!found || ret) { /* @found es verdadero, @ret es 0, se omite el manejo de errores del árbol de sumas de csuma. */ } Esto significa que omitimos completamente la configuración de BTRFS_FS_STATE_NO_DATA_CSUMS si el árbol de sumas de csuma está dañado, lo que resulta en una búsqueda posterior inesperada --- truncado ---