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/[email protected]/ Signed-off-by: Breno Leitao <[email protected]> --- 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/[email protected] To: David Heidelberg <[email protected]> To: "David S. Miller" <[email protected]> To: Eric Dumazet <[email protected]> To: Jakub Kicinski <[email protected]> To: Paolo Abeni <[email protected]> To: Simon Horman <[email protected]> To: Samuel Ortiz <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] --- 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 <[email protected]>
