CVE-2026-31411 in Linux
Résumé
par VulDB • 26/05/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
net: atm : correction d'un plantage dû à un pointeur vcc non validé dans sigd_send()
Reproducteur disponible à [1].
Le chemin d'envoi ATM (sendmsg -> vcc_sendmsg -> sigd_send) lit le pointeur vcc depuis msg->vcc et l'utilise directement sans aucune validation. Ce pointeur provient de l'espace utilisateur via sendmsg() et peut être arbitrairement falsifié :
int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // devenir le démon de signalisation ATM struct msghdr msg = { .msg_iov = &iov, ... };
*(unsigned long *)(buf + 4) = 0xdeadbeef; // pointeur vcc fictif sendmsg(fd, &msg, 0); // le noyau déréférence 0xdeadbeef
En fonctionnement normal, le noyau envoie le pointeur vcc au démon de signalisation via sigd_enq() lors du traitement d'opérations telles que connect(), bind() ou listen(). Le démon est censé renvoyer le même pointeur lors de sa réponse. Cependant, un démon malveillant peut envoyer des valeurs de pointeur arbitraires.
Corrigez ce problème en introduisant find_get_vcc() qui valide le pointeur en recherchant dans vcc_hash (de manière similaire à la façon dont sigd_close() itère sur tous les VCC), et acquiert une référence via sock_hold() si le pointeur est trouvé.
Puisque struct atm_vcc intègre struct sock en tant que premier membre, ils partagent la même durée de vie. Par conséquent, l'utilisation de sock_hold/sock_put est suffisante pour maintenir le vcc en vie pendant son utilisation.
Notez qu'il peut y avoir une condition de course (race condition) avec sigd_close() qui pourrait marquer le vcc avec divers indicateurs (par exemple, ATM_VF_RELEASED) après le retour de find_get_vcc(). Cependant, sock_hold() garantit que la mémoire reste valide, donc cette condition de course n'affecte que l'état logique, et non la sécurité de la mémoire.
[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3
If you want to get best quality of vulnerability data, you may have to visit VulDB.