From: John Fastabend <john.fastabend@gmail.com>
To: jakub@cloudflare.com, rivendell7@gmail.com, kuniyu@amazon.com
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org
Subject: [PATCH bpf 1/5] bpf: sockmap, fix proto update hook to avoid dup calls
Date: Thu, 21 Dec 2023 15:23:23 -0800 [thread overview]
Message-ID: <20231221232327.43678-2-john.fastabend@gmail.com> (raw)
In-Reply-To: <20231221232327.43678-1-john.fastabend@gmail.com>
When sockets are added to a sockmap or sockhash we allocate and init a
psock. Then update the proto ops with sock_map_init_proto the flow is
sock_hash_update_common
sock_map_link
psock = sock_map_psock_get_checked() <-returns existing psock
sock_map_init_proto(sk, psock) <- updates sk_proto
If the socket is already in a map this results in the sock_map_init_proto
being called multiple times on the same socket. We do this because when
a socket is added to multiple maps this might result in a new set of BPF
programs being attached to the socket requiring an updated ops struct.
This creates a rule where it must be safe to call psock_update_sk_prot
multiple times. When we added a fix for UAF through unix sockets in patch
4dd9a38a753fc we broke this rule by adding a sock_hold in that path
to ensure the sock is not released. The result is if a af_unix stream sock
is placed in multiple maps it results in a memory leak because we call
sock_hold multiple times with only a single sock_put on it.
Fixes: 4dd9a38a753fc ("bpf: sockmap, fix proto update hook to avoid dup calls")
Rebported-by: Xingwei Lee <xrivendell7@gmail.com>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
net/unix/unix_bpf.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/net/unix/unix_bpf.c b/net/unix/unix_bpf.c
index 7ea7c3a0d0d0..bd84785bf8d6 100644
--- a/net/unix/unix_bpf.c
+++ b/net/unix/unix_bpf.c
@@ -161,15 +161,30 @@ int unix_stream_bpf_update_proto(struct sock *sk, struct sk_psock *psock, bool r
{
struct sock *sk_pair;
+ /* Restore does not decrement the sk_pair reference yet because we must
+ * keep the a reference to the socket until after an RCU grace period
+ * and any pending sends have completed.
+ */
if (restore) {
sk->sk_write_space = psock->saved_write_space;
sock_replace_proto(sk, psock->sk_proto);
return 0;
}
- sk_pair = unix_peer(sk);
- sock_hold(sk_pair);
- psock->sk_pair = sk_pair;
+ /* psock_update_sk_prot can be called multiple times if psock is
+ * added to multiple maps and/or slots in the same map. There is
+ * also an edge case where replacing a psock with itself can trigger
+ * an extra psock_update_sk_prot during the insert process. So it
+ * must be safe to do multiple calls. Here we need to ensure we don't
+ * increment the refcnt through sock_hold many times. There will only
+ * be a single matching destroy operation.
+ */
+ if (!psock->sk_pair) {
+ sk_pair = unix_peer(sk);
+ sock_hold(sk_pair);
+ psock->sk_pair = sk_pair;
+ }
+
unix_stream_bpf_check_needs_rebuild(psock->sk_proto);
sock_replace_proto(sk, &unix_stream_bpf_prot);
return 0;
--
2.33.0
next prev parent reply other threads:[~2023-12-21 23:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-21 23:23 [PATCH bpf 0/5] fix sockmap + stream af_unix memleak John Fastabend
2023-12-21 23:23 ` John Fastabend [this message]
2024-01-02 12:00 ` [PATCH bpf 1/5] bpf: sockmap, fix proto update hook to avoid dup calls Jakub Sitnicki
2024-01-04 1:00 ` Martin KaFai Lau
2024-01-04 3:47 ` John Fastabend
2023-12-21 23:23 ` [PATCH bpf 2/5] bpf: sockmap, added comments describing update proto rules John Fastabend
2023-12-21 23:23 ` [PATCH bpf 3/5] bpf: sockmap, add tests for proto updates many to single map John Fastabend
2023-12-21 23:23 ` [PATCH bpf 4/5] bpf: sockmap, add tests for proto updates single socket to many map John Fastabend
2023-12-21 23:23 ` [PATCH bpf 5/5] bpf: sockmap, add tests for proto updates replace socket John Fastabend
2024-01-02 15:18 ` [PATCH bpf 0/5] fix sockmap + stream af_unix memleak Jakub Sitnicki
2024-01-02 23:49 ` John Fastabend
2024-01-04 1:00 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231221232327.43678-2-john.fastabend@gmail.com \
--to=john.fastabend@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=jakub@cloudflare.com \
--cc=kuniyu@amazon.com \
--cc=netdev@vger.kernel.org \
--cc=rivendell7@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.