* [PATCH bpf] bpf: sockmap: check update requirements after locking
@ 2020-02-07 10:37 Lorenz Bauer
2020-02-07 10:56 ` Jakub Sitnicki
2020-02-07 21:50 ` Daniel Borkmann
0 siblings, 2 replies; 3+ messages in thread
From: Lorenz Bauer @ 2020-02-07 10:37 UTC (permalink / raw)
To: John Fastabend, Daniel Borkmann, David S. Miller, Jakub Kicinski,
Alexei Starovoitov, Martin KaFai Lau, Song Liu, Yonghong Song,
Andrii Nakryiko
Cc: kernel-team, Lorenz Bauer, netdev, bpf, linux-kernel
It's currently possible to insert sockets in unexpected states into
a sockmap, due to a TOCTTOU when updating the map from a syscall.
sock_map_update_elem checks that sk->sk_state == TCP_ESTABLISHED,
locks the socket and then calls sock_map_update_common. At this
point, the socket may have transitioned into another state, and
the earlier assumptions don't hold anymore. Crucially, it's
conceivable (though very unlikely) that a socket has become unhashed.
This breaks the sockmap's assumption that it will get a callback
via sk->sk_prot->unhash.
Fix this by checking the (fixed) sk_type and sk_protocol without the
lock, followed by a locked check of sk_state.
Unfortunately it's not possible to push the check down into
sock_(map|hash)_update_common, since BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB
run before the socket has transitioned from TCP_SYN_RECV into
TCP_ESTABLISHED.
Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>
Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
---
net/core/sock_map.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 8998e356f423..36a2433e183f 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -416,14 +416,16 @@ static int sock_map_update_elem(struct bpf_map *map, void *key,
ret = -EINVAL;
goto out;
}
- if (!sock_map_sk_is_suitable(sk) ||
- sk->sk_state != TCP_ESTABLISHED) {
+ if (!sock_map_sk_is_suitable(sk)) {
ret = -EOPNOTSUPP;
goto out;
}
sock_map_sk_acquire(sk);
- ret = sock_map_update_common(map, idx, sk, flags);
+ if (sk->sk_state != TCP_ESTABLISHED)
+ ret = -EOPNOTSUPP;
+ else
+ ret = sock_map_update_common(map, idx, sk, flags);
sock_map_sk_release(sk);
out:
fput(sock->file);
@@ -739,14 +741,16 @@ static int sock_hash_update_elem(struct bpf_map *map, void *key,
ret = -EINVAL;
goto out;
}
- if (!sock_map_sk_is_suitable(sk) ||
- sk->sk_state != TCP_ESTABLISHED) {
+ if (!sock_map_sk_is_suitable(sk)) {
ret = -EOPNOTSUPP;
goto out;
}
sock_map_sk_acquire(sk);
- ret = sock_hash_update_common(map, key, sk, flags);
+ if (sk->sk_state != TCP_ESTABLISHED)
+ ret = -EOPNOTSUPP;
+ else
+ ret = sock_hash_update_common(map, key, sk, flags);
sock_map_sk_release(sk);
out:
fput(sock->file);
--
2.20.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH bpf] bpf: sockmap: check update requirements after locking
2020-02-07 10:37 [PATCH bpf] bpf: sockmap: check update requirements after locking Lorenz Bauer
@ 2020-02-07 10:56 ` Jakub Sitnicki
2020-02-07 21:50 ` Daniel Borkmann
1 sibling, 0 replies; 3+ messages in thread
From: Jakub Sitnicki @ 2020-02-07 10:56 UTC (permalink / raw)
To: Lorenz Bauer
Cc: John Fastabend, Daniel Borkmann, David S. Miller, Jakub Kicinski,
Alexei Starovoitov, Martin KaFai Lau, Song Liu, Yonghong Song,
Andrii Nakryiko, kernel-team, netdev, bpf, linux-kernel
On Fri, Feb 07, 2020 at 11:37 AM CET, Lorenz Bauer wrote:
> It's currently possible to insert sockets in unexpected states into
> a sockmap, due to a TOCTTOU when updating the map from a syscall.
> sock_map_update_elem checks that sk->sk_state == TCP_ESTABLISHED,
> locks the socket and then calls sock_map_update_common. At this
> point, the socket may have transitioned into another state, and
> the earlier assumptions don't hold anymore. Crucially, it's
> conceivable (though very unlikely) that a socket has become unhashed.
> This breaks the sockmap's assumption that it will get a callback
> via sk->sk_prot->unhash.
>
> Fix this by checking the (fixed) sk_type and sk_protocol without the
> lock, followed by a locked check of sk_state.
>
> Unfortunately it's not possible to push the check down into
> sock_(map|hash)_update_common, since BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB
> run before the socket has transitioned from TCP_SYN_RECV into
> TCP_ESTABLISHED.
>
> Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>
> Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
> ---
> net/core/sock_map.c | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/net/core/sock_map.c b/net/core/sock_map.c
> index 8998e356f423..36a2433e183f 100644
> --- a/net/core/sock_map.c
> +++ b/net/core/sock_map.c
> @@ -416,14 +416,16 @@ static int sock_map_update_elem(struct bpf_map *map, void *key,
> ret = -EINVAL;
> goto out;
> }
> - if (!sock_map_sk_is_suitable(sk) ||
> - sk->sk_state != TCP_ESTABLISHED) {
> + if (!sock_map_sk_is_suitable(sk)) {
> ret = -EOPNOTSUPP;
> goto out;
> }
>
> sock_map_sk_acquire(sk);
> - ret = sock_map_update_common(map, idx, sk, flags);
> + if (sk->sk_state != TCP_ESTABLISHED)
> + ret = -EOPNOTSUPP;
> + else
> + ret = sock_map_update_common(map, idx, sk, flags);
> sock_map_sk_release(sk);
> out:
> fput(sock->file);
> @@ -739,14 +741,16 @@ static int sock_hash_update_elem(struct bpf_map *map, void *key,
> ret = -EINVAL;
> goto out;
> }
> - if (!sock_map_sk_is_suitable(sk) ||
> - sk->sk_state != TCP_ESTABLISHED) {
> + if (!sock_map_sk_is_suitable(sk)) {
> ret = -EOPNOTSUPP;
> goto out;
> }
>
> sock_map_sk_acquire(sk);
> - ret = sock_hash_update_common(map, key, sk, flags);
> + if (sk->sk_state != TCP_ESTABLISHED)
> + ret = -EOPNOTSUPP;
> + else
> + ret = sock_hash_update_common(map, key, sk, flags);
> sock_map_sk_release(sk);
> out:
> fput(sock->file);
> --
> 2.20.1
Thanks for fixing this, Lorenz. I'll adapt socket state checks on update
in "Extend SOCKMAP to store listening sockets" series accordingly.
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH bpf] bpf: sockmap: check update requirements after locking
2020-02-07 10:37 [PATCH bpf] bpf: sockmap: check update requirements after locking Lorenz Bauer
2020-02-07 10:56 ` Jakub Sitnicki
@ 2020-02-07 21:50 ` Daniel Borkmann
1 sibling, 0 replies; 3+ messages in thread
From: Daniel Borkmann @ 2020-02-07 21:50 UTC (permalink / raw)
To: Lorenz Bauer, John Fastabend, David S. Miller, Jakub Kicinski,
Alexei Starovoitov, Martin KaFai Lau, Song Liu, Yonghong Song,
Andrii Nakryiko
Cc: kernel-team, netdev, bpf, linux-kernel
On 2/7/20 11:37 AM, Lorenz Bauer wrote:
> It's currently possible to insert sockets in unexpected states into
> a sockmap, due to a TOCTTOU when updating the map from a syscall.
> sock_map_update_elem checks that sk->sk_state == TCP_ESTABLISHED,
> locks the socket and then calls sock_map_update_common. At this
> point, the socket may have transitioned into another state, and
> the earlier assumptions don't hold anymore. Crucially, it's
> conceivable (though very unlikely) that a socket has become unhashed.
> This breaks the sockmap's assumption that it will get a callback
> via sk->sk_prot->unhash.
>
> Fix this by checking the (fixed) sk_type and sk_protocol without the
> lock, followed by a locked check of sk_state.
>
> Unfortunately it's not possible to push the check down into
> sock_(map|hash)_update_common, since BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB
> run before the socket has transitioned from TCP_SYN_RECV into
> TCP_ESTABLISHED.
>
> Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>
> Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
Applied, thanks!
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-02-07 21:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-07 10:37 [PATCH bpf] bpf: sockmap: check update requirements after locking Lorenz Bauer
2020-02-07 10:56 ` Jakub Sitnicki
2020-02-07 21:50 ` Daniel Borkmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).