All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	John Fastabend <john.fastabend@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Simon Horman <horms@kernel.org>,
	Kuniyuki Iwashima <kuniyu@google.com>,
	Willem de Bruijn <willemb@google.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	bpf@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v3 2/9] net/l2tp: Add missing sa_family validation in pppol2tp_sockaddr_get_info
Date: Thu, 23 Oct 2025 09:01:28 -0700	[thread overview]
Message-ID: <202510230900.5754A094@keescook> (raw)
In-Reply-To: <52c7bbac-da08-44d5-b1ec-315ce001b42a@redhat.com>

On Thu, Oct 23, 2025 at 12:47:32PM +0200, Paolo Abeni wrote:
> On 10/20/25 11:26 PM, Kees Cook wrote:
> > While reviewing the struct proto_ops connect() and bind() callback
> > implementations, I noticed that there doesn't appear to be any
> > validation that AF_PPPOX sockaddr structures actually have sa_family set
> > to AF_PPPOX. The pppol2tp_sockaddr_get_info() checks only look at the
> > sizes.
> > 
> > I don't see any way that this might actually cause problems as specific
> > info fields are being populated, for which the existing size checks are
> > correct, but it stood out as a missing address family check.
> > 
> > Add the check and return -EAFNOSUPPORT on mismatch.
> > 
> > Signed-off-by: Kees Cook <kees@kernel.org>
> > ---
> >  net/l2tp/l2tp_ppp.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
> > index 5e12e7ce17d8..b7a9c224520f 100644
> > --- a/net/l2tp/l2tp_ppp.c
> > +++ b/net/l2tp/l2tp_ppp.c
> > @@ -535,6 +535,13 @@ struct l2tp_connect_info {
> >  static int pppol2tp_sockaddr_get_info(const void *sa, int sa_len,
> >  				      struct l2tp_connect_info *info)
> >  {
> > +	const struct sockaddr_unspec *sockaddr = sa;
> > +
> > +	if (sa_len < offsetofend(struct sockaddr, sa_family))
> > +		return -EINVAL;
> > +	if (sockaddr->sa_family != AF_PPPOX)
> > +		return -EAFNOSUPPORT;
> 
> I fear we can't introduce this check, as it could break existing
> user-space application currently passing random data into sa_family but
> still able to connect successfully.

Isn't sa_family kind of the critical determining factor on how the
network stack decides to handle sockaddr stuff? I'll drop it for now,
I guess, but that's surprising to me.

-Kees

-- 
Kees Cook

  reply	other threads:[~2025-10-23 16:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-20 21:26 [PATCH v3 0/9] net: Introduce struct sockaddr_unspec Kees Cook
2025-10-20 21:26 ` [PATCH v3 1/9] net: Add struct sockaddr_unspec for sockaddr of unknown length Kees Cook
2025-10-21  9:26   ` David Laight
2025-10-21 19:42     ` Kees Cook
2025-10-22  9:26       ` David Laight
2025-10-23 16:33         ` Kees Cook
2025-10-23 10:43   ` Paolo Abeni
2025-10-23 11:40     ` David Laight
2025-10-23 16:31     ` Kees Cook
2025-10-23 10:59   ` Paolo Abeni
2025-10-23 16:20     ` Kees Cook
2025-10-20 21:26 ` [PATCH v3 2/9] net/l2tp: Add missing sa_family validation in pppol2tp_sockaddr_get_info Kees Cook
2025-10-23 10:47   ` Paolo Abeni
2025-10-23 16:01     ` Kees Cook [this message]
2025-10-20 21:26 ` [PATCH v3 3/9] net: Convert proto_ops bind() callbacks to use sockaddr_unspec Kees Cook
2025-10-20 21:26 ` [PATCH v3 4/9] net: Convert proto_ops connect() " Kees Cook
2025-10-20 21:26 ` [PATCH v3 5/9] net: Remove struct sockaddr from net.h Kees Cook
2025-10-20 21:26 ` [PATCH v3 6/9] net: Convert proto callbacks from sockaddr to sockaddr_unspec Kees Cook
2025-10-20 21:26 ` [PATCH v3 7/9] bpf: Convert cgroup sockaddr filters to use sockaddr_unspec consistently Kees Cook
2025-10-20 21:26 ` [PATCH v3 8/9] bpf: Convert bpf_sock_addr_kern "uaddr" to sockaddr_unspec Kees Cook
2025-10-20 21:26 ` [PATCH v3 9/9] net: Convert struct sockaddr to fixed-size "sa_data[14]" Kees Cook

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=202510230900.5754A094@keescook \
    --to=kees@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gustavo@embeddedor.com \
    --cc=horms@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=willemb@google.com \
    /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.