From patchwork Sat Jan 11 06:11:59 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1221535 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.a=rsa-sha256 header.s=20161025 header.b=glSJbUPk; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47vqK32v42z9sR0 for ; Sat, 11 Jan 2020 17:12:55 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726104AbgAKGMd (ORCPT ); Sat, 11 Jan 2020 01:12:33 -0500 Received: from mail-io1-f67.google.com ([209.85.166.67]:39232 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726065AbgAKGMd (ORCPT ); Sat, 11 Jan 2020 01:12:33 -0500 Received: by mail-io1-f67.google.com with SMTP id c16so4411132ioh.6; Fri, 10 Jan 2020 22:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=k/uOUC4WZrxLQy7Z1uiXWhhGNWt+EgxTQhQgxc/WTeQ=; b=glSJbUPkGbA/zZ77sxSrpphY5koT0ODVZa2PWUS9kxFltmKHRODxtGXD7276Z/zXpz U7OQSf52AapQY4pk2Guvyuo0Np1TNEud5Da/GOuPVCw1bkRT/YrN29SE4oL78YwcKcV7 w/TDm/uxpFIxneS/+MDe5w+4GBLTS8dphBpCYoiDrEtqozYdMFxZZaaRC6ANroAS9i+w mwWnK9bdpNq2PHAKOTTdjfql9h9iI7aFEwnHdQVhe/xo70x91bMp+0404sNZaaepDrT5 f/6Ho1qSJ9FCratYeXyjj5WJZF5wtVqPg1l/n7zcALorGwPhRHcPxc392dcJ/ZbWxfel Hmcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=k/uOUC4WZrxLQy7Z1uiXWhhGNWt+EgxTQhQgxc/WTeQ=; b=EeaWa8tF72zsQ1w+ZutJYgL3jk5I+eRZ2rvpUnUoTK7Mc7y3289Hqh09u/Nb7NtVAx yqX5RQhLBNTwHNJjzkBiMzt/cqrQEVYtIhLUHbfiKT7XZyC8/bNThxxQXYhAp1BT66nR FIS4CBDYuNicJ53ldOS3mHFvRZpsL6vRj/MNpHn2MOKBLYBm9HwE+bTHj5h0NiQN99YL Pn7e/sA6HGXt7EaNyZj8HdzQ1lK63HeeLGQiRdNtZe7qpJ+VcjdcOgtAmaFHnhx2lYCx ieWiBjc7vl3NRLnFv1q6gqYBSbnBW9YFwJ+0Pi179KhKjWQVxixp6aOMifBosmlpwfZ0 +fJA== X-Gm-Message-State: APjAAAX1jaz6RdVMlsenVtfto7TnRTLzbSovHU3xKQ+lEr0bKFfY3BvR eM9hF6/xFF25gMQyWbjQYKMkYhud X-Google-Smtp-Source: APXvYqzogvFDa66OvKD/9iILKwwbyTtZo6bxlJax41rKJ3OLTlrA2CZG02NidGW3cnXBGgIsGmoDCg== X-Received: by 2002:a5e:8813:: with SMTP id l19mr5711114ioj.261.1578723152076; Fri, 10 Jan 2020 22:12:32 -0800 (PST) Received: from localhost.localdomain ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id 141sm1417784ile.44.2020.01.10.22.12.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jan 2020 22:12:31 -0800 (PST) From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org, john.fastabend@gmail.com, song@kernel.org, jonathan.lemon@gmail.com Subject: [bpf PATCH v2 1/8] bpf: sockmap/tls, during free we may call tcp_bpf_unhash() in loop Date: Sat, 11 Jan 2020 06:11:59 +0000 Message-Id: <20200111061206.8028-2-john.fastabend@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200111061206.8028-1-john.fastabend@gmail.com> References: <20200111061206.8028-1-john.fastabend@gmail.com> 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 Cc: stable@vger.kernel.org Acked-by: Song Liu Signed-off-by: John Fastabend Reviewed-by: Jakub Sitnicki --- 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 Sat Jan 11 06:12:00 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1221536 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.a=rsa-sha256 header.s=20161025 header.b=sJmBlUuH; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47vqK36YS1z9sR8 for ; Sat, 11 Jan 2020 17:12:55 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726262AbgAKGMm (ORCPT ); Sat, 11 Jan 2020 01:12:42 -0500 Received: from mail-io1-f66.google.com ([209.85.166.66]:33913 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726065AbgAKGMl (ORCPT ); Sat, 11 Jan 2020 01:12:41 -0500 Received: by mail-io1-f66.google.com with SMTP id z193so4440404iof.1; Fri, 10 Jan 2020 22:12:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=2YO/NNWKM5qMXT2mbSvtSSJzyxAWg0hu0wdxBaM9JKk=; b=sJmBlUuHXvYYtxlbwOOVZBx67VJgtR0LUlzlDcqPJgs0+lvWDTRBkr8bSybEBEGTy2 lmNZHQOy3X1WaUv3HyZ7RIHUKYPOSdJAI0FpMxT+GuV9TFwgwcJwnFLBtsS9raZsbmQl DMaHbmPKopLgE5mXrtCUmpFrNU8H9e1rapHLFO+7rHYHUPZ7KLGos4t0BrCJ2McF/kKS Le2GCynm9eSa8T3M3kEq/aGkksAuRnZ7av5Xo/FsmtiGdC3at8yLJcVBUz0m3NMi387e YpxtsODBFmoAA5S9mw5+TvkxcaK4THIZVgf5AGd80/XiP75ZQv4zqDS7RLQ4ShV4HNPn FFfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=2YO/NNWKM5qMXT2mbSvtSSJzyxAWg0hu0wdxBaM9JKk=; b=EHgxTmjUdrlhIDDHel1gojHkAv0YrbOzy8tJ4q3xVYPaD+EB3iI47NS5qvudRoXS+x CdMJ2xdtYLk6P8KDpvYAw3131vgyiL2KyLGODYDavcTx8SpN9Ef3yzco3xYQZpsjnfWl b3CFld+TUisOhVzJdCRmvga8k7hADJ0mvobB7A/rox6FruLAkhzSJW8Z5QD9ncW7Osll q8j1ptBE7P5bPbniYt3DzDhhk/BSMS2hZoHXbusjp8h2piNHYEY+i9Rw5tD13jVr7JCc 5yDoHC0nQxw6WrQu5AqARj+eHCZ0M3lsKdks0IsdHEAnsgcxn+BfCH9Sbtzw6tbFUULq zRvA== X-Gm-Message-State: APjAAAWcOjogE74J+M6Nti0gwahL5E29KyvGERd5Pp1QZAix+POUl3be E16lPtCYlcJrbsxj1hETHqySI40K X-Google-Smtp-Source: APXvYqxJ8ZGh0Q7/VcVr2PoAr6Qa0ThQYX3jaGtsJih9yJdXn1w+bPzc4LP/g4qB8e0u/44m6YXqdg== X-Received: by 2002:a02:c951:: with SMTP id u17mr6361541jao.27.1578723161110; Fri, 10 Jan 2020 22:12:41 -0800 (PST) Received: from localhost.localdomain ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id 141sm1417784ile.44.2020.01.10.22.12.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jan 2020 22:12:40 -0800 (PST) From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org, john.fastabend@gmail.com, song@kernel.org, jonathan.lemon@gmail.com Subject: [bpf PATCH v2 2/8] bpf: sockmap, ensure sock lock held during tear down Date: Sat, 11 Jan 2020 06:12:00 +0000 Message-Id: <20200111061206.8028-3-john.fastabend@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200111061206.8028-1-john.fastabend@gmail.com> References: <20200111061206.8028-1-john.fastabend@gmail.com> 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") Cc: stable@vger.kernel.org Acked-by: Song Liu Signed-off-by: John Fastabend --- 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 Sat Jan 11 06:12:01 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1221537 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.a=rsa-sha256 header.s=20161025 header.b=OJOa+DHT; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47vqK42WxNz9sPn for ; Sat, 11 Jan 2020 17:12:56 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728380AbgAKGMw (ORCPT ); Sat, 11 Jan 2020 01:12:52 -0500 Received: from mail-il1-f195.google.com ([209.85.166.195]:33815 "EHLO mail-il1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726065AbgAKGMw (ORCPT ); Sat, 11 Jan 2020 01:12:52 -0500 Received: by mail-il1-f195.google.com with SMTP id s15so3630923iln.1; Fri, 10 Jan 2020 22:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=QiMdV4OLEwq0FLj4VztT2ToAicHmfpX3NmaOXmEG4Lw=; b=OJOa+DHTTThbQQx89RRflJq4Tn7Xc6VGUA3aRIzrKAPY4FTfDIXHC5+Mt676ztjs0B 2nsd2VHylloAqZ7xeKYpCy9u0u0DC4WB9KH3h/2ux07QQOTVNRcFefr5R0bqcWHf3WHg 37g5/8XE9XDHhZ6SqShxBgOTaxAJC8qQA6E4gGHpqjBu+gPU1yvAjmalyCMVhlDBjd2Y u3NsKbTbGY6Pk/4/AQoH3Wmb8v723krAdxe9zx9JZ3Ah81+C+Mnb/KK4G72kJhZ1w7Yd sWsHTBgLoGBw2rD4qz7a/5c+4Azv9TpvgaQQNWCINR8cZ38rHHJ/txtFy22fZrBMJ55X BTaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=QiMdV4OLEwq0FLj4VztT2ToAicHmfpX3NmaOXmEG4Lw=; b=C2G4pn36/0WN3fUjWIHd9+LmL5j+lak/9ODas7ZKmS4dKlf/pSFYfAi47r17PAL5Up x0qPgKuVxEBgS5WTSFNC5iL+EGO2y/XhSO+EAsfMAoaoYdylsQJqxxgI4YX9TwmPp8w0 19ZVaBy9KP1reHEGaBrwZLvBR4h8FDb4g4KjdOhpClN5ygfPWudMvQM/YbTJJJgQUB6x trtJVY26iXBXfwVhHUm5sk6ORX7ARmwKF7UedrktkAGpyXYHQkZhBcO3VLHlzKl0sk9e s06oAALHleGcYVOn39tQQJb1J9rgkAC4kVjYg9STM9NNmUuspA+3QNysPvPaJa3kpED3 I+Hw== X-Gm-Message-State: APjAAAUTHMcFgKqyeqZGybt9hj2X1mJlyQlyvs8BunCalJHst0cPEaTc Ji3be2yLoFzrupJNIlgMo9bQAoUN X-Google-Smtp-Source: APXvYqwIgdCdmvs7bNvjMHilXiaKdd+ltp/jT2xDbe7RqRWATifael0p4TrYfj61xMPIwY7Zbw1EbA== X-Received: by 2002:a92:ca8b:: with SMTP id t11mr6364437ilo.227.1578723171297; Fri, 10 Jan 2020 22:12:51 -0800 (PST) Received: from localhost.localdomain ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id 141sm1417784ile.44.2020.01.10.22.12.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jan 2020 22:12:50 -0800 (PST) From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org, john.fastabend@gmail.com, song@kernel.org, jonathan.lemon@gmail.com Subject: [bpf PATCH v2 3/8] bpf: sockmap/tls, push write_space updates through ulp updates Date: Sat, 11 Jan 2020 06:12:01 +0000 Message-Id: <20200111061206.8028-4-john.fastabend@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200111061206.8028-1-john.fastabend@gmail.com> References: <20200111061206.8028-1-john.fastabend@gmail.com> 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. Cc: stable@vger.kernel.org Fixes: 95fa145479fbc ("bpf: sockmap/tls, close can race with map free") Signed-off-by: John Fastabend Acked-by: Jonathan Lemon Reviewed-by: Jakub Sitnicki --- 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 Sat Jan 11 06:12:02 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1221542 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.a=rsa-sha256 header.s=20161025 header.b=o6uawgi+; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47vqKC18wtz9sP3 for ; Sat, 11 Jan 2020 17:13:03 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728394AbgAKGNC (ORCPT ); Sat, 11 Jan 2020 01:13:02 -0500 Received: from mail-il1-f196.google.com ([209.85.166.196]:42207 "EHLO mail-il1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726065AbgAKGNC (ORCPT ); Sat, 11 Jan 2020 01:13:02 -0500 Received: by mail-il1-f196.google.com with SMTP id t2so3590750ilq.9; Fri, 10 Jan 2020 22:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=8SRJAuD6qlOD0HSHgo+IvNbTx/fcAJ7xhAU9mfc1Ves=; b=o6uawgi+8OmM89CDqXqZoGJfdNydWXpnWS0ecI9oEOo8pXTIPUq748kWVRBRPnj3Ov kb+MuhelrLsa3rkE7QP85w6KqA9zFU5HMAhC8WuxqXa98iz1FWF1eE7E0czepMw/3ux1 kqRmSP9jEO2Qiih3b+S+qvLa+OCnI8X1W9nOT69LgxAUqNSHac5pcfaayTvm4EolLcGp cH2R3Oj5WLrfl1bYz8CX5Ra1FObFq5IjfU8g2JMrTNcsSJme1LDo0qEk5V+v/We/cAXW raErJb5fImh/f1oHTCsdV2O6gESvAcTOq0yIEn3+zPxIRoSsr1LYC1XmFKzrUUnPfeDA dg2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=8SRJAuD6qlOD0HSHgo+IvNbTx/fcAJ7xhAU9mfc1Ves=; b=LGp34mRGPMC1yFKOuiGALQstHypiSgFh8CUPCt3kqT/cA3EtcZukNbt1wd4y36Q0Vw jK53lCvlbn4fk028P05ciEoJjEyrU1/vdYTpO88uRFmcBGNnKm97oUdgGWOcSOrQBJq2 ujuxARl5a5zX50ty6S+a5CsQZWlK6yC+0IUqrH8wNoEUJzcCHMXSazc43xI2ZCnYOjyv bGWeuyZDH/bDc5UeG/eiecFyAAr5tmriIDEzuJ2sTi5zLr+w4BgA9Q5Nqjywp/jas6wm nfc6+xMN1v+Zvs5/n2NFUTk2Xw7FwGtTftSqkhTPjiHl16ndkmptPmARE1tMaicJ+24H Me1Q== X-Gm-Message-State: APjAAAVUpwjnGUvGAlRNDaGJC3PAuwSWnjyzoxiDej7Pm6M5YWvKoqUy 17AGD0rtXfot4WEKEMUzlcsqIcLS X-Google-Smtp-Source: APXvYqweHuLLy6ioN+DmkMuH2W62etIvLBu1N4lBObEkyEBEU+eiUj3Ez4rBfL6qqDaChFVymVTAkg== X-Received: by 2002:a92:d809:: with SMTP id y9mr6241457ilm.261.1578723181012; Fri, 10 Jan 2020 22:13:01 -0800 (PST) Received: from localhost.localdomain ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id 141sm1417784ile.44.2020.01.10.22.12.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jan 2020 22:13:00 -0800 (PST) From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org, john.fastabend@gmail.com, song@kernel.org, jonathan.lemon@gmail.com Subject: [bpf PATCH v2 4/8] bpf: sockmap, skmsg helper overestimates push, pull, and pop bounds Date: Sat, 11 Jan 2020 06:12:02 +0000 Message-Id: <20200111061206.8028-5-john.fastabend@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200111061206.8028-1-john.fastabend@gmail.com> References: <20200111061206.8028-1-john.fastabend@gmail.com> 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") CC: stable@vger.kernel.org Acked-by: Song Liu Signed-off-by: John Fastabend --- 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 d22d108fc6e3..ffa2278020d7 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 Sat Jan 11 06:12:03 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1221543 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.a=rsa-sha256 header.s=20161025 header.b=hsBchSmK; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47vqKM038gz9sP3 for ; Sat, 11 Jan 2020 17:13:11 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726272AbgAKGNK (ORCPT ); Sat, 11 Jan 2020 01:13:10 -0500 Received: from mail-io1-f67.google.com ([209.85.166.67]:37027 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726065AbgAKGNJ (ORCPT ); Sat, 11 Jan 2020 01:13:09 -0500 Received: by mail-io1-f67.google.com with SMTP id k24so4420158ioc.4; Fri, 10 Jan 2020 22:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=5w0X58zzRAug36IcN1KmduMBJ6zMEtZzvHiQMzXnCpg=; b=hsBchSmKRoAw4UPYizmTfISJzJiNC6jtdteBwdp4kTCOcq+4g1b1dZqmc5P60JSgDw z4aO3Cmr4zwNpZD6anR060iw7qn/jRZ4WDzg6J6wV7XnZJ+niXdGQClX9RhB4f2BKrw/ hQ06yhD5lSjsUPITQVoPHig6UA00hD7xRiGcq8jWnhY3Cl0x9nfW3And/Vb31taFsKhL iI3PQAITJRJPMjTTp6euCB6TN9H5WAcP/0hk1GjSKyf3n5rgNbjTf7lM5DUwTddaJFDA gMWqSCa6UvuUAkDE9CI8CXer3wyslTihvUzsYnCztkWIDC3yI3wVBmHMYPKDWo1BGm91 5zxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=5w0X58zzRAug36IcN1KmduMBJ6zMEtZzvHiQMzXnCpg=; b=COPjJuoFLRtDqlW4e6tXwdLAMnX23NQJoYBOvcNAZkGE3bd/HQAoaHuKBVwqgr0p99 KlFweYTXBRoXj27GWEgOYjGjL7kwA3FgxSY6XWVFqpBjvMwkZb5/Nc8VqBIOorP0S1hZ uZuzFSmhKd354YAshZ2V/QaZ18wACtW4xF1++xhzeA+ZVjGedOY6chD+sinI6Wpxomt7 932LKX9jIgKE1bYbjziNYs5rarMnTzCsvOJTgNVl44CWzFKNyeB5GZvZlpQXOcWs5vrh N0L4eSTIovH4NoWcLgmQGo+pvOsNrW2lmvRMtL5S5Non8k1E1MF/5fQb/xL58Sta4hr0 ru+w== X-Gm-Message-State: APjAAAVcvnGj2jnHVTk0VuE8JzxcZwKY+TIEH6zOwRaKwwSCYd//OOe/ MQCAD3MZ8QHG7YnpHIE8K8AFptoN X-Google-Smtp-Source: APXvYqxZiLbBlCPj7OZJa1QEIDjT/1FKUd6t528dtBR4DJcMJD617RKf3z8vWNC3UDcOxrvqAiR1gw== X-Received: by 2002:a02:3ece:: with SMTP id s197mr6135546jas.30.1578723189152; Fri, 10 Jan 2020 22:13:09 -0800 (PST) Received: from localhost.localdomain ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id 141sm1417784ile.44.2020.01.10.22.13.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jan 2020 22:13:08 -0800 (PST) From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org, john.fastabend@gmail.com, song@kernel.org, jonathan.lemon@gmail.com Subject: [bpf PATCH v2 5/8] bpf: sockmap/tls, msg_push_data may leave end mark in place Date: Sat, 11 Jan 2020 06:12:03 +0000 Message-Id: <20200111061206.8028-6-john.fastabend@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200111061206.8028-1-john.fastabend@gmail.com> References: <20200111061206.8028-1-john.fastabend@gmail.com> Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@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") Cc: stable@vger.kernel.org Acked-by: Song Liu Signed-off-by: John Fastabend --- net/core/filter.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/core/filter.c b/net/core/filter.c index ffa2278020d7..538f6a735a19 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 Sat Jan 11 06:12:04 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1221546 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.a=rsa-sha256 header.s=20161025 header.b=gwWMnaOi; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47vqKX66TZz9sP3 for ; Sat, 11 Jan 2020 17:13:20 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726262AbgAKGNT (ORCPT ); Sat, 11 Jan 2020 01:13:19 -0500 Received: from mail-il1-f193.google.com ([209.85.166.193]:39199 "EHLO mail-il1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726065AbgAKGNT (ORCPT ); Sat, 11 Jan 2020 01:13:19 -0500 Received: by mail-il1-f193.google.com with SMTP id x5so3601210ila.6; Fri, 10 Jan 2020 22:13:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=lvrCk0VuIjfhEPX8yFOFrXJYpOrWuYs2nDi2vn6KESg=; b=gwWMnaOiuxoBgcxKLKEAvtJvEuHFW0XrPAC644+641ShN2zLRMP8PJXzTeukjVTEGU uEDontKhlAjjazj9SBLlRIKltL2q/RmRY+O+XrMvC8OAim08ohYTY8Ng7E1Bf2IuoVWK KTKZnM3fqREv+u2tMfc2mXSs70fBTYy7mVjPHagAHv+1N4FdXPlaKhLWB6CNRkz0X2Ez e3HKxXX7lAmMRn5EilR5q5KYxs/4Mb3UOGRWZte6uldk4r6gWUYkpMk2uOPLcdQjv0X1 llsV63KHTwBtHt3ywD19K8k9VwWndQzCDd/NlxWzLCK/4EH7cJHmp6TQYNO4QL2I1v2c 6D4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=lvrCk0VuIjfhEPX8yFOFrXJYpOrWuYs2nDi2vn6KESg=; b=bWDuz70nUzO4WHJKtaNQU3A5Hp2t5EmpxEfrJidUwQyX8PUTyxPuoSdR7MH2lt6hqS V/lactcLsTH92CqfpXrx6X7Z+UrxOGvpI297qRI/gVKlSieX5zBY8zJqHVzVlL5VsQ72 vy4XDnUetuENUa6nsyEQyaLw89UKG2gHSEyRuYxmlTOUnk+J+l8yRvOVgxdOkrg0oDgR 4tuHUVsnIcBnmrPUvAFXZJ2EM4CmtWCBtf4sOMfDl2soHc/fHaJOJZk7UZvfIwrseHRa HbhHNgsXBH+QLhUhHMt1NqhSUxs4zIF/S5/go6gmFmMps6k9naxC7o/XbzIq85cTcps1 IY8w== X-Gm-Message-State: APjAAAVLXUfQw6JnxcxxHjn26mxlr/16dIoEn48cbC1Y+sDfkQBmAePR zEqiOgvozs5fe3naPX6eBRxVSa8z X-Google-Smtp-Source: APXvYqza7092BKt+ErtNSj3GsSktvVnFMX2TA9WRN8B7LKkXEtzMtVNMe0+h1VKHyZ63R99z+egQ9A== X-Received: by 2002:a92:af8e:: with SMTP id v14mr5828924ill.150.1578723198895; Fri, 10 Jan 2020 22:13:18 -0800 (PST) Received: from localhost.localdomain ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id 141sm1417784ile.44.2020.01.10.22.13.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jan 2020 22:13:18 -0800 (PST) From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org, john.fastabend@gmail.com, song@kernel.org, jonathan.lemon@gmail.com Subject: [bpf PATCH v2 6/8] bpf: sockmap/tls, tls_sw can create a plaintext buf > encrypt buf Date: Sat, 11 Jan 2020 06:12:04 +0000 Message-Id: <20200111061206.8028-7-john.fastabend@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200111061206.8028-1-john.fastabend@gmail.com> References: <20200111061206.8028-1-john.fastabend@gmail.com> Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@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. Kernel splat below. 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. [ 306.719107] BUG: kernel NULL pointer dereference, address: 0000000000000008 [...] [ 306.747260] RIP: 0010:scatterwalk_copychunks+0x12f/0x1b0 [...] [ 306.770350] Call Trace: [ 306.770956] scatterwalk_map_and_copy+0x6c/0x80 [ 306.772026] gcm_enc_copy_hash+0x4b/0x50 [ 306.772925] gcm_hash_crypt_remain_continue+0xef/0x110 [ 306.774138] gcm_hash_crypt_continue+0xa1/0xb0 [ 306.775103] ? gcm_hash_crypt_continue+0xa1/0xb0 [ 306.776103] gcm_hash_assoc_remain_continue+0x94/0xa0 [ 306.777170] gcm_hash_assoc_continue+0x9d/0xb0 [ 306.778239] gcm_hash_init_continue+0x8f/0xa0 [ 306.779121] gcm_hash+0x73/0x80 [ 306.779762] gcm_encrypt_continue+0x6d/0x80 [ 306.780582] crypto_gcm_encrypt+0xcb/0xe0 [ 306.781474] crypto_aead_encrypt+0x1f/0x30 [ 306.782353] tls_push_record+0x3b9/0xb20 [tls] [ 306.783314] ? sk_psock_msg_verdict+0x199/0x300 [ 306.784287] bpf_exec_tx_verdict+0x3f2/0x680 [tls] [ 306.785357] tls_sw_sendmsg+0x4a3/0x6a0 [tls] test_sockmap test signature to trigger bug, [TEST]: (1, 1, 1, sendmsg, pass,redir,start 1,end 2,pop (1,2),ktls,): Cc: stable@vger.kernel.org Fixes: d3b18ad31f93d ("tls: add bpf support to sk_msg handling") Acked-by: Jonathan Lemon Signed-off-by: John Fastabend --- 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 Sat Jan 11 06:12:05 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1221548 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.a=rsa-sha256 header.s=20161025 header.b=kUwY/oq+; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47vqKh50rRz9sP3 for ; Sat, 11 Jan 2020 17:13:28 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728424AbgAKGN1 (ORCPT ); Sat, 11 Jan 2020 01:13:27 -0500 Received: from mail-il1-f194.google.com ([209.85.166.194]:41494 "EHLO mail-il1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726065AbgAKGN1 (ORCPT ); Sat, 11 Jan 2020 01:13:27 -0500 Received: by mail-il1-f194.google.com with SMTP id f10so3584538ils.8; Fri, 10 Jan 2020 22:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=lhB0LKsb7l79Kz/6/x4gGYFNCjC4VcBwutdH+J/eLFs=; b=kUwY/oq+hcBwiMRSO8NWJaYwEYHjr+D8MTxGos/pa2BdTjU40qRu6NLAdAdPTrdDOa jGQCXBGm3OpFZN46Ojx2eYvIwZsj5Vm5xRPKgMH1k9ixJmJbun+uA84QIe78oy8wXQIT HMpyXYE0TdUKC3Qc+L6a4jInx3L7ODeUVTawHHrJ4AzQqmxuH6IF74X/LEZxd6pc2azp 5Igit2i1VY9SCEbBlGWHcaXPnYiOawdh95OlUDamAPb94bLPxx4dQjTPwU7RJfCsPClR wt3iHHCl+C/0a3Y9RjdP/AJxb3DlKyUed7etOoJbcGaauivJAkEmu+b63mPUUO2BeQUz rJ0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=lhB0LKsb7l79Kz/6/x4gGYFNCjC4VcBwutdH+J/eLFs=; b=UaTjxDpyCs4uZO0BFkZ+zmJ1I8yhfeW1VVYxXAOh9NV6RoiZL83QiOft+R+JX3qCTz LR/zgVQDz/HCY6UHBTZKPFwpUp/1bcbKdKrxtsPhUL+TTUDLKzUbwA0pdBysMBNdTyzL r1yBxtziPOnr1iwe1E6vPZHqM8c77DGZoHA7mkdVpAcvlNV54rQchMLOgFszkPoJtXJ8 Uh1gWp03JDdN+akqTRKsJSHBjltF+fJahCmpRc3wBQzXlQfA+a4HilAIp8DyreQ6eJ4F fvVrZr1XC01vetEkq46LxUmQ8mNTVzuD+rebQOVOfUUaIa1QYIB73HSlnbP5dHr5nDRL y3Lg== X-Gm-Message-State: APjAAAV35bmxYs8Zux0nIGOy97S+w37stoZiSQ2SdsD/2y2p0jZRp2dP QoQ1fFFwbBvUarmFrPKlP8/WOWBD X-Google-Smtp-Source: APXvYqw604jH7SmBLKeov5rjpfFiYbl8oSc7NvFdS/eDGqUntZvEsQif19tMwrMcC8sOEtU8uEWRTA== X-Received: by 2002:a92:489a:: with SMTP id j26mr6403868ilg.226.1578723206876; Fri, 10 Jan 2020 22:13:26 -0800 (PST) Received: from localhost.localdomain ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id 141sm1417784ile.44.2020.01.10.22.13.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jan 2020 22:13:26 -0800 (PST) From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org, john.fastabend@gmail.com, song@kernel.org, jonathan.lemon@gmail.com Subject: [bpf PATCH v2 7/8] bpf: sockmap/tls, skmsg can have wrapped skmsg that needs extra chaining Date: Sat, 11 Jan 2020 06:12:05 +0000 Message-Id: <20200111061206.8028-8-john.fastabend@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200111061206.8028-1-john.fastabend@gmail.com> References: <20200111061206.8028-1-john.fastabend@gmail.com> 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. Cc: stable@vger.kernel.org Fixes: d3b18ad31f93d ("tls: add bpf support to sk_msg handling") Acked-by: Jonathan Lemon Signed-off-by: John Fastabend --- 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 Sat Jan 11 06:12:06 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Fastabend X-Patchwork-Id: 1221550 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.a=rsa-sha256 header.s=20161025 header.b=vFyRz6U+; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 47vqKt2hYBz9sP3 for ; Sat, 11 Jan 2020 17:13:38 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728434AbgAKGNh (ORCPT ); Sat, 11 Jan 2020 01:13:37 -0500 Received: from mail-io1-f68.google.com ([209.85.166.68]:36066 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728432AbgAKGNh (ORCPT ); Sat, 11 Jan 2020 01:13:37 -0500 Received: by mail-io1-f68.google.com with SMTP id d15so4446899iog.3; Fri, 10 Jan 2020 22:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=aWJKRDY8MhSXF1Y5+iELc/XyQ+wGJ0meS4Z9ad1oV9M=; b=vFyRz6U+rGU8ISXQDQVjwoEofji3TT+I/BRePEbhMMmourl6enq3raY2UWAZ0g41FF v6kdR4ky6wSl2epx2eCQ4r5e7IUxsJRHa5fXxVv1gM9iL3WYfyB7MqWbin1gACaPAX8+ joNlQDl60SgMCDD19gfnWCf6NQmNq8tlZAI9jlBmiXkLjqgov1dDRvC+SbMOq5JBhoZ0 6U/GpEVV1dBp+tkftWvzAtWZFtFQAmjpMhpVBopeP5O/xmtzD7T/iXMFkbEKmYPAZQ/I 4yNXmR6mLu4FDM2j4mLHvVo5gK3w+KXO8yg5EJhD5btGJiGOe0HKuCfrSS9RmcYBajrM 41OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=aWJKRDY8MhSXF1Y5+iELc/XyQ+wGJ0meS4Z9ad1oV9M=; b=JWdKizMo4gRf5bsTCViQq4LR8UXqb+kUo2voSrfpNjUgu46dWp4mnqP2V4BzhANSfx 7QkkTuXo8ja2znS547vj0T7+PCCqNYLozTMpgernUjff9VVMODXP1FFaQF8N4g5VF/P2 ZxJHNi6M38RqKpcb+LaVRNtHwqp4/W4+bsJSvOmDqhSXNFfDGpGy5ObdZ0I217PrdirT OHQ4MUaqENebGltygJf4IBRjYeWSAMiibC9CYg1+v12fnV9B4vQVsAv1HJsavZFAFQuY b+a6JHZPyHvjKBYPXw4UXr3yxZXMbU0GUEvm9oAmo8ethmD1tT7odNNoM90lM55umHVJ qLlQ== X-Gm-Message-State: APjAAAVw1Y9m5vMr3Qepuiusa2G9FKndNrKwNKzeVJMA3bWG0g+jn3/4 ZtW2eGjXrH5euJOv9z9eutF6nt/d X-Google-Smtp-Source: APXvYqzUw18RYIIqv8OG3R4jSuqIeeiVxMsBROc/KQyYmSYT+zcbuZwy/A8Iexcn74GPb9cktjeTVA== X-Received: by 2002:a5e:8b03:: with SMTP id g3mr5495370iok.279.1578723216530; Fri, 10 Jan 2020 22:13:36 -0800 (PST) Received: from localhost.localdomain ([184.63.162.180]) by smtp.gmail.com with ESMTPSA id 141sm1417784ile.44.2020.01.10.22.13.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jan 2020 22:13:36 -0800 (PST) From: John Fastabend To: bpf@vger.kernel.org Cc: netdev@vger.kernel.org, daniel@iogearbox.net, ast@kernel.org, john.fastabend@gmail.com, song@kernel.org, jonathan.lemon@gmail.com Subject: [bpf PATCH v2 8/8] bpf: sockmap/tls, fix pop data with SK_DROP return code Date: Sat, 11 Jan 2020 06:12:06 +0000 Message-Id: <20200111061206.8028-9-john.fastabend@gmail.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200111061206.8028-1-john.fastabend@gmail.com> References: <20200111061206.8028-1-john.fastabend@gmail.com> 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. Cc: stable@vger.kernel.org Fixes: 7246d8ed4dcce ("bpf: helper to pop data from messages") Acked-by: Jonathan Lemon Signed-off-by: John Fastabend --- 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 e6b08b5a0895..8a01428f80c1 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 21c7725d17ca..159d49dab403 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -809,10 +809,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) {