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:   Mon, 14 Nov 2022 13:39:18 +0800
From:   mingkun bian <bianmingkun@...il.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [ISSUE] suspicious sock leak

Cong Wang <xiyou.wangcong@...il.com> 于2022年11月14日周一 09:25写道：
>
> 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.

Hi,

I do not use sockmap in this scenario.

Traffic model is about 20Gbps external traffic and 80Gbps lo traffic,
only external traffic can insert bpf map.
The old sock will be reused only if the old sock exec "__sock_free"
whether  referenced or not by the kernel, but my test result is not
so.
And TIME_WAIT state still release the sock immediately， then create
tcp_timewait_sock instead of sock in function 'tcp_time_wait'.

My kernel is 4.18.0.

Thanks.