ceph: use kernel_connect()

Direct calls to ops->connect() can overwrite the address parameter when
used in conjunction with BPF SOCK_ADDR hooks. Recent changes to
kernel_connect() ensure that callers are insulated from such side
effects. This patch wraps the direct call to ops->connect() with
kernel_connect() to prevent unexpected changes to the address passed to
ceph_tcp_connect().

This change was originally part of a larger patch targeting the net tree
addressing all instances of unprotected calls to ops->connect()
throughout the kernel, but this change was split up into several patches
targeting various trees.

Link: https://lore.kernel.org/netdev/20230821100007.559638-1-jrife@google.com/
Link: https://lore.kernel.org/netdev/9944248dba1bce861375fcce9de663934d933ba9.camel@redhat.com/
Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect")
Cc: stable@vger.kernel.org
Signed-off-by: Jordan Rife <jrife@google.com>
---
 net/ceph/messenger.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

On Thu, Oct 5, 2023 at 1:39 AM Jordan Rife <jrife@google.com> wrote:
>
> Direct calls to ops->connect() can overwrite the address parameter when
> used in conjunction with BPF SOCK_ADDR hooks. Recent changes to
> kernel_connect() ensure that callers are insulated from such side
> effects. This patch wraps the direct call to ops->connect() with
> kernel_connect() to prevent unexpected changes to the address passed to
> ceph_tcp_connect().
>
> This change was originally part of a larger patch targeting the net tree
> addressing all instances of unprotected calls to ops->connect()
> throughout the kernel, but this change was split up into several patches
> targeting various trees.
>
> Link: https://lore.kernel.org/netdev/20230821100007.559638-1-jrife@google.com/
> Link: https://lore.kernel.org/netdev/9944248dba1bce861375fcce9de663934d933ba9.camel@redhat.com/
> Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jordan Rife <jrife@google.com>
> ---
>  net/ceph/messenger.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c
> index 10a41cd9c5235..3c8b78d9c4d1c 100644
> --- a/net/ceph/messenger.c
> +++ b/net/ceph/messenger.c
> @@ -459,8 +459,8 @@ int ceph_tcp_connect(struct ceph_connection *con)
>         set_sock_callbacks(sock, con);
>
>         con_sock_state_connecting(con);
> -       ret = sock->ops->connect(sock, (struct sockaddr *)&ss, sizeof(ss),
> -                                O_NONBLOCK);
> +       ret = kernel_connect(sock, (struct sockaddr *)&ss, sizeof(ss),
> +                            O_NONBLOCK);
>         if (ret == -EINPROGRESS) {
>                 dout("connect %s EINPROGRESS sk_state = %u\n",
>                      ceph_pr_addr(&con->peer_addr),
> --
> 2.42.0.582.g8ccd20d70d-goog
>

Hi Jordan,

I'm a bit confused.  This is marked as fixing commit d74bad4e74ee
("bpf: Hooks for sys_connect") and also for stable, but doesn't
(explicitly, at least) mention the prerequisite commit 0bdf399342c5
("net: Avoid address overwrite in kernel_connect") which isn't marked
for stable.  Was it forwarded to the stable team separately?

Thanks,

                Ilya

Ilya,

Sorry for the confusion. I forgot to mark 0bdf399342c5 ("net: Avoid
address overwrite in kernel_connect") for stable initially, so I
forwarded it separately to the stable team a while back. It has since
been backported to all stable branches 4.19+.

-Jordan

On Fri, Oct 6, 2023 at 3:53 AM Ilya Dryomov <idryomov@gmail.com> wrote:
>
> On Thu, Oct 5, 2023 at 1:39 AM Jordan Rife <jrife@google.com> wrote:
> >
> > Direct calls to ops->connect() can overwrite the address parameter when
> > used in conjunction with BPF SOCK_ADDR hooks. Recent changes to
> > kernel_connect() ensure that callers are insulated from such side
> > effects. This patch wraps the direct call to ops->connect() with
> > kernel_connect() to prevent unexpected changes to the address passed to
> > ceph_tcp_connect().
> >
> > This change was originally part of a larger patch targeting the net tree
> > addressing all instances of unprotected calls to ops->connect()
> > throughout the kernel, but this change was split up into several patches
> > targeting various trees.
> >
> > Link: https://lore.kernel.org/netdev/20230821100007.559638-1-jrife@google.com/
> > Link: https://lore.kernel.org/netdev/9944248dba1bce861375fcce9de663934d933ba9.camel@redhat.com/
> > Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Jordan Rife <jrife@google.com>
> > ---
> >  net/ceph/messenger.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c
> > index 10a41cd9c5235..3c8b78d9c4d1c 100644
> > --- a/net/ceph/messenger.c
> > +++ b/net/ceph/messenger.c
> > @@ -459,8 +459,8 @@ int ceph_tcp_connect(struct ceph_connection *con)
> >         set_sock_callbacks(sock, con);
> >
> >         con_sock_state_connecting(con);
> > -       ret = sock->ops->connect(sock, (struct sockaddr *)&ss, sizeof(ss),
> > -                                O_NONBLOCK);
> > +       ret = kernel_connect(sock, (struct sockaddr *)&ss, sizeof(ss),
> > +                            O_NONBLOCK);
> >         if (ret == -EINPROGRESS) {
> >                 dout("connect %s EINPROGRESS sk_state = %u\n",
> >                      ceph_pr_addr(&con->peer_addr),
> > --
> > 2.42.0.582.g8ccd20d70d-goog
> >
>
> Hi Jordan,
>
> I'm a bit confused.  This is marked as fixing commit d74bad4e74ee
> ("bpf: Hooks for sys_connect") and also for stable, but doesn't
> (explicitly, at least) mention the prerequisite commit 0bdf399342c5
> ("net: Avoid address overwrite in kernel_connect") which isn't marked
> for stable.  Was it forwarded to the stable team separately?
>
> Thanks,
>
>                 Ilya

On Fri, Oct 6, 2023 at 5:45 PM Jordan Rife <jrife@google.com> wrote:
>
> Ilya,
>
> Sorry for the confusion. I forgot to mark 0bdf399342c5 ("net: Avoid
> address overwrite in kernel_connect") for stable initially, so I
> forwarded it separately to the stable team a while back. It has since
> been backported to all stable branches 4.19+.

Thanks for the clarification, now applied.

                Ilya