Blog / CVE expliquées

CVE-2025-37858 : une destination 64 bits ne corrige pas un décalage trop étroit

Un calcul des groupes d’allocation de JFS montre pourquoi la revue de code doit examiner la largeur d’une opération avant que son résultat ne soit affecté.

Études doctorales en sécurité de l’information achevéesSoutenance universitaire réussie · Soutenance finale de thèse à venir

Là où le calcul a déraillé

CVE-2025-37858 concerne le dimensionnement des groupes d’allocation dans dbExtendFS(), dans fs/jfs/jfs_dmap.c. Le calcul utilisait 1 << l2agsize. L’annonce CVE de Linux décrit des décalages supérieurs à 31 sur les systèmes 32 bits, qui produisent un comportement indéfini et des tailles de groupe d’allocation invalides.

La subtilité tient à l’expression elle-même. Le littéral entier 1 ne devient pas un opérande 64 bits parce que le résultat sera stocké dans un champ plus large. Le décalage est évalué d’abord, l’affectation vient ensuite. Examiner seulement le type de destination fait passer à côté de l’opération qui crée la valeur.

Élargir l’opérande avant le décalage

Le correctif convertit l’opérande gauche en s64 avant le décalage. L’opération utilise ainsi la largeur voulue et correspond au champ de la taille du groupe d’allocation. La comparaison ci-dessous montre la modification de l’expression documentée dans l’annonce.

Convertir l’expression une fois calculée interviendrait trop tard. La même distinction mérite l’attention dans les multiplications et les calculs de taille d’allocation. Un type intermédiaire plus large exige aussi un contrôle de plage adapté : l’élargissement seul ne rend pas toute entrée possible sûre.

- bmp->db_agsize = 1 << l2agsize;
+ bmp->db_agsize = (s64)1 << l2agsize;

Examiner les valeurs intermédiaires

Notez, pour chaque calcul de taille, les types effectifs des opérandes, leur signe et la plage d’entrée valide. Vérifiez l’expression avant l’affectation, y compris les promotions et les conversions explicites. Examinez les configurations 32 et 64 bits prises en charge lorsqu’elles influent sur les types ou sur la compilation.

Les tests aux limites doivent exercer les valeurs autour de la borne prévue et vérifier la taille obtenue ou le rejet. Les sanitizers et l’analyse statique peuvent aider, mais le relecteur doit toujours relier l’arithmétique aux hypothèses de l’opération suivante.

Pourquoi cela compte au-delà des systèmes de fichiers

L’annonce publique évoque de possibles corruptions du système de fichiers et des plantages du noyau dus à une taille de groupe invalide. Elle n’établit pas l’impact d’une expression d’apparence similaire dans votre application : il faut pour cela suivre le résultat jusqu’à ceux qui l’utilisent.

Ce réflexe de revue est utile dans les applications natives qui manipulent des longueurs, des décalages, des tampons et des métadonnées de fichiers non fiables. Une revue de code sécurité bien cadrée peut examiner le calcul et les opérations mémoire ou de stockage qu’il pilote. Pour les paquets Linux déployés, appuyez-vous sur la fiche CVE à jour et sur l’avis de l’éditeur pour connaître l’état du correctif.

Sources

Fiche de la vulnérabilité

CVE-2025-37858

Besoin de vérifier ce point dans votre propre produit ?

Revue de code sécurité

Vous voulez apprendre à trouver vous-même ce type de vulnérabilité ?

Formation individuelle à la revue de code sécurisé
Tous les articles

08Contact

Vous livrez un produit qui traite des données d’utilisateurs ?

Envoyez-moi un bref descriptif. Je réponds sous trois jours avec des questions ou une première proposition, et le prix est fixé par écrit avant le démarrage.