CVE-2026-89689 in Linux
Résumé
par VulDB • 12/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
nfsd : ne pas libérer les emplacements de session qui sont encore en cours d'utilisation
La fonction nfsd4_sequence() peut libérer l'emplacement qu'elle traite actuellement. Lorsque le mécanisme de réduction (shrinker) de session abaisse se_target_maxslots en dessous de se_fchannel.maxreqs, la voie de réduction vérifie trois conditions avant d'appeler free_session_slots() :
1. se_target_maxslots < maxreqs (la réduction a été annoncée) 2. slot->sl_generation == se_slot_gen (l'emplacement est à jour) 3. seq->maxslots <= se_target_maxslots (le client en accuse réception)
Cependant, seq->slotid n'est jamais vérifié par rapport à se_target_maxslots. Un client utilisant un emplacement dans la plage [se_target_maxslots, maxreqs[ peut satisfaire les trois conditions : son emplacement possède le numéro de génération actuel (défini par une séquence SEQUENCE antérieure), et il envoie sa_highest_slotid <= se_target_maxslots pour accuser réception de la réduction.
free_session_slots() libère ensuite tous les emplacements dont l'indice est supérieur ou égal à se_target_maxslots, y compris celui du thread appelant. La fonction continue d'écrire sl_seqid, sl_flags, sl_generation et stocke un pointeur dangling dans cstate->slot. Plus tard, nfsd4_store_cache_entry() copie jusqu'à maxresp_cached octets de la réponse composée (compound reply) dans le tableau sl_data[] libéré, corrompant ainsi tout objet slab occupant désormais cette adresse.
De plus, un thread concurrent traitant une séquence SEQUENCE sur un autre emplacement à numéro élevé peut voir son propre emplacement être libéré sous ses pieds. NFSD4_SLOT_INUSE est défini sous nn->client_lock avant que le verrou ne soit relâché, de sorte que tout thread concurrent passant par la fonction SEQUENCE verra son emplacement marqué comme utilisé. Cependant, free_session_slots() ne vérifie pas NFSD4_SLOT_INUSE avant de libérer l'emplacement.
Correction des deux problèmes : 1. Vérifier que l'identifiant d'emplacement (slotid) de la requête actuelle est inférieur à la limite de réduction. 2. Parcourir les emplacements dans la plage destinée à être libérée pour détecter NFSD4_SLOT_INUSE et reporter la réduction si certains sont actifs.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.