CVE-2026-98581

Published: Ott 18, 2026 Last Modified: Ott 19, 2026

ExploitDB:

Other exploit source:

Google Dorks:

Description

AI Translation Available

In the Linux kernel, the following vulnerability has been resolved:

nfc: llcp: Fix list corruption / refcount desync in nfc_llcp_recv_dm()

nfc_llcp_recv_dm() handles DM(NOBOUND)/DM(REJ) for a socket that is still
linked on local->connecting_sockets: it looks the socket up with
nfc_llcp_connecting_sock_get(), sets sk->sk_state = LLCP_CLOSED and
returns, without taking the socket lock and without unlinking the socket
from the connecting_sockets list.

llcp_sock_release() selects the list to unlink from by sk_state: a socket
in LLCP_CONNECTING is unlinked from connecting_sockets, otherwise from the
sockets list. Because recv_dm left the socket physically on
connecting_sockets but in the LLCP_CLOSED state, release() takes the else
branch and calls nfc_llcp_sock_unlink(&local->sockets, sk). That runs
sk_del_node_init() while holding sockets.lock, i.e. it removes the socket
from the connecting_sockets hlist under the wrong lock. A concurrent
connect() linking another socket onto connecting_sockets under
connecting_sockets.lock then mutates the same hlist unserialized, which
corrupts the list and desyncs the sk_add_node()/sk_del_node_init()
sock_hold()/__sock_put() pairing. An unprivileged local process holding
LLCP sockets, with the DM supplied by the remote peer over an established
LLCP link, can drive this to leak kernel sockets without bound (the
mis-decrement goes through the non-freeing __sock_put() path, so the
object is never released), leading to memory exhaustion / DoS.

This is the same class of bug that was fixed in the sibling handler
nfc_llcp_recv_cc() by commit b493ea2765cc ('nfc: llcp: Fix use-after-free
race in nfc_llcp_recv_cc()'); recv_dm did not receive the equivalent fix.

Fix it the same way: take lock_sock(), re-check that the socket is still
hashed (release() may have won the race), and for the NOBOUND/REJ case
unlink it from connecting_sockets before moving it to LLCP_CLOSED. The
unlink drops the connecting_sockets membership reference via
sk_del_node_init(), leaving the socket unhashed, so the later
nfc_llcp_sock_unlink() in llcp_sock_release() becomes a no-op and no
double put occurs.

AI Generated Translation

Nel kernel Linux, è stata risolta la seguente vulnerabilità:

nfc: llcp: Correzione della corruzione della lista / desincronizzazione del refcount in nfc_llcp_recv_dm()

nfc_llcp_recv_dm() gestisce DM(NOBOUND)/DM(REJ) per una socket ancora collegata a local->connecting_sockets: cerca la socket con nfc_llcp_connecting_sock_get(), imposta sk->sk_state = LLCP_CLOSED e ritorna, senza acquisire il lock sulla socket e senza scollegare la socket dalla lista connecting_sockets.

llcp_sock_release() seleziona la lista da scollegare in base allo stato di sk: una socket in LLCP_CONNECTING viene scollegata da connecting_sockets, altrimenti dalla lista sockets. Poiché recv_dm lasciava la socket fisicamente su connecting_sockets ma nello stato LLCP_CLOSED, release() prende il ramo else e chiama nfc_llcp_sock_unlink(&local->sockets, sk). Questo esegue sk_del_node_init() mantenendo il lock sockets, cioè rimuove la socket da connecting_sockets sotto il lock sbagliato. Una connect() concorrente che collega un’altra socket su connecting_sockets sotto connecting_sockets.lock modifica la stessa hlist senza serializzazione, corrompendo la lista e causando la desincronizzazione tra sk_add_node()/sk_del_node_init() e sock_hold()/__sock_put(). Un processo locale non privilegiato che detiene socket LLCP, con il DM fornito dal peer remoto su un link LLCP stabilito, può sfruttare questa condizione per leakare socket kernel senza bound (il decrement errato passa attraverso il percorso __sock_put() non liberante, quindi l’oggetto non viene mai rilasciato), portando a esaurimento della memoria / DoS.

Si tratta della stessa classe di bug risolta nel gestore nfc_llcp_recv_cc() con il commit b493ea2765cc ("nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()"); recv_dm non aveva ricevuto la corrispondente correzione.

Correggilo allo stesso modo: acquisisci lock_sock(), ricontrolla che la socket sia ancora hashata (release() potrebbe aver vinto la gara), e per il caso NOBOUND/REJ scollega la socket da connecting_sockets prima di spostarla in LLCP_CLOSED. La scollegatura rimuove il riferimento alla membership di connecting_sockets tramite sk_del_node_init(), lasciando la socket non hashata, quindi la successiva nfc_llcp_sock_unlink() in llcp_sock_release() diventa un’operazione nulla e non si verifica un doppio __sock_put().