Re: [PATCH net 1/2] ipv4: mcast: getsockopt: do not overwrite past optlen

[David Laight <david.laight.linux@gmail.com>]

On Tue, 11 Aug 2026 08:15:43 -0700
Jakub Kicinski <kuba@kernel.org> wrote:

> On Tue, 11 Aug 2026 05:19:17 -0700 Breno Leitao wrote:
> > So my question to you: can you point me to actual software that
> > passes a "small" optlen and expects the kernel to write past it? That
> > would help to decide about the two options above.  
> 
> If you are very confident that no such SW exists - we can try to queue
> this up for -next. (TBH I'm not, mcast specifically may be full of
> strange one off manually written user space (as opposed to common libraries)).
> 
> If we decide to change the behavior- we will probably have to wait
> until this makes it to an LTS release + some time for people to deploy.
> It can't be a fix.
> 
> So practically speaking it may be more expedient to add some hacks to
> cater to this case in the conversion, and then remove the hack. That'd
> be easier to revert if someone pipes up later that we broke their SW.
> 

I'm also pretty sure there is another sockopt that uses a count inside
the header to indicate the actual buffer length.
For that option the length supplied has to match the expected header length
and there is code to write back the corrected length with an error code.
I did a search earlier today but failed to find it again.
It would be in the patches/changes I did (locally) that made the getsockopt
protocol functions return either a negative errno or a positive length.
But I think those were done an SDD that pretty much lost all its contents
while powered off for some time.

I never did decide on the best way to handle code that wanted to update
'optlen' and return an error.
It is annoying because there are only a handful of cases in the entire source.

I would suggest (again) that these changes be done starting with the syscall
'glue' and adding an extra getsockopt_new() to the function call table(s).
Then changing the protocols one by one to provide the new function and
finally deleting the old entry.
That way each protocol code only needs changing once.

I'd also wrap the copy_to_iter() in an inline function so that most code
doesn't have to care about the implementation.

	David