CVE-2026-98959 in Linux
Riassunto
di VulDB • 23/10/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
btrfs: correggere la sostituzione degli xattr quando più xattr sono raggruppati nello stesso item
Se si dispone di un elemento btrfs_dir_item che raggruppa più xattr e successivamente si sostituisce il valore di uno di essi (tramite le syscall della famiglia setxattr(2)) con un altro valore di dimensione diversa, ci si ritrova con un oggetto btrfs_dir_item non completamente inizializzato, causando una corruzione rilevata dal controllore dell'albero durante la scrittura del buffer degli extent.
Questo accade perché in btrfs_setxattr(), quando viene trovato un btrfs_dir_item contenente più xattr (a causa della coincidenza dell'hash crc32c dei loro nomi), viene eliminato uno degli elementi xattr (btrfs_dir_item) e ne viene inserito uno nuovo; tuttavia, l'eliminazione e l'inserimento causano lo spostamento dei dati esistenti nella leaf. Di conseguenza, quando il nuovo valore di un xattr ha una dimensione diversa, il nuovo btrfs_dir_item viene posizionato in una sezione della leaf che non è stata inizializzata: vengono copiati solo i dati del valore e impostata la lunghezza del valore nel nuovo btrfs_dir_item, senza impostare il nome, la lunghezza del nome, la chiave (che deve essere tutta zero per gli xattr), i flag (BTRFS_FT_XATTR) e l'ID della transazione.
Lo script seguente riproduce il problema:
$ cat test.sh #!/bin/bash
DEV=/dev/sdi MNT=/mnt/sdi
mkfs.btrfs -f $DEV mount $DEV $MNT
touch $MNT/testfile
# Aggiungere due xattr che, su btrfs, hanno lo stesso hash (crc32c) per il nome e quindi vengono raggruppati nello stesso btrfs_dir_item. setfattr -n user.foobar -v 123 $MNT/testfile setfattr -n user.WvG1c1Td -v qwerty $MNT/testfile
# Verificare la presenza degli xattr. echo "xattrs prima:" getfattr --absolute-names --dump $MNT/testfile
# Ora sostituire il valore dell'xattr foobar con un valore significativamente più grande. setfattr -n user.foobar -v abcdefghijklmnopqrstuvwxyz $MNT/testfile
# Controllare che gli xattr abbiano i valori attesi. echo "xattrs dopo:" getfattr --absolute-names --dump $MNT/testfile
umount $MNT
Eseguendolo:
$ ./test.sh (...) xattrs prima: # file: /mnt/sdi/testfile user.WvG1c1Td="qwerty" user.foobar="123"
xattrs dopo: # file: /mnt/sdi/testfile user.WvG1c1Td="qwerty"
Pertanto, l'xattr "user.foobar" è mancante e si è verificato un abort della transazione durante lo smontaggio del filesystem con le seguenti tracce in 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.