UBUNTU-CVE-2026-98581: Use After Free

In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: Fix list corruption / refcount desync in nfcllcprecvdm() nfcllcprecvdm() handles DM(NOBOUND)/DM(REJ) for a socket that is still linked on local->connectingsockets: it looks the socket up with nfcllcpconnectingsockget(), sets sk->skstate = LLCPCLOSED and returns, without taking the socket lock and without unlinking the socket from the connectingsockets list. llcpsockrelease() selects the list to unlink from by skstate: a socket in LLCPCONNECTING is unlinked from connectingsockets, otherwise from the sockets list. Because recvdm left the socket physically on connectingsockets but in the LLCPCLOSED state, release() takes the else branch and calls nfcllcpsockunlink(&local->sockets, sk). That runs skdelnodeinit() while holding sockets.lock, i.e. it removes the socket from the connectingsockets hlist under the wrong lock. A concurrent connect() linking another socket onto connectingsockets under connectingsockets.lock then mutates the same hlist unserialized, which corrupts the list and desyncs the skaddnode()/skdelnodeinit() sockhold()/sockput() 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 sockput() 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 nfcllcprecvcc() by commit b493ea2765cc ("nfc: llcp: Fix use-after-free race in nfcllcprecvcc()"); recvdm did not receive the equivalent fix. Fix it the same way: take locksock(), re-check that the socket is still hashed (release() may have won the race), and for the NOBOUND/REJ case unlink it from connectingsockets before moving it to LLCPCLOSED. The unlink drops the connectingsockets membership reference via skdelnodeinit(), leaving the socket unhashed, so the later nfcllcpsockunlink() in llcpsockrelease() becomes a no-op and no double put occurs.