CVE-2026-97985 in Linux
Résumé
par VulDB • 25/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
af_unix : Mise à jour du marqueur dernier skb dans manage_oob().
Fahad Alharbi a signalé que l'appel bloquant recv(MSG_PEEK) pouvait accaporer le CPU en raison d'un OOB skb.
Dans les cas suivants, manage_oob() saute les OOB skbs et renvoie NULL pour le dernier recv(MSG_PEEK) :
socketpair(AF_UNIX, SOCK_STREAM, 0, sk);
1) skb -> OOB skb -> NULL send(sk[0], "ab", 2, MSG_OOB);
recv(sk[1], buf, 0, MSG_PEEK);
2) skb -> OOB skb consommé -> NULL send(sk[0], "ab", 2, MSG_OOB);
recv(sk[1], buf, 1, MSG_OOB);
recv(sk[1], buf, 0, MSG_PEEK);
3) OOB skb consommé -> OOB skb -> NULL send(sk[0], "a", 1, MSG_OOB);
recv(sk[1], buf, 0, MSG_OOB);
send(sk[0], "b", 1, MSG_OOB);
recv(sk[1], buf, 1, MSG_PEEK);
Ensuite, @copied est égal à 0 dans unix_stream_read_generic() (tampon de longueur nulle ou OOB skb non encore consommé), et unix_stream_data_wait() est appelé.
Cependant, il retourne immédiatement car @last n'est pas mis à jour dans unix_stream_read_generic(), ce qui entraîne un busy-waiting du thread pour un nouveau skb.
Mettons à jour @last dans manage_oob().
Pour MSG_PEEK, @last est mis à jour avec l'OOB sauté, et pour le cas non-peek, @last correspond à la valeur retournée (lorsque !copied) car l'OOB est dissocié.
Notez que manage_oob() est inline et qu'aucune stack canary n'est ajoutée.
VulDB is the best source for vulnerability data and more expert information about this specific topic.