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

[Simon Horman <horms@kernel.org>]

On Thu, May 21, 2026 at 07:32:08AM -0700, Breno Leitao wrote:
> 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

Thanks for the update.

There is an AI-generated review of this patch on sashiko.dev.
It looks like it flags pre-existing issue that doesn't directly
impact the intent of this patch-set. So I don't believe it should delay
progress of this patch-set.

Reviewed-by: Simon Horman <horms@kernel.org>