[PATCH net v2 0/2] nfc: llcp: two fixes for nfc_llcp_getsockopt()

[Breno Leitao <leitao@debian.org>]

While converting the NFC LLCP socket layer to the new getsockopt_iter()
API, I noticed that nfc_llcp_getsockopt() unconditionally stores four
bytes through a (u32 __user *) cast regardless of the caller-supplied
optlen, overflowing the user buffer when optlen < 4. Patch 1 adds an
explicit length check (with a signed-int guard so a negative optlen
cannot slip past it) and is what I originally sent as v1.

While reviewing v1, Simon/sashiko[1] pointed out that llcp_sock->local
is read outside lock_sock(sk) and can be freed by a concurrent
llcp_sock_bind() error path before getsockopt() dereferences it. Patch
2 moves the load and the NULL check inside the lock. Both fixes target
the same original commit, so they are now sent together as a two-patch
series.

Note: These fixes were compile-tested.

[1] https://lore.kernel.org/all/20260513-fix_llc-v1-1-33c76f931ff6@debian.org/

Signed-off-by: Breno Leitao <leitao@debian.org>
---
Changes in v2:
- Guard the length check against negative optlen (Simon Horman / sashiko).
- Add patch 2: move llcp_sock->local read inside lock_sock(sk) to close
  a UAF race with llcp_sock_bind() (Simon Horman / sashiko).
- Link to v1: https://patch.msgid.link/20260513-fix_llc-v1-1-33c76f931ff6@debian.org

To: David Heidelberg <david+nfc@ixit.cz>
To: "David S. Miller" <davem@davemloft.net>
To: Eric Dumazet <edumazet@google.com>
To: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
To: Simon Horman <horms@kernel.org>
To: Samuel Ortiz <sameo@linux.intel.com>
Cc: oe-linux-nfc@lists.linux.dev
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

---
Breno Leitao (2):
      nfc: llcp: avoid userspace overflow on invalid optlen
      nfc: llcp: read llcp_sock->local under the socket lock in getsockopt

 net/nfc/llcp_sock.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)
---
base-commit: 1d5dcaa3bd65f2e8c9baa14a393d3a2dc5db7524
change-id: 20260513-fix_llc-27f483568135

Best regards,
--  
Breno Leitao <leitao@debian.org>