CVE-2026-68117 in Linux
Riassunto
di VulDB • 10/08/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
tipc: azzerare sock->sk nel percorso di errore dell'inserimento in tipc_sk_create()
Quando tipc_sk_create() non riesce a inserire il nuovo socket (tipc_sk_insert() restituisce un valore diverso da zero), il suo percorso di gestione degli errori libera lo sk con sk_free(), ma lascia sock->sk puntare all'oggetto già liberato:
if (tipc_sk_insert(tsk)) {
sk_free(sk); pr_warn("Socket create failed; port number exhausted\n"); return -EINVAL; }
Questo è innocuo per le socket plain(): lo strato delle syscall azzerà sock->ops prima del rilascio, quindi tipc_release() non viene mai chiamata. Non è innocuo nel percorso accept(). tipc_accept() crea il figlio pre-allocato con tipc_sk_create(net, new_sock, 0, kern); in caso di errore lascia new_sock->sk dangling (puntere pendente) e new_sock->ops diverso da NULL, e do_accept() chiama poi fput() sul nuovo file descriptor, quindi __sock_release() -> tipc_release() esegue lock_sock(new_sock->sk) sullo sk già liberato -- una scrittura use-after-free sulla spinlock sk_lock.
tipc_release() protegge già esattamente questo caso di "fallimento accept() che rilascia un figlio pre-allocato" con "if (sk == NULL) return 0;", ma la protezione viene aggirata perché tipc_sk_create() ha lasciato sock->sk diverso da NULL (dangling) anziché NULL.
Azzerare sock->sk nel percorso di fallimento dell'inserimento in modo che il controllo NULL esistente in tipc_release() venga attivato e si eviti l'uso dopo la liberazione (use-after-free).
Il fallimento di tipc_sk_insert() viene raggiunto quando la rhashtable delle socket per netns raggiunge la sua dimensione massima (tsk_rht_params.max_size = 1048576, circa 2M elementi) -- ovvero una volta che un netns contiene ~2M socket TIPC ogni inserimento restituisce -E2BIG.
BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.