IPv4's do_ip_getsockopt() rejects a negative optlen right after reading
it. do_ipv6_getsockopt() never has, and nothing downstream treats it as
an error either: len is an int, but every consumer compares it unsigned,
so -1 behaves as a huge value and each site clamps to its own reply
size.
len = min_t(unsigned int, sizeof(int), len);
So getsockopt(fd, SOL_IPV6, IPV6_TCLASS, buf, &len) with len set to -1
answers 4 bytes and reports 4, rather than failing.
This is a bug ready to bite us in the near future, let's get this fixed.
I've found this because testing the rest of the patch was returning
inconsistency when optlen = -1.
Later patches make the check unreachable, since sockopt_init_user() and
sockptr_to_sockopt() both reject a negative length before the switch
runs. Keep it as a guard; the fix stands on its own here.
Signed-off-by: Breno Leitao <[email protected]>
---
net/ipv6/ipv6_sockglue.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 4b3536571c9804..5c6a0819a2aaff 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -1002,6 +1002,8 @@ int do_ipv6_getsockopt(struct sock *sk, int level, int
optname,
if (copy_from_sockptr(&len, optlen, sizeof(int)))
return -EFAULT;
+ if (len < 0)
+ return -EINVAL;
switch (optname) {
case MCAST_MSFILTER:
if (in_compat_syscall())
--
2.53.0-Meta
