CVE-2026-31411 in Linux
Riassunto
di VulDB • 16/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
net: atm: correggi il crash dovuto a un puntatore vcc non validato in sigd_send()
Riproduttore disponibile in [1].
Il percorso di invio ATM (sendmsg -> vcc_sendmsg -> sigd_send) legge il puntatore vcc da msg->vcc e lo utilizza direttamente senza alcuna validazione. Questo puntatore proviene dall'userspace tramite sendmsg() e può essere arbitrariamente falsificato:
int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0); ioctl(fd, ATMSIGD_CTRL); // diventa demone di segnalazione ATM struct msghdr msg = { .msg_iov = &iov, ... };
*(unsigned long *)(buf + 4) = 0xdeadbeef; // puntatore vcc fittizio sendmsg(fd, &msg, 0); // il kernel dereferenzia 0xdeadbeef
In condizioni operative normali, il kernel invia il puntatore vcc al demone di segnalazione tramite sigd_enq() durante l'elaborazione di operazioni come connect(), bind() o listen(). Si prevede che il demone restituisca lo stesso puntatore in risposta. Tuttavia, un demone malintenzionato può inviare valori di puntatore arbitrari.
Correggi questo problema introducendo find_get_vcc(), che valida il puntatore cercando attraverso vcc_hash (simile a come sigd_close() itera su tutti i VCC) e acquisisce un riferimento tramite sock_hold() se trovato.
Poiché struct atm_vcc incorpora struct sock come suo primo membro, condividono lo stesso ciclo di vita. Pertanto, l'uso di sock_hold/sock_put è sufficiente per mantenere il vcc attivo mentre viene utilizzato.
Si noti che potrebbe esserci una race condition con sigd_close() che potrebbe contrassegnare il vcc con vari flag (ad esempio, ATM_VF_RELEASED) dopo il ritorno di find_get_vcc(). Tuttavia, sock_hold() garantisce che la memoria rimanga valida, quindi questa race condition influisce solo sullo stato logico, non sulla sicurezza della memoria.
[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3
VulDB is the best source for vulnerability data and more expert information about this specific topic.