From: Breno Leitao <leitao@debian.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: David Laight <david.laight.linux@gmail.com>,
David Ahern <dsahern@kernel.org>,
Ido Schimmel <idosch@nvidia.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com, stable@vger.kernel.org,
Stanislav Fomichev <sdf@fomichev.me>
Subject: Re: [PATCH net 1/2] ipv4: mcast: getsockopt: do not overwrite past optlen
Date: Thu, 13 Aug 2026 07:46:08 -0700 [thread overview]
Message-ID: <anxqRqlFXsoc1wwc@gmail.com> (raw)
In-Reply-To: <20260811081543.26d18828@kernel.org>
Hello Jakub,
On Tue, Aug 11, 2026 at 08:15:43AM -0700, Jakub Kicinski 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.
Thanks. I was mostly trying to find out whether this is a real problem
before creating this quirk, and your intuition is helpful here. I will
proceed with the quirk then.
For the sockopt_t conversion I can expand the iterator mid-air for the
few options that size their reply from a count in the header, so the
conversion stays a no-op for userspace.
Expanding is only safe for a user buffer, though - a kernel-backed
optval might be too risky, I would say. And it will not break anything,
given we don't have in-kernel users for this yet (given the __user
params)
I might come up with a helper like this one:
static inline void sockopt_expand_out(sockopt_t *opt, size_t len)
{
if (len < iov_iter_count(&opt->iter_out))
// No quirk required
return;
/* Only a user buffer can be larger than the caller
* declared; a kernel-backed optval has nothing behind it.
*/
if (WARN_ON_ONCE(!iter_is_ubuf(&opt->iter_out)))
return;
iov_iter_reexpand(&opt->iter_out, len);
}
and then, at the call site, right after the header is read and before
anything is written back:
/* The reply is sized by gf_numsrc, not by optlen, which only has
* to cover the fixed header. Grow the output iterator to what the
* header declares, or the source list gets truncated.
*/
sockopt_expand_out(opt, size_add(size0,
size_mul(gsf.gf_numsrc,
sizeof(gsf.gf_slist_flex[0]))));
(All completely untested so far.)
Thanks for the suggestion,
--breno
next prev parent reply other threads:[~2026-08-13 14:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 9:41 [PATCH net 0/2] net: mcast: do not write past optlen in the source filter getsockopt Breno Leitao
2026-08-06 9:42 ` [PATCH net 1/2] ipv4: mcast: getsockopt: do not overwrite past optlen Breno Leitao
2026-08-07 16:44 ` David Laight
2026-08-10 12:48 ` Breno Leitao
2026-08-10 21:21 ` David Laight
2026-08-11 12:19 ` Breno Leitao
2026-08-11 15:15 ` Jakub Kicinski
2026-08-11 17:51 ` David Laight
2026-08-13 14:49 ` Breno Leitao
2026-08-13 14:46 ` Breno Leitao [this message]
2026-08-06 9:42 ` [PATCH net 2/2] ipv6: mcast: do not write past optlen in the source filter getsockopt Breno Leitao
2026-08-07 16:44 ` David Laight
2026-08-07 14:38 ` [PATCH net 0/2] net: " Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=anxqRqlFXsoc1wwc@gmail.com \
--to=leitao@debian.org \
--cc=davem@davemloft.net \
--cc=david.laight.linux@gmail.com \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kernel-team@meta.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox