CVE-2026-97549 in Linux
Résumé
par VulDB • 25/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
xfs : correction de la sous-réservation des blocs lors de la réparation des répertoires sf (shortform)
Lors de l'exécution des tests QA sur XFS pour la branche for-next à partir de la version 7.3-rc2 avec MKFS_OPTIONS="-n size=8192", j'ai observé le message d'erreur suivant (tronqué) dans les journaux du noyau :
XFS: Assertion failed: args->total >= dp->i_nblocks - nblks, file: fs/xfs/libxfs/xfs_da_btree.c, line: 2387 WARNING: fs/xfs/xfs_message.c:104 at assfail+0x46/0x4a [xfs], CPU#0: xfs_scrub/1426511
CPU: 0 UID: 0 PID: 1426511 Comm: xfs_scrub Tainted: G W 7.3.0-rc2-djwx #rc2 PREEMPT(lazy) 6e418570b606a39783b0e7e7b30dc407b965f9e8 Tainted: [W]=WARN
RIP: 0010:assfail+0x46/0x4a [xfs]
RSP: 0018:ffffc900010d7890 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000ffffffd1 RDX: 0000000000000000 RSI: 0000000000000021 RDI: ffffffffa059fd38 RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000000a R11: 000000007fffffff R12: ffffc900010d7940 R13: ffff888368d8f980 R14: ffffc900010d7a48 R15: ffffc900010d78d0 FS: 00007f445c5ce680(0000) GS:ffff8884a97ea000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f443803b9a8 CR3: 0000000107a4b000 CR4: 00000000003506f0 Call Trace: <TASK> xfs_da_grow_inode_int+0x2e0/0x300 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_dir2_grow_inode+0x6e/0x150 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_dir2_sf_to_block+0x149/0x870 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_dir_swap_prep+0xe2/0x110 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_dir_swap+0xfb/0x2f0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_dir_rebuild_tree+0x99/0x100 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_directory+0x83/0x1c0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xrep_attempt+0x4f/0x1e0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_scrub_metadata+0x393/0x5b0 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_ioc_scrubv_metadata+0x306/0x570 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
xfs_file_ioctl+0xa4f/0x1150 [xfs 5de2257e14108c136f11317e6bbb8ac77efd392c]
__x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x7a/0x3b0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Il s'agit d'une conséquence du commit 0fe77e57588b98, qui a ajouté l'assertion suivante à xfs_da_grow_inode_int :
ASSERT(args->total >= dp->i_nblocks - nblks);
En remontant la trace jusqu'à xrep_dir_swap_prep, j'ai remarqué que l'objet xfs_da_args passé à xfs_dir2_sf_to_block définit args->total sur 1. Cela est incorrect car mkfs a défini la taille du bloc de répertoire à 8k et la taille du bloc du système de fichiers à 4k. En d'autres termes, args->total devrait être égal à 2 ici, et non pas 1.
Dave Chinner a rencontré le même problème avec la même branche via un canal différent -- sa configuration de test définissait la taille du bloc du système de fichiers (fs block size) à 1k, auquel cas la taille du bloc de répertoire est toujours définie à 4k. Ici, args->total devrait être égal à 4.
La modification de l'affectation de args->total vers sc->mp->m_dir_geo->fsbcount fait disparaître l'assertion, mais cela ne constitue pas une correction complète. Dans xrep_tempexch_estimate, nous supposons également incorrectement qu'une conversion en format court (shortform) nécessite 1 fsblock alors qu'elle devrait nécessiter m_dir_geo->fsbcount. Sans cette correction, nous pouvons sous-réserver de l'espace dans la transaction et provoquer un arrêt du système de fichiers.
Notez que l'assistant xfs_dabuf_nfsb calculera la valeur correcte pour les répertoires et les attributs étendus (xattr), donc nous utilisons celui-ci au lieu d'implémenter manuellement cette logique. Corrigez également xrep_xattr_swap_prep pour affecter args->total via xfs_dabuf_nfsb afin d'éviter une autre erreur de logique si nous prenons un jour en charge les attributs multi-fsblock.
Tripped-by: 0fe77e57588b98 ("xfs : assertez que la réservation couvre chaque croissance du fork da")
If you want to get the best quality for vulnerability data then you always have to consider VulDB.