Re: [ISSUE] suspicious sock leak

[Cong Wang <xiyou.wangcong@gmail.com>]

On Sun, Nov 13, 2022 at 06:22:22PM +0800, mingkun bian wrote:
> Hi,
> 
> bpf map1:
> key: cookie
> value: addr daddr sport dport cookie sock*
> 
> bpf map2:
> key: sock*
> value: addr daddr sport dport cookie sock*

So none of them is sockmap? Why not use sockmap which takes care
of sock refcnt for you?

> 
> 1. Recv a "HTTP GET" request in user applicatoin
> map1.insert(cookie, value)
> map2.insert(sock*, value)
> 
> 1. kprobe inet_csk_destroy_sock:
> sk->sk_wmem_queued is 0
> sk->sk_wmem_alloc is 4201
> sk->sk_refcnt is 2
> sk->__sk_common.skc_cookie is 173585924
> saddr daddr sport dport is 192.168.10.x 80
> 
> 2. kprobe __sk_free
> can not find the "saddr daddr sport dport 192.168.10.x 80" in kprobe __sk_free
> 
> 3. kprobe __sk_free
> after a while, "kprobe __sk_free" find the "saddr daddr sport dport
> 127.0.0.1 xx"' info
> value = map2.find(sock*)
> value1 = map1.find(sock->cookie)
> if (value) {
>     map2.delete(sock) //print value info, find "saddr daddr sport
> dport" is "192.168.10.x 80“， and value->cookie is 173585924, which is
> the same as "192.168.10.x 80" 's cookie.
> }
> 
> if (value1) {
>     map1.delete(sock->cookie)
> }
> 
> Here is my test flow, commented lines represents that  sock of ”saddr
> daddr sport dport 192.168.10.x 80“ does not come in  __sk_free， but it
> is reused by ” saddr daddr sport dport 127.0.0.1 xx"

I don't see this is a problem yet, the struct sock may be still referenced
by the kernel even after you close its corresponding struct socket from
user-space. And TCP sockets have timewait too, so...

I suggest you try sockmap to store sockets instead.

Thanks.