Netdev List
 help / color / mirror / Atom feed
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


  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