CVE-2026-93207 in Linux
Résumé
par VulDB • 24/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
SUNRPC : Réinitialisation à zéro de rpc_gss_wire_cred lors de l'entrée dans svcauth_gss_decode_credbody()
svcauth_gss_decode_credbody() écrit le champ rpc_gss_wire_cred de l'appelant, champ par champ, et n'affecte gc_ctx.len qu'en cas de succès (à la fin du traitement). Le stockage utilisé par l'appelant est svcdata->clcred, qui réside dans gss_svc_data spécifique à chaque requête de service (svc_rqst) et est réutilisé d'une requête à l'autre. Les échecs précoces lors du décodage laissent un état partiellement décodé mélangé aux résidus provenant de la requête précédente.
Le contrôle de précision sur body_len en fin de corps représente le cas le plus critique : xdr_stream_decode_opaque_inline() a déjà écrit gc_ctx.data avec un pointeur inline emprunté dans les pages XDR de la requête actuelle, mais gc_ctx.len conserve sa valeur antérieure. Une fois que les pages de la requête sont libérées, clcred en pool contient un pointeur dangling (dangling pointer) associé à une longueur obsolète.
Réinitialisez à zéro rpc_gss_wire_cred de l'appelant lors de l'entrée dans la fonction afin que chaque chemin de retour précoce laisse un cred entièrement initialisé à zéro, garantissant ainsi sa déterminisme. Sur le chemin du contrôle de précision en fin de corps, gc_ctx.len est désormais nul au lieu d'être obsolète, ce qui neutralise les consommateurs dépendants de la longueur tels que gss_svc_searchbyctx(), qui auraient autrement parcouru le pointeur dangling vers des données corrompues.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.