Message ID | 20180116090037.44423-1-ilyal@mellanox.com |
---|---|
State | Superseded, archived |
Delegated to: | David Miller |
Headers | show |
Series | [net,1/1] net/tls: Only attach to sockets in ESTABLISHED state | expand |
I'm sorry, I've noticed that I have a typo in my comment. It should read: /*The TLS ulp is currently supported only for TCP sockets * in ESTABLISHED state. * Supporting sockets in LISTEN state will require us * to modify the accept implementation to clone rather then * share the ulp context. */ Should I resubmit the patch?
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c index e07ee3ae0023..a1a4e50acb53 100644 --- a/net/tls/tls_main.c +++ b/net/tls/tls_main.c @@ -454,6 +454,15 @@ static int tls_init(struct sock *sk) struct tls_context *ctx; int rc = 0; + /* The TLS ulp is correnctly supported only for TCP sockets + * in ESTABLISHED state. + * Supporting sockets in TCP_LISTEN state will require us + * to modify the accept implementation to clone rather then + * share the ulp context. + */ + if (sk->sk_state != TCP_ESTABLISHED) + return -ENOTSUPP; + /* allocate tls context */ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); if (!ctx) {
Calling accept on a TCP socket with a TLS ulp attached results in two sockets that share the same ulp context. The ulp context is freed while a socket is destroyed, so after one of the sockets is released, the second second will trigger a use after free when it tries to access the ulp context attached to it. We restrict the TLS ulp to sockets in ESTABLISHED state to prevent the scenario above. Fixes: 3c4d755 ('tls: kernel TLS support') Reported-by: syzbot+904e7cd6c5c741609228@syzkaller.appspotmail.com Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com> --- net/tls/tls_main.c | 9 +++++++++ 1 file changed, 9 insertions(+)