From: Jordan Rife <jrife@google.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
davem@davemloft.net, Eric Dumazet <edumazet@google.com>,
kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org,
dborkman@kernel.org
Subject: Re: [PATCH net] net: prevent address overwrite in connect() and sendmsg()
Date: Tue, 12 Sep 2023 11:31:38 -0700 [thread overview]
Message-ID: <CADKFtnTOD2+7B5tH8YMHEnxubiG+Cs+t8EhTft+q51YwxjW9xw@mail.gmail.com> (raw)
In-Reply-To: <1ca3ca8a-6185-bc55-de74-53991ffc6f91@iogearbox.net>
> These should probably call kernel_connect instead.
> Similarly, this could call kernel_sendmsg, and the extra copy handled in that wrapper.
I was considering this approach initially, but one concern I had was
that there are other instances I see of modules calling ops->connect()
directly (bypassing kernel_connect()):
- net/netfilter/ipvs/ip_vs_sync.c: make_send_sock()
- drivers/block/drbd/drbd_receiver.c: drbd_try_connect()
- drivers/infiniband/hw/erdma/erdma_cm.c: kernel_bindconnect()
- drivers/infiniband/sw/siw/siw_cm.c: kernel_bindconnect()
- fs/ocfs2/cluster/tcp.c: o2net_start_connect()
- net/rds/tcp_connect.c: rds_tcp_conn_path_connect()
and ops->sendmsg():
- net/smc/af_smc.c: smc_sendmsg()
- drivers/vhost/net.c: vhost_tx_batch(), handle_tx_copy(), handle_tx_zerocopy()
- drivers/target/iscsi/iscsi_target_util.c: iscsit_fe_sendpage_sg()
which (at least in theory) leaves them open to the same problem I'm
seeing with NFS/SMB right now. I worry that even if all these
instances were swapped out with kernel_sendmsg() and kernel_connect(),
it would turn into a game of whac-a-mole in the future as new changes
or new modules may reintroduce direct calls to sock->ops->connect() or
sock->ops->sendmsg().
-Jordan
On Tue, Sep 12, 2023 at 7:22 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 9/12/23 3:33 PM, Willem de Bruijn wrote:
> > Jordan Rife wrote:
> >> commit 0bdf399342c5 ("net: Avoid address overwrite in kernel_connect")
> >> ensured that kernel_connect() will not overwrite the address parameter
> >> in cases where BPF connect hooks perform an address rewrite. However,
> >> there remain other cases where BPF hooks can overwrite an address held
> >> by a kernel client.
> >>
> >> ==Scenarios Tested==
> >>
> >> * Code in the SMB and Ceph modules calls sock->ops->connect() directly,
> >> allowing the address overwrite to occur. In the case of SMB, this can
> >> lead to broken mounts.
> >
> > These should probably call kernel_connect instead.
> >
> >> * NFS v3 mounts with proto=udp call sock_sendmsg() for each RPC call,
> >> passing a pointer to the mount address in msg->msg_name which is
> >> later overwritten by a BPF sendmsg hook. This can lead to broken NFS
> >> mounts.
> >
> > Similarly, this could call kernel_sendmsg, and the extra copy handled
> > in that wrapper. The arguments are not exacty the same, so not 100%
> > this is feasible.
> >
> > But it's preferable if in-kernel callers use the kernel_.. API rather
> > than bypass it. Exactly for issues like the one you report.
>
> Fully agree, if it's feasible it would be better to convert them over to
> in-kernel API.
>
> >> In order to more comprehensively fix this class of problems, this patch
> >> pushes the address copy deeper into the stack and introduces an address
> >> copy to both udp_sendmsg() and udpv6_sendmsg() to insulate all callers
> >> from address rewrites.
> >>
> >> Signed-off-by: Jordan Rife <jrife@google.com>
next prev parent reply other threads:[~2023-09-12 18:31 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 [this message]
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
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=CADKFtnTOD2+7B5tH8YMHEnxubiG+Cs+t8EhTft+q51YwxjW9xw@mail.gmail.com \
--to=jrife@google.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dborkman@kernel.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--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).