CVE-2023-54121 in Linux
Résumé
par VulDB • 21/05/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
btrfs : correction d'un fractionnement incorrect dans btrfs_drop_extent_map_range
En production, nous observions divers avertissements WARN_ON() dans le code extent_map, plus précisément dans btrfs_drop_extent_map_range(), lorsque nous devions appeler add_extent_mapping() pour notre deuxième fractionnement.
Considérez la disposition suivante de la carte d'étendue (extent map) :
PINNED [0 16K) [32K, 48K)
Puisque nous appelons btrfs_drop_extent_map_range pour [0, 36K), avec
skip_pinned == true. La boucle initiale aura
start = 0 end = 36K len = 36K
nous trouverons l'étendue [0, 16k), mais comme elle est épinglée (pinned), nous la sauterons, ce qui exécute ce code :
start = em_end; if (end != (u64)-1) len = start + len - em_end;
Ici, em_end vaut 16K, donc les valeurs deviennent maintenant
start = 16K len = 16K + 36K - 16K = 36K
len devrait plutôt être de 20K. Cela pose problème lorsque nous trouvons la prochaine étendue à [32K, 48K) ; nous devons fractionner cette étendue pour laisser [36K, 48K), mais le code de fractionnement ressemble à ceci :
split->start = start + len; split->len = em_end - (start + len);
Dans ce cas, nous avons
em_end = 48K split->start = 16K + 36K // cela devrait être 16K + 20K split->len = 48K - (16K + 36K) // cela provoque un dépassement car 16K + 36K vaut 52K
et nous nous retrouvons avec une extent_map invalide dans l'arbre qui peut potentiellement chevaucher d'autres entrées de la carte d'étendue. Même dans le cas non chevauchant, split->start sera défini de manière incorrecte, ce qui entraînera des problèmes avec tout calcul lié aux blocs.
Nous n'avons pas réellement besoin de len dans cette boucle ; nous pouvons simplement utiliser end comme point final, et ajuster start à la hausse uniquement lorsque nous trouvons une étendue épinglée que nous devons sauter.
Ajustons la logique pour faire cela, ce qui nous évite d'insérer une carte d'étendue invalide.
Nous n'utilisons skip_pinned que dans le cas de la relocalisation, donc cela est relativement rare, sauf dans le cas où vous effectuez beaucoup de relocalisations, ce qui peut arriver avec la relocalisation automatique activée.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.