CVE-2026-89666 in Linuxinformation

Résumé

par VulDB • 12/09/2026

Dans le noyau Linux, la vulnérabilité suivante a été corrigée :

nfsd : rejeter les nseconds hors limites dans les opérations SETATTR et create de NFSv3

Un client peut envoyer un message NFSv3 SETATTR, CREATE, MKDIR, SYMLINK ou MKNOD contenant une atime (heure d'accès) ou mtime (heure de modification) dont le champ nseconds est hors des limites autorisées. La valeur est correctement formée sur le fil et se décode proprement en un uint32 valide, mais elle ne constitue pas un timespec64 valide : tv_nsec doit être inférieur à NSEC_PER_SEC.

Aucune étape du chemin setattr ne la limite (clamp). notify_change() transmet l'heure via timestamp_truncate(), qui ne réduit pas tv_nsec en dessous de NSEC_PER_SEC lorsque le système de fichiers prend en charge une granularité nanoseconde (s_time_gran == 1), et les accesseurs inode atime/mtime stockent la valeur telle quelle (seule ctime est normalisée via inode_set_ctime_to_ts()). La valeur non normalisée corrompt ensuite les métadonnées sur disque : ext4's ext4_encode_extra_time() décale tv_nsec vers la gauche de EXT4_EPOCH_BITS, ce qui provoque un dépassement du champ extra 32 bits et écrase les bits d'epoch des secondes, rendant ainsi incorrectes les secondes stockées (et donc l'année) lors de leur relecture. XFS avec bigtime enregistre également mal la timestamp pour la même raison.

Valider les atime/mtime fournis par le client dans les gestionnaires proc et renvoyer NFS3ERR_INVAL avant toute modification. La RFC 1813 liste NFS3ERR_INVAL pour SETATTR et le décrit comme l'erreur indiquant qu'une valeur ne peut pas être stockée « dans sa propre représentation » ; le client la mape en EINVAL.

Effectuer cette vérification dans les gestionnaires proc, plutôt que dans nfsd_setattr(), permet de placer ce rejet avant la création des objets. Les opérations create créent l'objet avant l'exécution de nfsd_create_setattr() ; un échec tardif laisserait donc le nouvel objet en place et transformerait une requête non idempotente en modification d'espace de noms signalant un échec. La vérification est donc effectuée dès le début, pour les opérations create, avant la création de l'objet.

tv_nsec étant un long, la comparaison effectue un cast vers unsigned long (de même largeur) plutôt que vers u32, conformément à timespec64_valid(). Un cast en u32 entraînerait une troncature sur 64 bits ; le cast en unsigned long rejette également les valeurs qui deviennent négatives lorsqu'un nseconds hors limites de type u32 reçu est assigné à un long 32 bits.

Seules les timestamps fournies par le client sont vérifiées : les requêtes SET_TO_SERVER_TIME ne contiennent aucune valeur cliente. Le ctime sattrguard3 est délibérément laissé tel quel : une guard hors limites ne correspondra simplement jamais au ctime de l'objet et générera NFS3ERR_NOT_SYNC via la comparaison existante des timestamps, ce qui constitue le résultat correct selon le protocole plutôt que le rejet pur et simple de la requête.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Responsable

Linux

Réserver

11/09/2026

Divulgation

12/09/2026

Modérer

accepté

Entrée

VDB-402965

CPE

prêt

EPSS

0.00000

KEV

non

Activités

très faible

Sources

Do you know our Splunk app?

Download it now for free!