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

[Breno Leitao]

On Sun, Sep 27, 2026 at 07:53:58AM +0100, David Laight wrote:
> On Fri, 25 Sep 2026 12:02:22 -0700
> Stanislav Fomichev <sdf.kernel@xxxxxxxxx> 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