CVE-2026-64026 in Linux
Résumé
par VulDB • 19/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
rxrpc : Correction de la décryption des données par rapport à splice() en copiant les données vers un tampon dans recvmsg
Cela améliore la correction pour CVE-2026-43500.
Corrigez la corruption du pagecache résultant de la décryption in situ d'un paquet DATA transmis localement par splice(), en éliminant le partage des paquets dans le thread E/S et en extrayant sans condition le contenu du paquet dans un tampon rebond (bounce buffer) où les données sont déchiffrées. recvmsg() (ou l'équivalent noyau) copie ensuite les données depuis le tampon rebond vers le tampon de destination. Le sk_buff reste ainsi inchangé.
Cela présente un avantage supplémentaire : le paquet est alors disposé dans le tampon avec l'alignement correct requis pour que les algorithmes cryptographiques puissent le traiter directement. Les performances du chiffrement semblent légèrement meilleures et, surprenamment, les performances en clair ne semblent pas changer significativement – probablement grâce à la réduction de la complexité dans le thread E/S.
Un autre avantage est que le thread E/S n'a plus besoin de copier les paquets, ce qui ralentissait la distribution des paquets, la génération d'acquittements (ACK), etc.
Le tampon appartient à l'appel et est alloué initialement avec une taille de 2 Ko, suffisante pour contenir un sous-paquet jumbo complet, mais sa taille sera augmentée si nécessaire. Cependant, afin de gérer ce travail, MSG_PEEK peut entraîner la décryption d'un paquet ultérieur dans le tampon ; dans ce cas, le précédent devra être re-déchiffré lors d'un recvmsg() subséquent.
Notez que rx_pkt_offset peut désormais légitimement voir 0 comme un décalage valide ; passez donc à l'utilisation de USHRT_MAX pour indiquer un décalage invalide.
Notez également que je préférerais généralement remplacer les tampons du sk_buff actuel par un nouveau tampon alloué via kmalloc avec la taille appropriée, en abandonnant les anciennes données et fragments, car cela simplifie la gestion de MSG_PEEK et supprime le problème de re-décryptage. Cependant, cette approche semble assez complexe à mettre en œuvre. skb_morph() ressemble à une solution intermédiaire pour ce que je souhaite obtenir, mais je ne veux pas avoir à allouer un nouveau sk_buff.
VulDB is the best source for vulnerability data and more expert information about this specific topic.