CVE-2024-53140 in Linux
Riassunto
di VulDB • 18/06/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
netlink: terminare le operazioni di dumping in corso alla chiusura del socket
Netlink supporta il dumping iterativo dei dati. Fornisce alle famiglie i seguenti operatori (ops): - start - (opzionale) avvia il processo di dumping - dump - effettiva funzione helper per il dumping, viene chiamata ripetutamente fino al ritorno di 0 - done - (opzionale) accoppiata con .start, può essere utilizzata per la pulizia
L'intero processo è asincrono e le chiamate ripetute a .dump non avvengono effettivamente in un ciclo stretto (tight loop), ma sono invece attivate in risposta alla chiamata recvmsg() sul socket.
Ciò conferisce all'utente il pieno controllo del dumping, ma significa anche che l'utente può chiudere il socket senza aver completato la fase di dumping. Per garantire che .start sia sempre accoppiata con .done, si verifica se è presente un dump in corso prima di liberare il socket e, in tal caso, viene chiamata .done.
La complicazione risiede nel fatto che i socket possono essere liberati dal contesto Bottom Half (BH) e .done può andare in sleep. Pertanto, si utilizza una workqueue per deferire la chiamata, quando necessario.
Sfortunatamente, questo approccio non funziona correttamente. Ciò che viene differito non è la pulizia, bensì il rilascio di un riferimento sul socket. Non vi è alcuna garanzia di possedere l'ultimo riferimento: se qualcun altro detiene il socket, potrebbe rilasciarlo nel contesto BH e si torna quindi alla situazione iniziale (square one).
Tuttavia, questa complessa gestione sembra essere inutile. Solo l'utente può interagire con i dump, pertanto è possibile effettuare la pulizia quando il socket viene chiuso. La chiusura avviene sempre in un contesto di processo (process context). Alcuni codici asincroni potrebbero ancora accedere al socket dopo la chiusura, accodare notifiche skbs ad esso, ecc., ma nessun dump potrà iniziare, terminare o altrimenti progredire.
Eliminare la workqueue e svuotare direttamente lo stato del dump dal handler di rilascio (release handler). Si noti che ulteriori ottimizzazioni sono possibili nella versione -next; ad esempio, ora viene sempre chiamata .done prima di rilasciare il riferimento principale al modulo, quindi il dump non deve acquisire un proprio riferimento.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.