Blog / CVE expliquées

CVE-2024-26855 : quand un attribut absent devient un déréférencement de NULL

Un correctif du pilote ice de Linux illustre une erreur fréquente en revue de code : traiter le résultat optionnel d’un parseur comme un objet garanti.

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

L’hypothèse qui n’a pas tenu

CVE-2024-26855 concerne ice_bridge_setlink(), dans le pilote réseau ice d’Intel. La fonction recherche dans un message netlink l’attribut de pont IFLA_AF_SPEC. Sa recherche, nlmsg_find_attr(), peut renvoyer NULL lorsque cet attribut est absent. Le chemin vulnérable transmettait le résultat à l’itération des attributs imbriqués sans le vérifier au préalable.

La question importante, en revue, est le contrat entre deux opérations : la recherche promet-elle un objet, ou renvoie-t-elle un résultat optionnel ? Qu’un message atteigne le gestionnaire ne garantit pas la présence de tous les attributs attendus par le code qui suit.

Valider le résultat avant de l’utiliser

Le correctif accepté vérifie br_spec immédiatement après la recherche et renvoie -EINVAL s’il est absent. La valeur invalide est ainsi arrêtée avant l’itération imbriquée. L’extrait ci-dessous montre ce garde-fou ; ce n’est pas un reproducteur autonome.

Placer la vérification à la transition rend l’hypothèse visible pour le lecteur suivant. Le code établit désormais la condition dont l’opération suivante a besoin.

if (!br_spec)
    return -EINVAL;

Ce qu’il faut vérifier dans votre propre parseur

Suivez chaque recherche optionnelle jusqu’à sa première utilisation. Examinez les champs manquants, les collections vides et les entrées malformées séparément du chemin nominal. Vérifiez si une fonction utilitaire signale l’échec par NULL, par une valeur d’erreur ou par un statut distinct. Confirmez ensuite que chaque appelant respecte ce contrat.

Un test de non-régression utile exerce le chemin de l’attribut absent et vérifie le résultat d’erreur attendu. Un test qui ne contient qu’un message complet peut réussir tout en laissant l’hypothèse d’origine intacte.

La leçon pratique pour une équipe produit

Il s’agit d’un défaut ciblé, au niveau du code, avec une correction concrète. Le même réflexe de revue compte aussi dans les parseurs applicatifs, les gestionnaires de protocoles et les chargeurs de configuration : une donnée optionnelle doit rester optionnelle jusqu’à sa validation.

Pour un système Linux installé, consultez la fiche CVE à jour et l’avis de paquets de votre distribution. Les correctifs rétroportés rendent l’état du paquet plus parlant qu’une comparaison superficielle avec la version amont. Pour votre propre code, une revue ciblée peut suivre ces contrats à travers les composants qui traitent des entrées non fiables.

Sources

Fiche de la vulnérabilité

CVE-2024-26855

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.