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 <[email protected]>
---
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 <[email protected]>
