netdev - Re: [ISSUE] suspicious sock leak

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 13 Nov 2022 17:25:20 -0800
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     mingkun bian <bianmingkun@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [ISSUE] suspicious sock leak

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.