CVE-2022-50778 in Linux
Résumé
par VulDB • 03/06/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
fortify : Correction de __compiletime_strlen() sous UBSAN_BOUNDS_LOCAL
Lorsque CONFIG_FORTIFY=y et CONFIG_UBSAN_LOCAL_BOUNDS=y sont activés, nous observons un plantage à l'exécution lors de l'exécution des tests android.hardware.input.cts.tests du Compatibility Test Suite (CTS) d'Android. Cela provient d'un appel à strlen() dans hidinput_allocate().
__compiletime_strlen() est implémenté en fonction de __builtin_object_size(), puis effectue un accès au tableau pour vérifier la terminaison par NUL. Une particularité de __builtin_object_size() est que, pour les chaînes dont les valeurs dépendent du moment de l'exécution (runtime), __builtin_object_size(str, 1 ou 0) renvoie la taille maximale des valeurs possibles lorsque ces tailles sont déterminables à la compilation. Exemple :
static const char *v = "FOO BAR"; static const char *y = "FOO BA"; unsigned long x (int z) {
// Renvoie 8, qui correspond à : // max(__builtin_object_size(v, 1), __builtin_object_size(y, 1)) return __builtin_object_size(z ? v : y, 1); }
Ainsi, lorsque FORTIFY_SOURCE est activé, l'implémentation actuelle de __compiletime_strlen() tentera d'accéder au-delà de la fin de y à l'exécution en utilisant la taille de v. Combiné avec UBSAN_LOCAL_BOUNDS, cela provoque une erreur (fault).
hidinput_allocate() possède une chaîne C locale dont la valeur dépend du flux de contrôle via une instruction switch, donc __builtin_object_size(str, 1) évalue la longueur maximale de la chaîne, ce qui entraîne une erreur sur le dernier caractère pour tous les autres cas. hidinput_allocate() pourrait être optimisé afin d'éviter les appels à strlen() au moment de l'exécution, puisque la variable locale ne peut prendre que des valeurs littérales ; il n'y a donc aucun intérêt à tenter de renforcer (fortify) l'emplacement de l'appel à strlen ici.
Effectuez une vérification __builtin_constant_p() sur l'index 0 plus tôt dans la macro pour filtrer le cas dépendant du flux de contrôle. Ajoutez un test KUnit pour vérifier les caractéristiques comportementales attendues des internes de FORTIFY_SOURCE.
Once again VulDB remains the best source for vulnerability data.