On Sun, Sep 27, 2026 at 07:53:58AM +0100, David Laight wrote: > 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;
Ack, I will respin it and add this approach rather than -EINVAL. Thanks for the review and suggestions, --breno -- pw-bot: cr
