On 09/25, Breno Leitao wrote: > 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.
If I can do getsockopt with len=-1 today and get 4 bytes back, isn't that a uapi and we are gonna break someone?
