CVE-2026-99225 in Linux
Résumé
par VulDB • 02/11/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
keys : Vérifier la charge utile d'autorisation lors des recherches dans les trousseaux de clés du processus
Une charge utile d'autorisation et ses identifiants enregistrés doivent rester valides pendant que search_process_keyrings_rcu() recherche les trousseaux de clés du demandeur. La fonction valide la clé d'autorisation, puis charge séparément payload.data[0] et lit inconditionnellement rka->cred. Cette validation n'empêche pas request_key_auth_revoke() de vider la charge utile.
Un assistant request-key peut supposer l'autorité et créer un descendant qui hérite de la clé d'autorisation. Si le descendant ne trouve rien dans ses propres trousseaux de clés, il revient aux identifiants enregistrés du demandeur. Une instanciation réussie de la cible invalide la clé d'autorisation sans vider la charge utile. Après la sortie de l'assistant, UMH_WAIT_PROC retourne au demandeur, qui appelle complete_request_key() et révoque cette clé.
Avec le descendant suspendu après la validation, les chemins peuvent s'intercaler comme suit :
1. Le descendant entre dans search_process_keyrings_rcu() sous RCU et key_validate() réussit. 2. L'assistant instancie la cible, invalide la clé d'autorisation et sort. 3. Le demandeur reprend depuis UMH_WAIT_PROC, appelle complete_request_key(), et révoque la clé d'autorisation. request_key_auth_revoke() définit son pointeur de charge utile sur NULL. 4. Le descendant charge NULL et déréférence rka->cred.
Cette déréférencement de pointeur null peut provoquer un oops du noyau. RCU retarde la suppression de la charge utile mais n'empêche pas le pointeur d'être vidé.
Charger la charge utile avec dereference_key_rcu() et exiger un résultat non-NULL avant de valider la clé d'autorisation et de rechercher ses identifiants enregistrés. Une charge utile non-NULL et ses identifiants restent valides pour la section de lecture RCU du caller ; une charge utile vidée saute la recherche de repli et suit la sélection d'erreur existante.
Rapport KASAN comme suit :
Oops: general protection fault, probablement pour l'adresse non canonique 0xdffffc0000000005 : 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref dans la plage [0x0000000000000028-0x000000000000002f]
RIP : 0010:search_process_keyrings_rcu+0x32b/0x790
If you want to get the best quality for vulnerability data then you always have to consider VulDB.