On Fri, 25 Sep 2026 12:02:22 -0700
Stanislav Fomichev <[email protected]> wrote:
> 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?
>
Treating negative values as 4 goes way back into the pre-historic annals,
And I agree that there could be code out there that fails to set a value
so passes 'dirty stack' and it always works because it never passed 0..3.
I suspect all the per-protocol code ought to be passed an unsigned 'len'
(and return back a possibly modified value for the wrapper code to give
to the user).
Then you have somewhere:
/* Historic bug compatibility */
ulen = len >= 0 ? len : 4;
David
