From: Breno Leitao <leitao@debian.org>
To: David Laight <david.laight.linux@gmail.com>
Cc: David Ahern <dsahern@kernel.org>,
Ido Schimmel <idosch@nvidia.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
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
Subject: Re: [PATCH net 1/2] ipv4: mcast: getsockopt: do not overwrite past optlen
Date: Mon, 10 Aug 2026 05:48:53 -0700 [thread overview]
Message-ID: <anm9gImFEz6EkUZ9@gmail.com> (raw)
In-Reply-To: <20260807174402.2dfc12d6@pumpkin>
Hello David,
On Fri, Aug 07, 2026 at 05:44:02PM +0100, David Laight wrote:
> On Thu, 06 Aug 2026 02:42:00 -0700
> Breno Leitao <leitao@debian.org> wrote:
>
> > getsockopt(MCAST_MSFILTER) can write past the end of the buffer the caller
> > declared.
> >
> > This is because the copy_to_user() does not respect the optlen, and can
> > write over the allocated buffer, overwriting userspace undesired
> > memory
>
> Nak. This is just the way it is defined.
> The application provides a length that is just the header.
> As you noted the header contains details of the real buffer.
>
> There are quite a few sockopt like it, you have to support them.
> There may be some where the length isn't checked and is just assumed
> to be the right size - they have to continue to work as well.
Thanks for the review.
The generic getsockopt(2) contract says otherwise.
For getsockopt(), optlen is a value-result argument, initially
containing the size of the buffer pointed to by optval, and modified
on return to indicate the actual size of the value returned.
You are saying that we have userspace program in the wild that doesn't honour
the contract above, right?
On the set side (setsockopt) of the same option takes the opposite view.
It rejects calls if optlen is not properly set.
err = -EINVAL;
if (GROUP_FILTER_SIZE(gsf->gf_numsrc) > optlen)
goto out_free_gsf;
Back to getsockopt(2), I was trying to look for users it, and glibc
passes the full length for both options, with optlen and numsrc coming
from the same variable:
/* sysdeps/unix/sysv/linux/getsourcefilter.c */
socklen_t needed = GROUP_FILTER_SIZE(*numsrc);
gf->gf_numsrc = *numsrc;
result = __getsockopt (s, sol, MCAST_MSFILTER, gf, &needed);
and
/* sysdeps/unix/sysv/linux/getipv4sourcefilter.c */
socklen_t needed = IP_MSFILTER_SIZE (*numsrc);
imsf->imsf_numsrc = *numsrc;
int result = __getsockopt (s, SOL_IP, IP_MSFILTER, imsf, &needed);
So the clamp is a no-op for every caller that goes through libc.
So my conclusion is that this is a bug: setsockopt and glibc both treat optlen
as the buffer size, and I could not find anything relying on the get side not
doing so.
If you know of a caller that does, I will drop the series - I would rather
look at it than assume it exists and assume that it will break someone that is
leveraging a buggy behavior.
Thanks,
--breno
next prev parent reply other threads:[~2026-08-10 12:49 UTC|newest]
Thread overview: 8+ 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 [this message]
2026-08-10 21:21 ` David Laight
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=anm9gImFEz6EkUZ9@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=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