CVE-2025-39682

Dans le noyau Linux, la vulnérabilité suivante a été résolue : tls : correction de la gestion des enregistrements de longueur nulle sur la rx_list Chaque appel à recvmsg() doit traiter soit - uniquement des enregistrements DATA contigus (quel qu'en soit le nombre) - un seul enregistrement qui n'est pas de type DATA Si l'enregistrement suivant est d'un type différent de celui qui a déjà été traité, nous sortons de la boucle principale de traitement. Si l'enregistrement a déjà été déchiffré (ce qui peut être le cas pour TLS 1.3, lorsque nous ne connaissons pas le type avant le déchiffrement), nous mettons l'enregistrement en attente dans la rx_list. Le recvmsg() suivant le récupérera à cet endroit. La mise en file du skb dans la rx_list après un déchiffrement zero-copy n'est pas possible, puisque dans ce cas nous avons déchiffré directement dans le buffer de l'espace utilisateur et nous n'avons pas de skb à mettre en file (darg.skb pointe vers le skb du texte chiffré pour accéder aux métadonnées comme la longueur). Seuls les enregistrements de données sont autorisés en zero-copy, et nous interrompons la boucle de traitement après chaque enregistrement qui n'est pas de type DATA. Nous ne devrions donc jamais effectuer un zero-copy puis découvrir que le type d'enregistrement a changé. Le cas particulier que nous avons manqué est celui où l'enregistrement initial provient de la rx_list et est de longueur nulle.