• J
    bpf: Sockmap/tls, during free we may call tcp_bpf_unhash() in loop · 4da6a196
    John Fastabend 提交于
    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: 5d92e631 ("net/tls: partially revert fix transition through disconnect with close")
    Reported-by: syzbot+83979935eb6304f8cd46@syzkaller.appspotmail.com
    Signed-off-by: NJohn Fastabend <john.fastabend@gmail.com>
    Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
    Reviewed-by: NJakub Sitnicki <jakub@cloudflare.com>
    Acked-by: NSong Liu <songliubraving@fb.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/bpf/20200111061206.8028-2-john.fastabend@gmail.com
    4da6a196
skmsg.h 10.8 KB