[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5d681e0011c7b_6b462ad11252c5c084@john-XPS-13-9370.notmuch>
Date: Thu, 29 Aug 2019 11:48:32 -0700
From: John Fastabend <john.fastabend@...il.com>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>,
Hillf Danton <hdanton@...a.com>
Cc: john.fastabend@...il.com,
syzbot <syzbot+7a6ee4d0078eac6bf782@...kaller.appspotmail.com>,
aviadye@...lanox.com, borisp@...lanox.com, daniel@...earbox.net,
davejwatson@...com, davem@...emloft.net,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
syzkaller-bugs@...glegroups.com
Subject: Re: general protection fault in tls_sk_proto_close (2)
Jakub Kicinski wrote:
> On Thu, 29 Aug 2019 11:52:00 +0800, Hillf Danton wrote:
> > Alternatively work is done if sock is closed again. Anyway ctx is reset
> > under sock's callback lock in write mode.
> >
> > --- a/net/tls/tls_main.c
> > +++ b/net/tls/tls_main.c
> > @@ -295,6 +295,8 @@ static void tls_sk_proto_close(struct so
> > long timeo = sock_sndtimeo(sk, 0);
> > bool free_ctx;
> >
> > + if (!ctx)
> > + return;
> > if (ctx->tx_conf == TLS_SW)
> > tls_sw_cancel_work_tx(ctx);
>
> That's no bueno, the real socket's close will never get called.
Seems when we refactored BPF side we dropped the check for ULP on one
path so I'll add that back now. It would be nice and seems we are
getting closer now that tls side is a bit more dynamic if the ordering
didn't matter.
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 1330a7442e5b..30d11558740e 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -666,6 +666,8 @@ static int sock_hash_update_common(struct bpf_map *map, void *key,
WARN_ON_ONCE(!rcu_read_lock_held());
if (unlikely(flags > BPF_EXIST))
return -EINVAL;
+ if (unlikely(icsk->icsk_ulp_data))
+ return -EINVAL;
link = sk_psock_init_link();
if (!link)
Powered by blists - more mailing lists