CVE-2026-31402

Résumé

Dans le noyau Linux, la vulnérabilité suivante a été résolue : nfsd : correction d'un débordement de tas dans le cache de rejeu LOCK NFSv4.0 Le cache de rejeu NFSv4.0 utilise un tampon en ligne fixe de 112 octets (rp_ibuf[NFSD4_REPLAY_ISIZE]) pour stocker les réponses d'opérations encodées. Cette taille a été calculée sur la base des réponses OPEN et ne tient pas compte des réponses de refus LOCK, qui incluent le propriétaire du verrou en conflit comme champ de longueur variable pouvant atteindre 1024 octets (NFS4_OPAQUE_LIMIT). Lorsqu'une opération LOCK est refusée en raison d'un conflit avec un verrou existant possédant un grand propriétaire, nfsd4_encode_operation() copie la réponse encodée complète dans le tampon de rejeu sous-dimensionné via read_bytes_from_xdr_buf() sans vérification des limites. Cela entraîne une écriture hors limites de type slab de jusqu'à 944 octets au-delà de la fin du tampon, corrompant la mémoire de tas adjacente. Cela peut être déclenché à distance par un attaquant non authentifié avec deux clients NFSv4.0 coopérants : l'un définit un verrou avec une chaîne de propriétaire de grande taille, puis l'autre demande un verrou en conflit pour provoquer le refus. Nous pourrions corriger cela en augmentant NFSD4_REPLAY_ISIZE pour permettre un opaque complet, mais cela augmenterait la taille de chaque stateowner, alors que la plupart des lockowners ne sont pas si grands. Au lieu de cela, corrigeons cela en vérifiant la longueur de la réponse encodée par rapport à NFSD4_REPLAY_ISIZE avant de copier dans le tampon de rejeu. Si la réponse est trop grande, définissez rp_buflen sur 0 pour ignorer la mise en cache de la charge utile de rejeu. Le statut est toujours mis en cache, et le client a déjà reçu la réponse correcte sur la requête d'origine.

• CVE-2026-31402Informationnel

  CVE-2026-31402