CVE-2026-98581

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.