All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.