CVE-2026-80734 in Linux
Resumen
por VulDB • 2026-09-03
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
btrfs: inicializar las marcas de mapeo del inodo para los inodos en caché
[BUG]
Al ejecutar generic/795 con un tamaño de bloque de 8K y un tamaño de página de 4K, la prueba siempre falla, desencadenando algunas ASSERT() relacionadas con el tamaño del folio:
795 (241074): drop_caches: 3 assertion failed: IS_ALIGNED(start, blocksize) && IS_ALIGNED(end + 1, blocksize), in extent_io.c:1404 (blocksize=8192 root=262 ino=258 start=16826368 end=16830463 mapping min order=0) ------------[ cut here ]------------
kernel BUG at extent_io.c:1404! Oops: invalid opcode: 0000 [#1] SMP
CPU: 8 UID: 0 PID: 241105 Comm: fsstress Tainted: G OE 7.2.0-rc5-custom+ #442 PREEMPT(full) f4bfb352566f3949f29c233ce6f735050a03b245 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:assert_folio_range.cold+0x3d/0x3f [btrfs]
Call Trace: <TASK> btrfs_read_folio+0x9e/0x170 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]
prepare_one_folio.constprop.0+0x104/0x2a0 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]
btrfs_buffered_write+0x285/0xa50 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]
btrfs_do_write_iter+0x1aa/0x210 [btrfs 4cd1dd93b341b8ef766643f9512f4a86259567a3]
iter_file_splice_write+0x31a/0x540 direct_splice_actor+0x53/0x170 splice_direct_to_actor+0xe9/0x240 do_splice_direct+0x76/0xb0 vfs_copy_file_range+0x1fd/0x630 __x64_sys_copy_file_range+0xf9/0x220 do_syscall_64+0xe1/0x790 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---
La ASSERT() en sí fue añadida por un parche posterior. El crash se desencadena con ese nuevo parche de depuración y sin esta corrección.
[CAUSE]
En el caso anterior, el inicio 16826368 está correctamente alineado a 8K, pero el final (16830463 + 1) no está alineado a 8K. Además, la orden mínima del folio en el mapeo es 0, no la esperada de 1 para un tamaño de bloque de 8K con un tamaño de página de 4K.
Esto significa que algunos inodos no tienen llamada a btrfs_set_inode_mapping_order().
La falta de la llamada a btrfs_set_inode_mapping_order() ocurre en los inodos almacenados en caché, a través de los siguientes eventos:
- Se llama a btrfs_create_new_inode() para el inodo X Lo cual establece correctamente la orden mínima del folio para el inodo VFS.
- Se llama a btrfs_update_inode() para el inodo X Lo cual llama a btrfs_delayed_update_inode() para crear un delayed_node en xarray root->delayed_nodes.
- Drop cache/pressure de memoria, evictando el inodo X en memoria Lo cual evicte el inodo X, pero el delayed_node sigue estando en root->delayed_nodes para su reutilización futura.
- Se llama a btrfs_iget() nuevamente para el inodo X
btrfs_iget() |- btrfs_iget_locked() | |- iget5_locked_rcu() | Lo cual crea un nuevo vfs_inode para btrfs, cuyo mapeo aún tiene la orden mínima como 0. | |- btrfs_read_locked_inode() |- btrfs_fill_inode() | |- btrfs_get_delayed_node() | El cual encuentra el nodo anterior y utiliza ese delayed_node para inicializar el nuevo inodo. | |- filled = true; |- if (filled) goto cache_index; Lo cual omite las llamadas a btrfs_update_inode_mapping_flags() y btrfs_set_inode_mapping_order(). Así que el inodo sigue teniendo la orden mínima del folio establecida como 0, no la requerida de 1.
Por lo tanto, una lectura posterior en la página cache obtendrá un folio cuyo tamaño es menor que el tamaño del bloque, ya que el mapeo tiene su orden mínima del folio establecida como 0 y no como 1, desencadenando así la ASSERT().
[FIX]
Mover las llamadas a btrfs_update_inode_mapping_flags() y btrfs_set_inode_mapping_order() bajo la etiqueta cache_index, de modo que las marcas de mapeo y la orden mínima del folio se establezcan siempre, independientemente de si tenemos un inodo en caché.
If you want to get best quality of vulnerability data, you may have to visit VulDB.