From: Paolo Abeni <pabeni@redhat.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
Jordan Rife <jrife@google.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
davem@davemloft.net, Eric Dumazet <edumazet@google.com>,
kuba@kernel.org, netdev@vger.kernel.org, dborkman@kernel.org
Subject: Re: [PATCH net] net: prevent address overwrite in connect() and sendmsg()
Date: Thu, 14 Sep 2023 10:24:01 +0200 [thread overview]
Message-ID: <b6ed0ef1346363f11ddc7bb1c390a5f03f3a6b89.camel@redhat.com> (raw)
In-Reply-To: <CAF=yD-Lapvy4J748ge8k5v7gUoynDxJPpXKV8rOdgtAw7=_ErQ@mail.gmail.com>
On Wed, 2023-09-13 at 10:02 -0400, Willem de Bruijn wrote:
> On Tue, Sep 12, 2023 at 5:09 PM Jordan Rife <jrife@google.com> wrote:
> >
> > > If we take this path, it could be a single patch. The subsystem
> > > maintainers should be CC:ed so that they can (N)ACK it.
> > >
> > > But I do not mean to ask to split it up and test each one separately.
> > >
> > > The change from sock->ops->connect to kernel_connect is certainly
> > > trivial enough that compile testing should suffice.
> >
> > Ack. Thanks for clarifying.
> >
> > > The only question is whether we should pursue your original patch and
> > > accept that this will continue, or one that improves the situation,
> > > but touches more files and thus has a higher risk of merge conflicts.
> > >
> > > I'd like to give others some time to chime in. I've given my opinion,
> > > but it's only one.
> > >
> > > I'd like to give others some time to chime in. I've given my opinion,
> > > but it's only one.
> >
> > Sounds good. I'll wait to hear others' opinions on the best path forward.
>
> No other comments so far.
>
> My hunch is that a short list of these changes
>
> ```
> @@ -1328,7 +1328,7 @@ static int kernel_bindconnect(struct socket *s,
> struct sockaddr *laddr,
> if (rv < 0)
> return rv;
>
> - rv = s->ops->connect(s, raddr, size, flags);
> + rv = kernel_connect(s, raddr, size, flags);
> ```
>
> is no more invasive than your proposed patch, and gives a more robust outcome.
>
> Please take a stab.
I'm sorry for the late feedback. For the records, I agree the cleanest
fix described above should be attempted first.
Thanks,
Paolo
next prev parent reply other threads:[~2023-09-14 8:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-12 1:33 [PATCH net] net: prevent address overwrite in connect() and sendmsg() Jordan Rife
2023-09-12 13:33 ` Willem de Bruijn
2023-09-12 14:22 ` Daniel Borkmann
2023-09-12 18:31 ` Jordan Rife
2023-09-12 19:35 ` Willem de Bruijn
2023-09-12 20:07 ` Jordan Rife
2023-09-12 20:48 ` Willem de Bruijn
2023-09-12 21:08 ` Jordan Rife
2023-09-13 14:02 ` Willem de Bruijn
2023-09-13 18:04 ` Jordan Rife
2023-09-13 19:10 ` Willem de Bruijn
2023-09-14 8:24 ` Paolo Abeni [this message]
2023-09-14 18:41 ` Jordan Rife
2023-09-15 0:16 ` Willem de Bruijn
2023-09-15 0:21 ` Jordan Rife
2023-09-13 7:19 ` Dan Carpenter
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=b6ed0ef1346363f11ddc7bb1c390a5f03f3a6b89.camel@redhat.com \
--to=pabeni@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dborkman@kernel.org \
--cc=edumazet@google.com \
--cc=jrife@google.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=willemdebruijn.kernel@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).