Netdev List
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: "David S. Miller" <davem@davemloft.net>,
	 Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>,
	 Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	 Shuah Khan <shuah@kernel.org>,
	David Heidelberg <david+nfc@ixit.cz>,
	 Samuel Ortiz <sameo@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	 linux-kselftest@vger.kernel.org, oe-linux-nfc@lists.linux.dev,
	 kernel-team@meta.com, Breno Leitao <leitao@debian.org>
Subject: [PATCH net] nfc: llcp: avoid userspace overflow on invalid optlen
Date: Wed, 13 May 2026 03:57:54 -0700	[thread overview]
Message-ID: <20260513-fix_llc-v1-1-33c76f931ff6@debian.org> (raw)

nfc_llcp_getsockopt() returns each of its option values via:

	put_user(value, (u32 __user *) optval);

The (u32 __user *) cast tells put_user() to store sizeof(u32) = 4
bytes, regardless of what optlen the caller supplied. The earlier
clamp

	len = min_t(u32, len, sizeof(u32));

only affects the optlen value that is later reported back to user
space; it does not constrain the put_user() store itself.

If a caller invokes getsockopt(NFC_LLCP_RW/MIUX/REMOTE_*) with
optlen < 4 (for example optlen = 1 against a single-byte buffer),
the kernel still writes 4 bytes into optval, scribbling up to 3
bytes of the caller's adjacent memory.

That violates the getsockopt(2) contract that the kernel must not write
more than *optlen bytes into the user buffer.

All five supported optnames (NFC_LLCP_RW, NFC_LLCP_MIUX,
NFC_LLCP_REMOTE_MIU, NFC_LLCP_REMOTE_LTO, NFC_LLCP_REMOTE_RW)
are affected because they share the same put_user() pattern.

Reject any call with optlen < sizeof(u32) up front so the
put_user() stores always have enough room. This formalises the
implicit u32 ABI these options have always returned.o

Maybe it is possible to change nfc_llcp_getsockopt() to accept optlen
< 4, but this might be a riskier operation than just keep the current
approach and guarantee that users are doing the right thing.

Fixes: 26fd76cab2e6 ("NFC: llcp: Implement socket options")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
 net/nfc/llcp_sock.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/nfc/llcp_sock.c b/net/nfc/llcp_sock.c
index f1be1e84f6653..dc74e725ddd05 100644
--- a/net/nfc/llcp_sock.c
+++ b/net/nfc/llcp_sock.c
@@ -319,6 +319,9 @@ static int nfc_llcp_getsockopt(struct socket *sock, int level, int optname,
 	if (get_user(len, optlen))
 		return -EFAULT;
 
+	if (len < sizeof(u32))
+		return -EINVAL;
+
 	local = llcp_sock->local;
 	if (!local)
 		return -ENODEV;

---
base-commit: 1d5dcaa3bd65f2e8c9baa14a393d3a2dc5db7524
change-id: 20260513-fix_llc-27f483568135

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


                 reply	other threads:[~2026-05-13 10:58 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260513-fix_llc-v1-1-33c76f931ff6@debian.org \
    --to=leitao@debian.org \
    --cc=davem@davemloft.net \
    --cc=david+nfc@ixit.cz \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oe-linux-nfc@lists.linux.dev \
    --cc=pabeni@redhat.com \
    --cc=sameo@linux.intel.com \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox