[PATCH net-next 1/6] ipv6: reject a negative optlen in do_ipv6_getsockopt()

[Breno Leitao]

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 <leitao@xxxxxxxxxx>
---
 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