CVE-2026-90225: nfc: llcp: read llcp_sock->local under the socket lock in getsockopt
In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: read llcpsock->local under the socket lock in getsockopt
nfcllcpgetsockopt() read llcpsock->local before locksock(sk) and then dereferenced the cached pointer inside the locked region. llcpsockbind() assigns and clears llcpsock->local under the same socket lock, dropping the last reference on its error path. A getsockopt() racing an in-flight bind() can observe the pointer, block on locksock(), and then dereference a freed nfcllcplocal once bind() has unwound.
Move the llcpsock->local read and the NULL check inside the locksock(sk) region so bind() cannot mutate or free the pointer between the load and the use.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
The race requires concurrent operations on the same NFC LLCP socket: a getsockopt() call must read the local pointer while an in-flight bind() later clears and frees it on its error path. The getsockopt() call then waits for the socket lock and dereferences the stale pointer after bind() has unwound.
Are systems without NFC LLCP socket use exposed?
The described race is in the NFC LLCP socket getsockopt and bind paths. Systems that do not use NFC LLCP sockets would not exercise the vulnerable code path described.
How can administrators tell whether the fix is present?
Check whether the kernel includes a change that moves the llcp_sock->local read and NULL check inside the lock_sock(sk) region in nfc_llcp_getsockopt(). The listed stable references identify commits containing the resolution.