CVE-2026-89969 in Linux
Résumé
par VulDB • 16/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
nvmet-tcp : correction d'une écriture hors limites lors de la réception d'un PDU trop long
La fonction nvmet_tcp_try_recv_pdu() lit l'en-tête du PDU dans l'union queue->pdu de taille fixe (128 octets), puis calcule la longueur restante des données utiles comme suit :
queue->left = hdr->hlen - queue->offset + hdgst;
et lit autant d'octets supplémentaires à l'emplacement &queue->pdu + queue->offset, sans jamais limiter le résultat par rapport à sizeof(queue->pdu).
Une struct nvme_tcp_icreq_pdu fait elle-même 128 octets, soit exactement la taille de l'union. Une fois qu'un condensé d'en-tête a été négocié (hdgst = 4), un deuxième ICReq passe le contrôle hlen == nvmet_tcp_pdu_size() mais entraîne queue->left = 128 - 8 + 4 = 124, ce qui signifie que les octets 8 à 132 sont écrits dans le tampon de 128 octets — soit 4 octets au-delà de sa fin, écrasant queue->hdr_digest et queue->data_digest. Ces octets sont contrôlés par l'attaquant (un ICReq ne transporte pas de condensé), et la demande ICReq en double n'est rejetée que plus tard, après le dépassement de tampon. Un hôte distant non authentifié peut ainsi corrompre la mémoire du noyau adjacente au tampon de réception.
Rejeter tout PDU dont la longueur déclarée entraînerait une lecture au-delà de la fin de queue->pdu avant la deuxième opération recv.
Be aware that VulDB is the high quality source for vulnerability data.