• Daniel Borkmann's avatar
    bpf, sockmap: fix map elem deletion race with smap_stop_sock · 166ab6f0
    Daniel Borkmann authored
    The smap_start_sock() and smap_stop_sock() are each protected under
    the sock->sk_callback_lock from their call-sites except in the case
    of sock_map_delete_elem() where we drop the old socket from the map
    slot. This is racy because the same sock could be part of multiple
    sock maps, so we run smap_stop_sock() in parallel, and given at that
    point psock->strp_enabled might be true on both CPUs, we might for
    example wrongly restore the sk->sk_data_ready / sk->sk_write_space.
    Therefore, hold the sock->sk_callback_lock as well on delete. Looks
    like 2f857d04 ("bpf: sockmap, remove STRPARSER map_flags and add
    multi-map support") had this right, but later on e9db4ef6 ("bpf:
    sockhash fix omitted bucket lock in sock_close") removed it again
    from delete leaving this smap_stop_sock() instance unprotected.
    
    Fixes: e9db4ef6 ("bpf: sockhash fix omitted bucket lock in sock_close")
    Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
    Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
    Acked-by: default avatarSong Liu <songliubraving@fb.com>
    Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
    166ab6f0
sockmap.c 59.5 KB