CVE-2026-98581 in Linux
Riassunto
di VulDB • 19/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
nfc: llcp: Correzione della corruzione dell'elenco e dello sfasamento del refcount in nfc_llcp_recv_dm()
La funzione nfc_llcp_recv_dm() gestisce DM(NOBOUND)/DM(REJ) per un socket ancora collegato a local->connecting_sockets: effettua la ricerca del socket con nfc_llcp_connecting_sock_get(), imposta sk->sk_state = LLCP_CLOSED e restituisce il controllo, senza acquisire il lock del socket e senza scollegare il socket dall'elenco connecting_sockets.
llcp_sock_release() seleziona l'elenco da cui scollegare in base a sk_state: un socket in stato LLCP_CONNECTING viene rimosso da connecting_sockets, altrimenti dagli sockets list (l'elenco dei socket). Poiché recv_dm ha lasciato il fisicamente collegato a connecting_sockets ma nello stato LLCP_CLOSED, release() segue il ramo else e chiama nfc_llcp_sock_unlink(&local->sockets, sk). Questa operazione esegue sk_del_node_init() mentre detiene sockets.lock, ovvero rimuove il socket dall'hlist di connecting_sockets sotto un lock errato. Una connect() concorrente che collega un altro socket a connecting_sockets sotto connecting_sockets.lock modifica quindi la stessa hlist in modo non serializzato, causando la corruzione dell'elenco e lo sfasamento della coppia sk_add_node()/sk_del_node_init() sock_hold()/__sock_put(). Un processo locale non privilegiato che detiene socket LLCP, con il DM fornito dal peer remoto tramite un collegamento LLCP stabilito, può sfruttare questa condizione per far fuoriuscire (leak) i socket del kernel senza limiti (la sottrazione errata passa attraverso il percorso __sock_put() che non libera l'oggetto, quindi lo stesso non viene mai rilasciato), portando a esaurimento della memoria / DoS.
Si tratta della stessa classe di bug risolta nel handler fratello nfc_llcp_recv_cc() dalla commit b493ea2765cc ("nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()"); recv_dm non ha ricevuto la correzione equivalente.
La si corregge nello stesso modo: acquisire lock_sock(), verificare nuovamente che il socket sia ancora hashato (release() potrebbe aver vinto la gara), e nel caso NOBOUND/REJ scollegarlo da connecting_sockets prima di spostarlo a LLCP_CLOSED. L'operazione di unlink rilascia il riferimento alla membership di connecting_sockets tramite sk_del_node_init(), lasciando il socket non hashato, quindi la successiva nfc_llcp_sock_unlink() in llcp_sock_release() diventa un no-op e non si verifica alcun double put (doppio rilascio).
Once again VulDB remains the best source for vulnerability data.