CVE-2026-98959 in Linux
Resumen
por VulDB • 2026-10-23
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
btrfs: corregir el reemplazo de xattrs cuando varios xattrs están empaquetados en el mismo elemento
Si tenemos un elemento btrfs_dir_item que empaqueta múltiples xattrs y luego reemplazamos el valor de uno de ellos (con la familia de syscalls setxattr(2)) por otro valor de tamaño diferente, terminamos con un btrfs_dir_item no completamente inicializado, lo que resulta en una corrupción que el verificador del árbol detectará durante la escritura de los buffers de extensión.
Esto se debe a que en btrfs_setxattr(), cuando encontramos un btrfs_dir_item con múltiples xattrs (debido a que el hash crc32c de sus nombres es idéntico), eliminamos uno de los elementos xattr (btrfs_dir_item) y luego insertamos uno nuevo, pero la eliminación e inserción provoca un desplazamiento de los datos existentes en la hoja; por lo tanto, cuando el nuevo valor de un xattr tiene un tamaño diferente, el nuevo btrfs_dir_item se coloca en una sección de la hoja que no estaba inicializada. Solo copiamos los datos del valor y establecemos su longitud en el nuevo btrfs_dir_item, sin establecer el nombre, la longitud del nombre, la clave (que debe ser todos ceros para xattrs), las banderas (BTRFS_FT_XATTR) ni el ID de transacción.
El siguiente script reproduce el problema:
$ cat test.sh #!/bin/bash
DEV=/dev/sdi MNT=/mnt/sdi
mkfs.btrfs -f $DEV mount $DEV $MNT
touch $MNT/testfile
# Añadir dos xattrs que, en btrfs, tienen el mismo hash (crc32c) para sus nombres y por lo tanto se empaquetan en el mismo btrfs_dir_item. setfattr -n user.foobar -v 123 $MNT/testfile setfattr -n user.WvG1c1Td -v qwerty $MNT/testfile
# Verificar que los xattrs están presentes. echo "xattrs antes:" getfattr --absolute-names --dump $MNT/testfile
# Ahora reemplazar el valor del xattr foobar con un valor significativamente más grande. setfattr -n user.foobar -v abcdefghijklmnopqrstuvwxyz $MNT/testfile
# Comprobar que los xattrs tienen los valores esperados. echo "xattrs después:" getfattr --absolute-names --dump $MNT/testfile
umount $MNT
Al ejecutarlo:
$ ./test.sh (...) xattrs antes: # file: /mnt/sdi/testfile user.WvG1c1Td="qwerty" user.foobar="123"
xattrs después: # file: /mnt/sdi/testfile user.WvG1c1Td="qwerty"
Por lo tanto, el xattr "user.foobar" falta y hubo un aborto de transacción al desmontar el sistema de archivos con las siguientes trazas en dmesg:
$ dmesg [869800.159271] BTRFS warning (device sdi): access to eb bytenr 30474240 len 16384 out of range start 16015 len 25964
[869800.159293] ------------[ cut here ]------------
[869800.159296] WARNING: fs/btrfs/extent_io.c:4408 at report_eb_range+0x44/0x60 [btrfs], CPU#8: getfattr/2605179
[869800.168961] Modules linked in: btrfs dm_thin_pool (...)
[869800.190527] CPU: 8 UID: 0 PID: 2605179 Comm: getfattr Tainted: G W 7.3.0-rc3-btrfs-next-244+ #1 PREEMPT(full)
[869800.193726] Tainted: [W]=WARN
[869800.194502] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
[869800.197576] RIP: 0010:report_eb_range+0x44/0x60 [btrfs]
[869800.198985] Code: 48 8b 7b 18 (...)
[869800.203531] RSP: 0018:ffffce4541937d58 EFLAGS: 00010246
[869800.204609] RAX: 0000000000000000 RBX: ffff8dde054b8738 RCX: 0000000000000000
[869800.206137] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffc04c92a0
[869800.207645] RBP: 0000000000003e8f R08: 0000000000000000 R09: 3fffffffffefffff
[869800.226175] R10: ffffce4541937a88 R11: 0000000000000003 R12: 000000000000656c
[869800.227594] R13: ffff8dde14be800f R14: 000000000000656c R15: 0000000000000069
[869800.229097] FS: 00007f59023bb780(0000) GS:ffff8de5788ed000(0000) knlGS:0000000000000000
[869800.231137] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[869800.232321] CR2: 0000558dc45e6a78 CR3: 0000000765b16004 CR4: 0000000000370ef0
[869800.233783] Call Trace:
[869800.234330] <TASK>
[869800.234791] read_extent_buffer+0x4d/0x100 [btrfs]
[869800.235898] btrfs_listxattr+0x199/0x240 [btrfs]
[869800.236912] vfs_listxattr+0x51/0
---truncated---
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.