You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
bpf, sockmap: avoid using sk_socket after free when reading
There are potential concurrency issues, as shown below.
'''
CPU0 CPU1
sk_psock_verdict_data_ready:
socket *sock = sk->sk_socket
if (!sock) return
close(fd):
...
ops->release()
if (!sock->ops) return
sock->ops = NULL
rcu_call(sock)
free(sock)
READ_ONCE(sock->ops)
^
use 'sock' after free
'''
RCU is not applicable to Unix sockets read path, because the Unix socket
implementation itself assumes it's always in process context and heavily
uses mutex_lock, so, we can't call read_skb within rcu lock.
Incrementing the psock reference count would not help either, since
sock_map_close() does not wait for data_ready() to complete its execution.
While we don't utilize sk_socket here, implementing read_skb at the sock
layer instead of socket layer might be architecturally preferable ?
However, deferring this optimization as current fix adequately addresses
the immediate issue.
Fixes: c638291 ("af_unix: Implement ->psock_update_sk_prot()")
Reported-by: [email protected]
Closes: https://lore.kernel.org/bpf/[email protected]/
Signed-off-by: Jiayuan Chen <[email protected]>
0 commit comments