CVE-2026-92500 in Linux
Résumé
par VulDB • 18/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
ext4 : utiliser fsdata pour suivre l'état d'écriture des données inline et corriger une condition de concurrence (race)
Au lieu de vérifier l'état live de l'inode (`ext4_has_inline_data(inode)` et `ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)`) dans les gestionnaires de `write_end`, utiliser le paramètre fsdata des opérations d'espace d'adressage pour transmettre explicitement l'état dans lequel `write_begin` a préparé l'écriture.
Un thread concurrent (tel que `ext4_page_mkwrite()`) peut convertir les données inline en extent entre `write_begin` et `write_end`. Si cela se produit, les gestionnaires de `write_end` manquaient auparavant le chemin d'exécution `inline write_end` et déviaient vers la logique de `write_end` basée sur des extents. Cependant, comme les tampons de blocs n'ont jamais été alloués dans `write_begin`, cela a entraîné des déréférencements de pointeur NULL ou une perte de données car `folio_buffers(folio)` était NULL.
Définir EXT4_WRITE_DATA_INLINE (4) comme un bit flag (Bit 2), en traitant fsdata comme des bits flags plutôt que comme des énumérations mutuellement exclusives, afin de maintenir l'indépendance des états du chemin d'écriture. Communiquer cet état via fsdata : 1) `ext4_write_begin()` et `ext4_da_write_begin()` définissent le bit EXT4_WRITE_DATA_INLINE dans *fsdata par OR binaire lorsqu'une écriture inline est préparée avec succès. 2) À l'entrée, `ext4_write_begin()` efface le bit EXT4_WRITE_DATA_INLINE pour gérer correctement les nouvelles tentatives du VFS (où generic_perform_write() contourne l'initialisation de fsdata lors de sa nouvelle tentative). 3) Les gestionnaires write_end effectuent un ET binaire pour vérifier si le bit EXT4_WRITE_DATA_INLINE est défini et invoquent en conséquence l'aide à la fin d'une écriture inline.
De plus, pendant une écriture mise en mémoire tampon (buffered), `ext4_write_inline_data_end()` acquiert le verrou xattr après avoir préparé l'écriture. Si un défaut de page concurrent (`ext4_page_mkwrite()`) convertit les données inline en extent après que les gestionnaires write_end ont vérifié l'état mais avant que `ext4_write_inline_data_end()` n'acquière le verrou d'écriture xattr, la vérification ultérieure déclenchera un panic noyau via BUG_ON(!ext4_has_inline_data(inode)).
Pour conserver l'historique git et une capacité de bisect propre, remplacer la vérification BUG_ON dans ext4_write_inline_data_end() par un chemin de reprise avec gestion d'erreur gracieuse dans ce même commit. Si les données inline sont effacées après le verrouillage du xattr, nous libérons en toute sécurité toutes les ressources (libération de iloc.bh, déverrouillage/relâchement du folio, arrêt du handle de transaction journal actif) et retournons 0 (nouvelle tentative VFS) pour permettre au chemin d'écriture générique de réessayer l'opération en toute sécurité.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.