From patchwork Wed Jan 8 21:14:07 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1219965 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Original-To: incoming-bpf@patchwork.ozlabs.org Delivered-To: patchwork-incoming-bpf@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=bpf-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="BbAFJbMe"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47tMSV62SKz9sP6 for ; Thu, 9 Jan 2020 08:14:18 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727385AbgAHVOS (ORCPT ); Wed, 8 Jan 2020 16:14:18 -0500 Received: from mail-il1-f196.google.com ([209.85.166.196]:34851 "EHLO mail-il1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726836AbgAHVOS (ORCPT ); Wed, 8 Jan 2020 16:14:18 -0500 Received: by mail-il1-f196.google.com with SMTP id g12so3913657ild.2; Wed, 08 Jan 2020 13:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=nMRe4g2ztcBCA+0caE9RNqwQ4Lc8GtMpZaK2DzSrUsM=; b=BbAFJbMe9TZRthB6a4MS8rtfV1zJ7RrRj8Rh56+c8yRuvntm+9zyVC6kxcHZuwtk+y ryC7FE6d9lE/KmfeJqD42JHlHVTv+po3gESX3VGJXoWa1b1j+Shwi51d9EHtczwatZnl wdsViO/z465L7nPG10c/qQXpvSZSxjHzLP8uxti+mBzOuHPoAm6FbdMFWkz7xD/cO2oQ kgtWoT+YchGPyjPWHDprLPflQ+hoiK+GTw1ChblILVssvg9XRrMsRcsxpEfpKQVe8gTR FP/XVK+bgLxEL0w1bjer9FfW0jN3KK1LTwmu8hlyHL/pfDOOlPl02Om9z/UGysegCmMy Z0Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:date:message-id:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=nMRe4g2ztcBCA+0caE9RNqwQ4Lc8GtMpZaK2DzSrUsM=; b=T4QO/u08FVgH1065UicaL1u8AJ4HOvOZC0wzLfY6JJHhf1mtkep3Hne0lVYfnjwdno IrlgztJwOaC8RHPgPQHMaEVlDLuddaWU8+jmq3WWiwBhSJRETjRMAOb6uBdWdJU7Qztq gEiDTLyFf377VLS5170g7BmWrcyEfeCkvi/n8aAkEKgcOihyXdj3j77rM2XXTXuOUZtU 1w8FW8NzsdlG4gLFiWbKsaSG9tbVEnH5Yla6SK11r2UFQ3/Q7/Fcgoov0m5wSEaAGfPk zEh3o7JwfdWgDbjzUPEcGZkzWTbKC+Mp38oko+6G7SGMlYAuOeH0BpC3XVjxdAwo+a+T qRRw== X-Gm-Message-State: APjAAAVGe+FXXQMv8XpC/pj3TFszxNzJoM6Oj98YMEh8ihGFaeaM1nZ5 jc36DnWwldCkSDpjKzbNzgZpn/Ak X-Google-Smtp-Source: APXvYqw41PT2AvWhZaH6mUG/T1dIDe6mvXYfmBktVueNgJFlJ80hkWzsw58KLQ1pAvGc7YcLN7c8rg== X-Received: by 2002:a92:4448:: with SMTP id a8mr5802073ilm.256.1578518057406; Wed, 08 Jan 2020 13:14:17 -0800 (PST) Received: from [127.0.1.1] ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id w16sm1319972ilq.5.2020.01.08.13.14.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2020 13:14:17 -0800 (PST) Subject: [bpf PATCH 1/9] bpf: sockmap/tls, during free we may call tcp_bpf_unhash() in loop From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, john.fastabend@gmail.com, ast@kernel.org, daniel@iogearbox.net Date: Wed, 08 Jan 2020 21:14:07 +0000 Message-ID: <157851804766.1732.2480524840189309989.stgit@ubuntu3-kvm2> In-Reply-To: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> References: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org When a sockmap is free'd and a socket in the map is enabled with tls we tear down the bpf context on the socket, the psock struct and state, and then call tcp_update_ulp(). The tcp_update_ulp() call is to inform the tls stack it needs to update its saved sock ops so that when the tls socket is later destroyed it doesn't try to call the now destroyed psock hooks. This is about keeping stacked ULPs in good shape so they always have the right set of stacked ops. However, recently unhash() hook was removed from TLS side. But, the sockmap/bpf side is not doing any extra work to update the unhash op when is torn down instead expecting TLS side to manage it. So both TLS and sockmap believe the other side is managing the op and instead no one updates the hook so it continues to point at tcp_bpf_unhash(). When unhash hook is called we call tcp_bpf_unhash() which detects the psock has already been destroyed and calls sk->sk_prot_unhash() which calls tcp_bpf_unhash() yet again and so on looping and hanging the core. To fix have sockmap tear down logic fixup the stale pointer. Fixes: 5d92e631b8be ("net/tls: partially revert fix transition through disconnect with close") Reported-by: syzbot+83979935eb6304f8cd46@syzkaller.appspotmail.com Signed-off-by: John Fastabend Acked-by: Song Liu --- include/linux/skmsg.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/skmsg.h b/include/linux/skmsg.h index ef7031f8a304..b6afe01f8592 100644 --- a/include/linux/skmsg.h +++ b/include/linux/skmsg.h @@ -358,6 +358,7 @@ static inline void sk_psock_update_proto(struct sock *sk, static inline void sk_psock_restore_proto(struct sock *sk, struct sk_psock *psock) { + sk->sk_prot->unhash = psock->saved_unhash; sk->sk_write_space = psock->saved_write_space; if (psock->sk_proto) { From patchwork Wed Jan 8 21:14:23 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1219967 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Original-To: incoming-bpf@patchwork.ozlabs.org Delivered-To: patchwork-incoming-bpf@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=bpf-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="GU2OoX1z"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47tMSr6wKgz9sP6 for ; Thu, 9 Jan 2020 08:14:36 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727416AbgAHVOg (ORCPT ); Wed, 8 Jan 2020 16:14:36 -0500 Received: from mail-io1-f44.google.com ([209.85.166.44]:41332 "EHLO mail-io1-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726836AbgAHVOg (ORCPT ); Wed, 8 Jan 2020 16:14:36 -0500 Received: by mail-io1-f44.google.com with SMTP id c16so4784097ioo.8; Wed, 08 Jan 2020 13:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=XO2r01lOBNDBiQXSDfixnJ606GokxgdaQBqmQyr/bDs=; b=GU2OoX1zol0xRDr+Sntblx5PC4N0fXQk0lICdSZo2Qs6EGUqZfE1bcP6WfkEglPxk0 VFlz4NAi8CbEiw2x1gpjeHvtuDvBfxJzXGxlkPshGx6H5d4UswrN/V+E2JMNemqU+wZc 2RRwNHJxfE2h1vts7OeouIbswjA1Dqi/KJ6yhTrSdvYTn9DIy4ej5KOLIGRjmokl9QTd qFtmOFsiaEe//fKBgMO7QuiRSKkrDq/1fLBBGQLHD274AS972XIW6aO/BWUTsHFuXyBG oWUSa7VYenusLF9mLkYb9T8/rd9Y3OfdGzGinVuvB4qiGsGlvY/gUIhL4mS6QAefh8qc gI7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:date:message-id:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=XO2r01lOBNDBiQXSDfixnJ606GokxgdaQBqmQyr/bDs=; b=e1pZjSxf599Z3mLBsl/s93NPQ0hlK7POWQDcP5dy+JZlFMYzPQiKM+5KsnVZfzfL6Q O7OivLPKOjBWgdV9xdqtvtleZ/fEHGTcBjFDxApXsnARHJhX0AkBZ1GRllbGxLLaTE+x NZb8iTlXyNFAvlAjmC1l4eohsJY2AtM1mavRhZNbTnvu1rDSf49rpIIj3CjOWsrjMMVC 2zeddw1rLad8PSJJbZZfH2BrHHWH81yLhxClJjLQfvJtLU7v43AL1kXGCRxNGavETtw9 5FX+pylmOJEVfLP5WlI7w804gW8EP5d41N6ThliPtzkRMunDZMqdb9c4DvyPKXEJ9o/p aNKg== X-Gm-Message-State: APjAAAXGHlrduZr5nkty/V3ffwTB+F5zHHjDaWbL0AEK8P81x/vAHf22 Qcm5rJ4HR7UyKiYRLULh2MD7Jvzo X-Google-Smtp-Source: APXvYqxWsuNbq+D+y5zzDCTdrZ5TpAb6lZSV2uJ9ICG89wthJmqK7P1335uf7Nmw5baqZgHZ490cfQ== X-Received: by 2002:a6b:ed15:: with SMTP id n21mr4840178iog.128.1578518074544; Wed, 08 Jan 2020 13:14:34 -0800 (PST) Received: from [127.0.1.1] ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id h6sm911558iom.43.2020.01.08.13.14.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2020 13:14:34 -0800 (PST) Subject: [bpf PATCH 2/9] bpf: sockmap, ensure sock lock held during tear down From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, john.fastabend@gmail.com, ast@kernel.org, daniel@iogearbox.net Date: Wed, 08 Jan 2020 21:14:23 +0000 Message-ID: <157851806382.1732.8320375873100251133.stgit@ubuntu3-kvm2> In-Reply-To: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> References: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org The sock_map_free() and sock_hash_free() paths used to delete sockmap and sockhash maps walk the maps and destroy psock and bpf state associated with the socks in the map. When done the socks no longer have BPF programs attached and will function normally. This can happen while the socks in the map are still "live" meaning data may be sent/received during the walk. Currently, though we don't take the sock_lock when the psock and bpf state is removed through this path. Specifically, this means we can be writing into the ops structure pointers such as sendmsg, sendpage, recvmsg, etc. while they are also being called from the networking side. This is not safe, we never used proper READ_ONCE/WRITE_ONCE semantics here if we believed it was safe. Further its not clear to me its even a good idea to try and do this on "live" sockets while networking side might also be using the socket. Instead of trying to reason about using the socks from both sides lets realize that every use case I'm aware of rarely deletes maps, in fact kubernetes/Cilium case builds map at init and never tears it down except on errors. So lets do the simple fix and grab sock lock. This patch wraps sock deletes from maps in sock lock and adds some annotations so we catch any other cases easier. Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: John Fastabend Acked-by: Song Liu --- net/core/skmsg.c | 2 ++ net/core/sock_map.c | 7 ++++++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/net/core/skmsg.c b/net/core/skmsg.c index ded2d5227678..3866d7e20c07 100644 --- a/net/core/skmsg.c +++ b/net/core/skmsg.c @@ -594,6 +594,8 @@ EXPORT_SYMBOL_GPL(sk_psock_destroy); void sk_psock_drop(struct sock *sk, struct sk_psock *psock) { + sock_owned_by_me(sk); + sk_psock_cork_free(psock); sk_psock_zap_ingress(psock); diff --git a/net/core/sock_map.c b/net/core/sock_map.c index eb114ee419b6..8998e356f423 100644 --- a/net/core/sock_map.c +++ b/net/core/sock_map.c @@ -241,8 +241,11 @@ static void sock_map_free(struct bpf_map *map) struct sock *sk; sk = xchg(psk, NULL); - if (sk) + if (sk) { + lock_sock(sk); sock_map_unref(sk, psk); + release_sock(sk); + } } raw_spin_unlock_bh(&stab->lock); rcu_read_unlock(); @@ -862,7 +865,9 @@ static void sock_hash_free(struct bpf_map *map) raw_spin_lock_bh(&bucket->lock); hlist_for_each_entry_safe(elem, node, &bucket->head, node) { hlist_del_rcu(&elem->node); + lock_sock(elem->sk); sock_map_unref(elem->sk, elem); + release_sock(elem->sk); } raw_spin_unlock_bh(&bucket->lock); } From patchwork Wed Jan 8 21:14:41 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1219969 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Original-To: incoming-bpf@patchwork.ozlabs.org Delivered-To: patchwork-incoming-bpf@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=bpf-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="B3EzAvZc"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47tMT9518vz9sP6 for ; Thu, 9 Jan 2020 08:14:53 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727217AbgAHVOx (ORCPT ); Wed, 8 Jan 2020 16:14:53 -0500 Received: from mail-io1-f67.google.com ([209.85.166.67]:41366 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726836AbgAHVOx (ORCPT ); Wed, 8 Jan 2020 16:14:53 -0500 Received: by mail-io1-f67.google.com with SMTP id c16so4784901ioo.8; Wed, 08 Jan 2020 13:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=TRxE7RDfuYSml0D0IusqQY61z0CPE8spL8tPdO24lwg=; b=B3EzAvZcJpv0qz7V1l+z8gkxismQaCPByV7jXiiKKu4SLbGRR/FvUWEhpOH4tV1Uu2 4MgAPrU4aatis1mtuc9B7e228z1xWWWSyuYGV9r3wUhpBKcBrQbKOLJ0ivHejSvst9rs fobfUs4KzByJlZFmwhgynDVNOyp9Jn8WgAOq8OGFzSYqp4EvDHBI0m/q1iJknNXHxP7v jN/RaQnbFVxaRGOCUJACu4klsZhWsSblyQxFxodw7iq5MPkL+BEDdOKMnhjpr+bEe4nX 932hlduyugBeeZKaUrVeVXmOh3gmqZKF55e2xAoZpOcQt9thE69mISYVaWaHtcg83OTD 3Qiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:date:message-id:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=TRxE7RDfuYSml0D0IusqQY61z0CPE8spL8tPdO24lwg=; b=Un/5IR4U95xlS4gxEA3pPIKGSpTQpQAR2gYn22zqihCr6c+3Udr0c5qAzf8+FPnYzW YGCV4wcMW5XWWT8L0QchgN2/pQJwm3JEQH2x56+T3F/4DQIVT+sD61XJfkicJLNniX+v 6ut01IB7Cq+3G9FRqe1FfI3wOsIxVcQFBrXBL93YaLQ3kX7Va1mrPXjEXyNTs4OCYtT7 T2HLJZfKwyt5OmqK7KrE8w8yZrR0CNy9llruklJbcgFIuJjNwGnJ9HlMi5+yAWvM4K8B KyKnrf7WUO8eEF3/yY1YN9S5Im9VLIZdvJFq/YR5W1tvkJN5dsRih45SvsEeZaTDo3VK gNYQ== X-Gm-Message-State: APjAAAUKVwQnJb3FvExPws5Kt7PWG961QHM26pk6x2Qy0cFwZiXqixV8 VKJUKV9dgbUJFyqzYEQ/na/JIq/I X-Google-Smtp-Source: APXvYqwd3+k3g9LbxdN9D+vjHiO5nb/Jis9a6lJk5DwFwAxbhtKgTkNhVHSHQFKkMSFgJQwdTR/GzQ== X-Received: by 2002:a02:b602:: with SMTP id h2mr6090455jam.20.1578518092292; Wed, 08 Jan 2020 13:14:52 -0800 (PST) Received: from [127.0.1.1] ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id w16sm1320379ilq.5.2020.01.08.13.14.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2020 13:14:51 -0800 (PST) Subject: [bpf PATCH 3/9] bpf: sockmap/tls, push write_space updates through ulp updates From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, john.fastabend@gmail.com, ast@kernel.org, daniel@iogearbox.net Date: Wed, 08 Jan 2020 21:14:41 +0000 Message-ID: <157851808101.1732.11616068811837364406.stgit@ubuntu3-kvm2> In-Reply-To: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> References: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org When sockmap sock with TLS enabled is removed we cleanup bpf/psock state and call tcp_update_ulp() to push updates to TLS ULP on top. However, we don't push the write_space callback up and instead simply overwrite the op with the psock stored previous op. This may or may not be correct so to ensure we don't overwrite the TLS write space hook pass this field to the ULP and have it fixup the ctx. This completes a previous fix that pushed the ops through to the ULP but at the time missed doing this for write_space, presumably because write_space TLS hook was added around the same time. Fixes: 95fa145479fbc ("bpf: sockmap/tls, close can race with map free") Signed-off-by: John Fastabend --- include/linux/skmsg.h | 12 ++++++++---- include/net/tcp.h | 6 ++++-- net/ipv4/tcp_ulp.c | 6 ++++-- net/tls/tls_main.c | 10 +++++++--- 4 files changed, 23 insertions(+), 11 deletions(-) diff --git a/include/linux/skmsg.h b/include/linux/skmsg.h index b6afe01f8592..14d61bba0b79 100644 --- a/include/linux/skmsg.h +++ b/include/linux/skmsg.h @@ -359,17 +359,21 @@ static inline void sk_psock_restore_proto(struct sock *sk, struct sk_psock *psock) { sk->sk_prot->unhash = psock->saved_unhash; - sk->sk_write_space = psock->saved_write_space; if (psock->sk_proto) { struct inet_connection_sock *icsk = inet_csk(sk); bool has_ulp = !!icsk->icsk_ulp_data; - if (has_ulp) - tcp_update_ulp(sk, psock->sk_proto); - else + if (has_ulp) { + tcp_update_ulp(sk, psock->sk_proto, + psock->saved_write_space); + } else { sk->sk_prot = psock->sk_proto; + sk->sk_write_space = psock->saved_write_space; + } psock->sk_proto = NULL; + } else { + sk->sk_write_space = psock->saved_write_space; } } diff --git a/include/net/tcp.h b/include/net/tcp.h index e460ea7f767b..e6f48384dc71 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -2147,7 +2147,8 @@ struct tcp_ulp_ops { /* initialize ulp */ int (*init)(struct sock *sk); /* update ulp */ - void (*update)(struct sock *sk, struct proto *p); + void (*update)(struct sock *sk, struct proto *p, + void (*write_space)(struct sock *sk)); /* cleanup ulp */ void (*release)(struct sock *sk); /* diagnostic */ @@ -2162,7 +2163,8 @@ void tcp_unregister_ulp(struct tcp_ulp_ops *type); int tcp_set_ulp(struct sock *sk, const char *name); void tcp_get_available_ulp(char *buf, size_t len); void tcp_cleanup_ulp(struct sock *sk); -void tcp_update_ulp(struct sock *sk, struct proto *p); +void tcp_update_ulp(struct sock *sk, struct proto *p, + void (*write_space)(struct sock *sk)); #define MODULE_ALIAS_TCP_ULP(name) \ __MODULE_INFO(alias, alias_userspace, name); \ diff --git a/net/ipv4/tcp_ulp.c b/net/ipv4/tcp_ulp.c index 12ab5db2b71c..38d3ad141161 100644 --- a/net/ipv4/tcp_ulp.c +++ b/net/ipv4/tcp_ulp.c @@ -99,17 +99,19 @@ void tcp_get_available_ulp(char *buf, size_t maxlen) rcu_read_unlock(); } -void tcp_update_ulp(struct sock *sk, struct proto *proto) +void tcp_update_ulp(struct sock *sk, struct proto *proto, + void (*write_space)(struct sock *sk)) { struct inet_connection_sock *icsk = inet_csk(sk); if (!icsk->icsk_ulp_ops) { + sk->sk_write_space = write_space; sk->sk_prot = proto; return; } if (icsk->icsk_ulp_ops->update) - icsk->icsk_ulp_ops->update(sk, proto); + icsk->icsk_ulp_ops->update(sk, proto, write_space); } void tcp_cleanup_ulp(struct sock *sk) diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c index dac24c7aa7d4..94774c0e5ff3 100644 --- a/net/tls/tls_main.c +++ b/net/tls/tls_main.c @@ -732,15 +732,19 @@ static int tls_init(struct sock *sk) return rc; } -static void tls_update(struct sock *sk, struct proto *p) +static void tls_update(struct sock *sk, struct proto *p, + void (*write_space)(struct sock *sk)) { struct tls_context *ctx; ctx = tls_get_ctx(sk); - if (likely(ctx)) + if (likely(ctx)) { + ctx->sk_write_space = write_space; ctx->sk_proto = p; - else + } else { sk->sk_prot = p; + sk->sk_write_space = write_space; + } } static int tls_get_info(const struct sock *sk, struct sk_buff *skb) From patchwork Wed Jan 8 21:14:58 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1219971 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Original-To: incoming-bpf@patchwork.ozlabs.org Delivered-To: patchwork-incoming-bpf@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=bpf-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Yy48ZqE+"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47tMTW3BmCz9sP6 for ; Thu, 9 Jan 2020 08:15:11 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727158AbgAHVPL (ORCPT ); Wed, 8 Jan 2020 16:15:11 -0500 Received: from mail-il1-f196.google.com ([209.85.166.196]:39191 "EHLO mail-il1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726836AbgAHVPK (ORCPT ); Wed, 8 Jan 2020 16:15:10 -0500 Received: by mail-il1-f196.google.com with SMTP id x5so3886586ila.6; Wed, 08 Jan 2020 13:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=R01+CMo0RVfAWZgIcUOi47biaid6EcOVDaXjw4Yf1DM=; b=Yy48ZqE+361CSnDnXBR2wVWy0DeyOm6JU6USAVm8V+a8o9xUuQtPQbTkh1nsCkVx8L j+m3QnHfEQ9P6MLFi3PRTrGyCLi0CcoIrkHDVNRCfuEfSDFSGYzOa06FzrWxMJr2C60A ps8gnAzcWD3sKR0ZEbFztrxjZBeYoRpbc/COqSVOKMxMu1WhFCjQ8BupFjEwf993oM8Q 5gX9W6SpMDefxKANSBsBOHAUtnuMR6Od5a0oS/w086FtgEYYg6hjIZGQLKsBMu/Ik3u0 Jw9oUF2XgsLyeWP0YsYh/4IA5dyflT6zq0BV3D1X/ThVqaV5URRmQkJb9i5wqLfhV8gI tb5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:date:message-id:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=R01+CMo0RVfAWZgIcUOi47biaid6EcOVDaXjw4Yf1DM=; b=UeVm/hrbKSnKPrmvMf6o3IQOtYya17LMs4jG1RVUsyPMaNTNPxeZU9BGRyPuhzN+X4 nZE0jEKK5RGvw29480bM4olR5I/B2M9wiuYokbpfNXOUTlosQ1T6r2zINs0VrSiwUGE4 Og5epuDMKezYUToGilkRVaBg8AQQMU6BB/O2imHnlfsais/6Ca3/H+cWti7mlwsC9ojT 53LLS/GTg2sjLMBnQiz9PgOoSNAk3tGCHRrQeuyHYTVTUV++3NvXZ4Fp3uGowcnbVKcl Th3jfv92q99FCzLf3qkE9wrYk1fXsjtrNiMCw8Qgy3WdSzY9NWLriEix79j+B3r7m1BH IRog== X-Gm-Message-State: APjAAAVSi41m00xVoEP+4tsektQRxlUw0DDuSKnZ2cbnGujeDlcWvxcw Vh1PSCt5Ut3zcIO3/aVJd+3c9jG2 X-Google-Smtp-Source: APXvYqy7NoWL+AdwBrnVel3a7s6z8DEgl9xhq2+mYh7yh6TSczvEN1TbuQT/0xeXoH9rCu0oPm8N1g== X-Received: by 2002:a05:6e02:d05:: with SMTP id g5mr5536389ilj.272.1578518110164; Wed, 08 Jan 2020 13:15:10 -0800 (PST) Received: from [127.0.1.1] ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id a7sm908014iod.61.2020.01.08.13.15.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2020 13:15:09 -0800 (PST) Subject: [bpf PATCH 4/9] bpf: sockmap, skmsg helper overestimates push, pull, and pop bounds From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, john.fastabend@gmail.com, ast@kernel.org, daniel@iogearbox.net Date: Wed, 08 Jan 2020 21:14:58 +0000 Message-ID: <157851809847.1732.8255673984543824278.stgit@ubuntu3-kvm2> In-Reply-To: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> References: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org In the push, pull, and pop helpers operating on skmsg objects to make data writable or insert/remove data we use this bounds check to ensure specified data is valid, /* Bounds checks: start and pop must be inside message */ if (start >= offset + l || last >= msg->sg.size) return -EINVAL; The problem here is offset has already included the length of the current element the 'l' above. So start could be past the end of the scatterlist element in the case where start also points into an offset on the last skmsg element. To fix do the accounting slightly different by adding the length of the previous entry to offset at the start of the iteration. And ensure its initialized to zero so that the first iteration does nothing. Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface") Fixes: 6fff607e2f14b ("bpf: sk_msg program helper bpf_msg_push_data") Fixes: 7246d8ed4dcce ("bpf: helper to pop data from messages") Signed-off-by: John Fastabend Acked-by: Song Liu --- net/core/filter.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/net/core/filter.c b/net/core/filter.c index 28b3c258188c..34d8eb0823f4 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -2231,10 +2231,10 @@ BPF_CALL_4(bpf_msg_pull_data, struct sk_msg *, msg, u32, start, /* First find the starting scatterlist element */ i = msg->sg.start; do { + offset += len; len = sk_msg_elem(msg, i)->length; if (start < offset + len) break; - offset += len; sk_msg_iter_var_next(i); } while (i != msg->sg.end); @@ -2346,7 +2346,7 @@ BPF_CALL_4(bpf_msg_push_data, struct sk_msg *, msg, u32, start, u32, len, u64, flags) { struct scatterlist sge, nsge, nnsge, rsge = {0}, *psge; - u32 new, i = 0, l, space, copy = 0, offset = 0; + u32 new, i = 0, l = 0, space, copy = 0, offset = 0; u8 *raw, *to, *from; struct page *page; @@ -2356,11 +2356,11 @@ BPF_CALL_4(bpf_msg_push_data, struct sk_msg *, msg, u32, start, /* First find the starting scatterlist element */ i = msg->sg.start; do { + offset += l; l = sk_msg_elem(msg, i)->length; if (start < offset + l) break; - offset += l; sk_msg_iter_var_next(i); } while (i != msg->sg.end); @@ -2506,7 +2506,7 @@ static void sk_msg_shift_right(struct sk_msg *msg, int i) BPF_CALL_4(bpf_msg_pop_data, struct sk_msg *, msg, u32, start, u32, len, u64, flags) { - u32 i = 0, l, space, offset = 0; + u32 i = 0, l = 0, space, offset = 0; u64 last = start + len; int pop; @@ -2516,11 +2516,11 @@ BPF_CALL_4(bpf_msg_pop_data, struct sk_msg *, msg, u32, start, /* First find the starting scatterlist element */ i = msg->sg.start; do { + offset += l; l = sk_msg_elem(msg, i)->length; if (start < offset + l) break; - offset += l; sk_msg_iter_var_next(i); } while (i != msg->sg.end); From patchwork Wed Jan 8 21:15:16 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1219973 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="LHAPrUnk"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47tMTt1FXCz9sPn for ; Thu, 9 Jan 2020 08:15:30 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727469AbgAHVP3 (ORCPT ); Wed, 8 Jan 2020 16:15:29 -0500 Received: from mail-il1-f175.google.com ([209.85.166.175]:36999 "EHLO mail-il1-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726836AbgAHVP3 (ORCPT ); Wed, 8 Jan 2020 16:15:29 -0500 Received: by mail-il1-f175.google.com with SMTP id t8so3906269iln.4; Wed, 08 Jan 2020 13:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=fEakvqeYkfbBRut9ZFCKn5+KChuB1ZUOtinLv56jXgE=; b=LHAPrUnkslrPTMrvfOpckVTzEnaENBRbXh3/kSs6LMYHkEIxW/eO2t2abowS/bHQ+0 ODJGM830KdVPViX26vYP6fmRpab/WuF6Y30QeWWO7ivEXIA7ew/V24Axxr2NPi6A/to3 LU59Zrjpjm5gSirbhgrCDZeWhdtXDAtBtHqUBaYA20i1537qbtNek4SQQ46ZFHeROF6n c10Ep8I4u2aaDsMeVLqKHf1Qk1jyf5gAgvEV/zHcxSfk2R218v4dLCP6oOirIC1l2jn5 gZKXbjTLR9LyLGf6T+9gnX9IMprqnHClKcSOUWcHQfFDrdxPrE61tEPDGhWZHm67Onh7 Pzxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:date:message-id:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=fEakvqeYkfbBRut9ZFCKn5+KChuB1ZUOtinLv56jXgE=; b=GA7nVxAiw33pL7Su/IPsjDbWsVPX8x/dNBTpkG4xtkBQrJp5CLb+LGt1YBRkrBo2UD q5JYDq6D5bUy19LHI4n9yXBFqo+wgU8M7oY4lIbE73PUpviK9IfY3ODw2SorBX0SGg6y fez5GdUvh3TeoKB1tYYkT5zHo5A9YIwkBxf/ttFzA6rRgL/pj5GopMnLYl1Kpf0Ah6kx IGFVen+tkMMxcmDlWA26bVWk8i1jJzS1IbJnDikWcFKAqs/sp8bluy3UMq1wDsuzWgdK YTAW7QDwUikMdnGyq0fHbpeYLIF41b56VGzMx8/9+30Nd3RsHaWNUEBytABDBy5fE+ah ABDQ== X-Gm-Message-State: APjAAAUMrvxwHRNX6FWxQYaYQ+8lx7O6XXcIYA0vEdh1tWzgiI3EQ+vm 4QyULUHF96RcdBR4sS6CL8UiwrAQ X-Google-Smtp-Source: APXvYqzBdHe+4liKu5ft7mY/wrFcOXAPVyCB9Tt0sKPsizSfd4NUJU8NEh0iq1ijAcRFrARF5BRQWA== X-Received: by 2002:a92:cd0c:: with SMTP id z12mr5920744iln.45.1578518128556; Wed, 08 Jan 2020 13:15:28 -0800 (PST) Received: from [127.0.1.1] ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id j88sm1301928ilf.83.2020.01.08.13.15.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2020 13:15:28 -0800 (PST) Subject: [bpf PATCH 5/9] bpf: sockmap/tls, msg_push_data may leave end mark in place From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, john.fastabend@gmail.com, ast@kernel.org, daniel@iogearbox.net Date: Wed, 08 Jan 2020 21:15:16 +0000 Message-ID: <157851811621.1732.15187089912852035409.stgit@ubuntu3-kvm2> In-Reply-To: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> References: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Leaving an incorrect end mark in place when passing to crypto layer will cause crypto layer to stop processing data before all data is encrypted. To fix clear the end mark on push data instead of expecting users of the helper to clear the mark value after the fact. This happens when we push data into the middle of a skmsg and have room for it so we don't do a set of copies that already clear the end flag. Fixes: 6fff607e2f14b ("bpf: sk_msg program helper bpf_msg_push_data") Signed-off-by: John Fastabend Acked-by: Song Liu --- net/core/filter.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/core/filter.c b/net/core/filter.c index 34d8eb0823f4..21d0190b5413 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -2415,6 +2415,7 @@ BPF_CALL_4(bpf_msg_push_data, struct sk_msg *, msg, u32, start, sk_msg_iter_var_next(i); sg_unmark_end(psge); + sg_unmark_end(&rsge); sk_msg_iter_next(msg, end); } From patchwork Wed Jan 8 21:15:34 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1219975 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="WT3mQuxP"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47tMVD38FMz9sPn for ; Thu, 9 Jan 2020 08:15:48 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727481AbgAHVPr (ORCPT ); Wed, 8 Jan 2020 16:15:47 -0500 Received: from mail-io1-f67.google.com ([209.85.166.67]:46839 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726992AbgAHVPr (ORCPT ); Wed, 8 Jan 2020 16:15:47 -0500 Received: by mail-io1-f67.google.com with SMTP id t26so4752809ioi.13; Wed, 08 Jan 2020 13:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=lOwmNDsUqawmAxi5AY455Ys+4HDKfXRmzw/uVvdXh6M=; b=WT3mQuxPkAm1oI83RjHOyJetl2OaXhkGLv31qd2n0UqlfvLevvpW6GDMX4/e9tEh6Y yA8e7cH+2JNPOjD9eyyHzpdsnUOyj/zIvJzCbOu2ZVddhuzc+LHRfEDTei4ockM8FT69 nyOEoZdcXTE0dMbh5x7GEU6Q+NMUQSbbsJnOrmsTI1itu4A34102kCK6jH+B44s0VpMu wAC7Mc7QgKn/YBADOTMsuANc8QH0rEx0tWdPLgtAWqaxklnO1OqpQXPke5pzsBNAtsnn j+lrT3RblOijjon+LaIOkZ9f6h+p576ckPRNQfrHX12iF/v84hblPdiD4kU5Fgzs28Vz vBLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:date:message-id:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=lOwmNDsUqawmAxi5AY455Ys+4HDKfXRmzw/uVvdXh6M=; b=MtCmJ1jFxSfzaeutbmtBydpeBgCkNW1u7PZXMXhLsc3Z4UL72yjSb+x7vA3WfZm8t1 nPpKiwFVNkReoZOQD7Ohox4EP1fZy+FZSoVFiY3vxxxJptSVcdZzqSOauvsAPVFpe4wP X1uDaQI+NR+eItiKPwObJeKwH12IJpigHI04cTxzBuwHb08xJAJG8otgtzUkM7xE0dEW QE7vyIcmy16SXt1MPdhP/xvkQShsZ7MOjU8X/2eQ98Yw2Yt+5kg1Ytq7ETyVt3j7XOsQ nUG22ooCd22sb8QLOfVyVNBUFvWh3vuJO4HCH+Tzl6hhohXjl2TMeTbnotbIdWb1diRU GkqA== X-Gm-Message-State: APjAAAV1bGwPZI+6yuQaEFEATvQ8KphwpPNnSFeMxBLCtW9vkMadr6H2 BD+HkoVmQdzMMNJ7uW/NQo+OhEos X-Google-Smtp-Source: APXvYqzYSdu9sDVy0i9fBTEDCh7yiixLNca+RD8qMN8/paHS2EDbKvE4aNyo8L+bZUvGYj9GXZ3wjQ== X-Received: by 2002:a02:b385:: with SMTP id p5mr5859804jan.43.1578518146687; Wed, 08 Jan 2020 13:15:46 -0800 (PST) Received: from [127.0.1.1] ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id h85sm1304852ili.22.2020.01.08.13.15.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2020 13:15:46 -0800 (PST) Subject: [bpf PATCH 6/9] bpf: sockmap/tls, tls_sw can create a plaintext buf > encrypt buf From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, john.fastabend@gmail.com, ast@kernel.org, daniel@iogearbox.net Date: Wed, 08 Jan 2020 21:15:34 +0000 Message-ID: <157851813461.1732.9406594355094857662.stgit@ubuntu3-kvm2> In-Reply-To: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> References: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org It is possible to build a plaintext buffer using push helper that is larger than the allocated encrypt buffer. When this record is pushed to crypto layers this can result in a NULL pointer dereference because the crypto API expects the encrypt buffer is large enough to fit the plaintext buffer. To resolve catch the cases this can happen and split the buffer into two records to send individually. Unfortunately, there is still one case to handle where the split creates a zero sized buffer. In this case we merge the buffers and unmark the split. This happens when apply is zero and user pushed data beyond encrypt buffer. This fixes the original case as well because the split allocated an encrypt buffer larger than the plaintext buffer and the merge simply moves the pointers around so we now have a reference to the new (larger) encrypt buffer. Perhaps its not ideal but it seems the best solution for a fixes branch and avoids handling these two cases, (a) apply that needs split and (b) non apply case. The are edge cases anyways so optimizing them seems not necessary unless someone wants later in next branches. Fixes: d3b18ad31f93d ("tls: add bpf support to sk_msg handling") Signed-off-by: John Fastabend Acked-by: Jonathan Lemon --- net/tls/tls_sw.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index c6803a82b769..31f6bbbc8992 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -682,12 +682,32 @@ static int tls_push_record(struct sock *sk, int flags, split_point = msg_pl->apply_bytes; split = split_point && split_point < msg_pl->sg.size; + if (unlikely((!split && + msg_pl->sg.size + + prot->overhead_size > msg_en->sg.size) || + (split && + split_point + + prot->overhead_size > msg_en->sg.size))) { + split = true; + split_point = msg_en->sg.size; + } if (split) { rc = tls_split_open_record(sk, rec, &tmp, msg_pl, msg_en, split_point, prot->overhead_size, &orig_end); if (rc < 0) return rc; + /* This can happen if above tls_split_open_record allocates + * a single large encryption buffer instead of two smaller + * ones. In this case adjust pointers and continue without + * split. + */ + if (!msg_pl->sg.size) { + tls_merge_open_record(sk, rec, tmp, orig_end); + msg_pl = &rec->msg_plaintext; + msg_en = &rec->msg_encrypted; + split = false; + } sk_msg_trim(sk, msg_en, msg_pl->sg.size + prot->overhead_size); } From patchwork Wed Jan 8 21:15:52 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1219977 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Original-To: incoming-bpf@patchwork.ozlabs.org Delivered-To: patchwork-incoming-bpf@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=bpf-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="JbP+xeCv"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47tMVZ0mJHz9sP6 for ; Thu, 9 Jan 2020 08:16:06 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727181AbgAHVQF (ORCPT ); Wed, 8 Jan 2020 16:16:05 -0500 Received: from mail-io1-f67.google.com ([209.85.166.67]:35796 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726836AbgAHVQF (ORCPT ); Wed, 8 Jan 2020 16:16:05 -0500 Received: by mail-io1-f67.google.com with SMTP id h8so4837473iob.2; Wed, 08 Jan 2020 13:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=HW7dGFRN4q8bVZHBetakZ6zy0wQpBxJQHxmfLpTAask=; b=JbP+xeCvCBV0fUzxT0Z0He+ZVY2XR3uiUCiTYzgKhIr2tgVzx12O9F8wPnt3vplWQS WU1KbPFYf4+fclhsaJeaDzYMRDSr3N+ESmAEIUCFSzC9iXIxPB2F8xLhP4MBoA/hRSWV 7Dingq1msS4AqeiKtDU1pege/lu9/K8nRCMAxiHJf/dW3XBIJ/xvSpnWvVcR7Wo5yKGH e4gcushclqiEwkqW2ubs++igPTfVdgASmXYXdF2V65sGvc3pg0QAJx9D7X72v5ruMBA1 8MB8AbHIZw7TJrByJSGDW1WaWRFM6SL6sF2t7TrRDpelvcfkMh7sAwNzK2hVyg2bbEYg CuwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:date:message-id:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=HW7dGFRN4q8bVZHBetakZ6zy0wQpBxJQHxmfLpTAask=; b=Xnz0J3FrWmi+m0M00exeQzsLC1fvsRRSEQhN5g0G/PD1O7Ik3+Ua26Mq7WtQCGzvL3 D0ijpl7iZFEZnXGrUQFTo/sVziHkRjNydy8475v9L5A7bJ43cLxwAq/IDhcbbxGek2Lc Hql67IhAWhdy/YrNTivxXBWQsGh3f5ZzCMBM1+1NlKtUpGtJ0vSpYxWJtpWyIJ/6s8q+ mVCMzojT5HrM7zlttOMg7JxNSdPLA0VlnXyEGOqfj4QmT+IOdqBrRVqmPXOyanCrsfSl uVqbneQ7/na24wggtbGlIZAcL+kwgt8PO/wl5dQwsAWhi0zpCpOWM7IWseULjekcg7Jr 16ew== X-Gm-Message-State: APjAAAWLWHTWXRwMfo6CjRc+5i7JVp71B8SCswl0oV5JDjLQQ5bGmuNF hu2bb0SL//wI1uG3ArfSAr19/fxi X-Google-Smtp-Source: APXvYqxrAz+2+NHfFm0dIV73z87vKm/FbqDyeTNBvHbNH65M+DoitYwuv2iFN8i4AXMe1LkxVjL8Dw== X-Received: by 2002:a5d:8353:: with SMTP id q19mr4904287ior.163.1578518164602; Wed, 08 Jan 2020 13:16:04 -0800 (PST) Received: from [127.0.1.1] ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id v10sm886889iol.85.2020.01.08.13.15.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2020 13:16:04 -0800 (PST) Subject: [bpf PATCH 7/9] bpf: sockmap/tls, skmsg can have wrapped skmsg that needs extra chaining From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, john.fastabend@gmail.com, ast@kernel.org, daniel@iogearbox.net Date: Wed, 08 Jan 2020 21:15:52 +0000 Message-ID: <157851815284.1732.9999561233745329569.stgit@ubuntu3-kvm2> In-Reply-To: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> References: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Its possible through a set of push, pop, apply helper calls to construct a skmsg, which is just a ring of scatterlist elements, with the start value larger than the end value. For example, end start |_0_|_1_| ... |_n_|_n+1_| Where end points at 1 and start points and n so that valid elements is the set {n, n+1, 0, 1}. Currently, because we don't build the correct chain only {n, n+1} will be sent. This adds a check and sg_chain call to correctly submit the above to the crypto and tls send path. Fixes: d3b18ad31f93d ("tls: add bpf support to sk_msg handling") Signed-off-by: John Fastabend Acked-by: Jonathan Lemon --- net/tls/tls_sw.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 31f6bbbc8992..21c7725d17ca 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -729,6 +729,12 @@ static int tls_push_record(struct sock *sk, int flags, sg_mark_end(sk_msg_elem(msg_pl, i)); } + if (msg_pl->sg.end < msg_pl->sg.start) { + sg_chain(&msg_pl->sg.data[msg_pl->sg.start], + MAX_SKB_FRAGS - msg_pl->sg.start + 1, + msg_pl->sg.data); + } + i = msg_pl->sg.start; sg_chain(rec->sg_aead_in, 2, &msg_pl->sg.data[i]); From patchwork Wed Jan 8 21:16:11 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1219979 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Original-To: incoming-bpf@patchwork.ozlabs.org Delivered-To: patchwork-incoming-bpf@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=bpf-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="QqoQBK2b"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47tMVw3R9pz9sP6 for ; Thu, 9 Jan 2020 08:16:24 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727063AbgAHVQY (ORCPT ); Wed, 8 Jan 2020 16:16:24 -0500 Received: from mail-il1-f193.google.com ([209.85.166.193]:37214 "EHLO mail-il1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726836AbgAHVQY (ORCPT ); Wed, 8 Jan 2020 16:16:24 -0500 Received: by mail-il1-f193.google.com with SMTP id t8so3908506iln.4; Wed, 08 Jan 2020 13:16:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=m8Rchxp7WynrVrNQW7gz1KcCJvgeZh/2BETow1fq1Bo=; b=QqoQBK2bwdHuoMAaimQOxerVbNsi3Px0z5fL7uQStVjOYFThjmYpGsflbYQ8WpzBA9 qlqk9seUe0pi1gaoOGZ921XYu6osXCCnFLeZIuEE3AeIhO+g0P7azgC67qcOsYAs4EbY uIshlgN+ptvIT1ZjyEreSn2LnBc0Dl1vF+kZ5NVcfhbcGx6NFN+/ECqVK/8gTOW3nmDa R2i56OKSSoySGNKLUK5CaByP8VRZ/akk1wmeyC7WL5GMawgew8dcIzId/A3CaOhLdUPo l+3nggYaJmX6zt3qaymCWhc32I/tZRnjXki49E5qwkcwsuoL8E5eX7RDNb/sAUGl3DBI WtYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:date:message-id:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=m8Rchxp7WynrVrNQW7gz1KcCJvgeZh/2BETow1fq1Bo=; b=HBbtowahChIcy9DRF7g24lErfy0+QwB+iPEdr/rzIcBGd6gD7We1pqjjK4t8NqCpS8 SS8VozMSccZzZ7eYgj4zxdEk7eI+Y5fN/5COv9vrQEQIPF/1UqeACOW8AlaHnpf6Defi 5BQk0MsYpRKXMTt3S487hvbz0Kg2xTDa1tFqkSuBd9mLgZkl3/n8Hp2JWUMmGl+pAgy6 MB5JsFLjpDkrlmbk3oKWFxWaQKpvwjGmpUQ3R6c1tzGmVJuWLL3EJ9mvXmQX52nKqg2P kImxkxbsFhmR9kWrAYRQsRNU+5uxZV7zzeQ7KMZLHAqVs2yznjGZT5RG5vzpdvpry6aw ugVA== X-Gm-Message-State: APjAAAVSZEvDkV3QdLvquZFT+ouze3VY3moXUhWwDiUqNk2n1B0KPKvS pS94Yi4muSwuoD1JqU1eEvjDYEp5 X-Google-Smtp-Source: APXvYqzr/9d+tadjw2nMeNKOAHWft++tJnwtK6W4m0lHXF08zQkV8JkIWyv+pnuzwuKNBpbmcl/NpA== X-Received: by 2002:a92:d5cf:: with SMTP id d15mr5490293ilq.306.1578518183266; Wed, 08 Jan 2020 13:16:23 -0800 (PST) Received: from [127.0.1.1] ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id i13sm903229ioi.67.2020.01.08.13.16.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2020 13:16:22 -0800 (PST) Subject: [bpf PATCH 8/9] bpf: sockmap/tls, tls_push_record can not handle zero length skmsg From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, john.fastabend@gmail.com, ast@kernel.org, daniel@iogearbox.net Date: Wed, 08 Jan 2020 21:16:11 +0000 Message-ID: <157851817088.1732.14988301389495595092.stgit@ubuntu3-kvm2> In-Reply-To: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> References: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org When passed a zero length skmsg tls_push_record() causes a NULL ptr deref. To resolve for fixes do a simple length check at start of routine. To create this case a user can create a BPF program to pop all the data off the message then return SK_PASS. Its not a very practical or useful thing to do so we mark it unlikely. Fixes: d3b18ad31f93d ("tls: add bpf support to sk_msg handling") Signed-off-by: John Fastabend --- net/tls/tls_sw.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 21c7725d17ca..0326e916ab01 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -680,6 +680,9 @@ static int tls_push_record(struct sock *sk, int flags, msg_pl = &rec->msg_plaintext; msg_en = &rec->msg_encrypted; + if (unlikely(!msg_pl->sg.size)) + return 0; + split_point = msg_pl->apply_bytes; split = split_point && split_point < msg_pl->sg.size; if (unlikely((!split && From patchwork Wed Jan 8 21:16:29 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1219981 X-Patchwork-Delegate: bpf@iogearbox.net Return-Path: X-Original-To: incoming-bpf@patchwork.ozlabs.org Delivered-To: patchwork-incoming-bpf@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=bpf-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="gEBJ6yFT"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47tMWJ0cGSz9sP6 for ; Thu, 9 Jan 2020 08:16:43 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727124AbgAHVQn (ORCPT ); Wed, 8 Jan 2020 16:16:43 -0500 Received: from mail-il1-f181.google.com ([209.85.166.181]:37119 "EHLO mail-il1-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726836AbgAHVQn (ORCPT ); Wed, 8 Jan 2020 16:16:43 -0500 Received: by mail-il1-f181.google.com with SMTP id t8so3909251iln.4; Wed, 08 Jan 2020 13:16:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=yXmxsUzDxx3UVsdYKuZEr+cwB6nejckACPxlNU4PCDI=; b=gEBJ6yFTCLzNUV+2DjSCesjosoyDVuqIxuLlyiVdjNgjtVWSX0jzyLBoD4cRMfbu9A pYabl6YXqgONs0OKZ8FAXog8hbJfUKofqm3w2YOkyffeX9+IC86uoPyUjspYzhBPupWB Enc4pZ2d4mOynBelKWbnRoZ5/maTpfCHp/BnyQo3akYOBTr02wvhLhUpvtN7LzzoZmMv fhkvb1c6FxOhHyzM2oxnonGijqLfGqvxL3LTBQuLXJWCVmc3bEYcMscGmPX8ZajMQaDL liL/YRJMPr2bvAIQgZLVj61TLCFuAd4qdTKC0+W0lsuUzo1GB3S/pd/36h+sdBohuirq hY8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:date:message-id:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=yXmxsUzDxx3UVsdYKuZEr+cwB6nejckACPxlNU4PCDI=; b=lg397/DYWLW0eRrLcPxKTplN5Wz6TBw01CJAS1J14MkI9Ya026dAdrRiz1e6n0uRSi v4kKCPfYQteaqHTp56Vvf4RtpTlv1geMocF43IUeXcREvIuLO9up1GPYf7DtAU1fg0P/ wi9ljWXDhIslGrCmOSEGi8u5gnCVvxaUPyg9YZdsB5R6Pbn8gYUwUR1wM8hYjb1WoGED TAoun/UfJybXdmhWtJkPrUaVj+ZZEd0l7Iv3na+dlNSEDo6LSCJC+nb8XPXPHuEnL5Lt J1V+bWk3nwfSIeGTpJRJzGBRMyGQJMd5yukKp66GsjDfuuf3nJZiDEI7KulWxypBJYAn pErQ== X-Gm-Message-State: APjAAAVth7CCSx7qBz8pie23fajEpMfSFTCubm6KSzDJ8bMcTCk7sYx5 dHGxMY+kG7cqNt0kzhOoT4jHTlBs X-Google-Smtp-Source: APXvYqzpurPMotm6OEYRJQfLw4fcefi+5q6PwNDWbC4NIpgURuLX+9VLaBRqKmKJgc/bP26CO6lc4A== X-Received: by 2002:a92:5b49:: with SMTP id p70mr5501604ilb.209.1578518202313; Wed, 08 Jan 2020 13:16:42 -0800 (PST) Received: from [127.0.1.1] ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id x2sm1309186ila.74.2020.01.08.13.16.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jan 2020 13:16:41 -0800 (PST) Subject: [bpf PATCH 9/9] bpf: sockmap/tls, fix pop data with SK_DROP return code From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, john.fastabend@gmail.com, ast@kernel.org, daniel@iogearbox.net Date: Wed, 08 Jan 2020 21:16:29 +0000 Message-ID: <157851818932.1732.14521897338802839226.stgit@ubuntu3-kvm2> In-Reply-To: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> References: <157851776348.1732.12600714815781177085.stgit@ubuntu3-kvm2> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org When user returns SK_DROP we need to reset the number of copied bytes to indicate to the user the bytes were dropped and not sent. If we don't reset the copied arg sendmsg will return as if those bytes were copied giving the user a positive return value. This works as expected today except in the case where the user also pops bytes. In the pop case the sg.size is reduced but we don't correctly account for this when copied bytes is reset. The popped bytes are not accounted for and we return a small positive value potentially confusing the user. The reason this happens is due to a typo where we do the wrong comparison when accounting for pop bytes. In this fix notice the if/else is not needed and that we have a similar problem if we push data except its not visible to the user because if delta is larger the sg.size we return a negative value so it appears as an error regardless. Fixes: 7246d8ed4dcce ("bpf: helper to pop data from messages") Signed-off-by: John Fastabend Acked-by: Jonathan Lemon --- net/ipv4/tcp_bpf.c | 5 +---- net/tls/tls_sw.c | 5 +---- 2 files changed, 2 insertions(+), 8 deletions(-) diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c index e38705165ac9..587d55611814 100644 --- a/net/ipv4/tcp_bpf.c +++ b/net/ipv4/tcp_bpf.c @@ -315,10 +315,7 @@ static int tcp_bpf_send_verdict(struct sock *sk, struct sk_psock *psock, */ delta = msg->sg.size; psock->eval = sk_psock_msg_verdict(sk, psock, msg); - if (msg->sg.size < delta) - delta -= msg->sg.size; - else - delta = 0; + delta -= msg->sg.size; } if (msg->cork_bytes && diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 0326e916ab01..d9a757c0ba0c 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -812,10 +812,7 @@ static int bpf_exec_tx_verdict(struct sk_msg *msg, struct sock *sk, if (psock->eval == __SK_NONE) { delta = msg->sg.size; psock->eval = sk_psock_msg_verdict(sk, psock, msg); - if (delta < msg->sg.size) - delta -= msg->sg.size; - else - delta = 0; + delta -= msg->sg.size; } if (msg->cork_bytes && msg->cork_bytes > msg->sg.size && !enospc && !full_record) {