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]
Message-ID: <CAL87dS2XjE2f0+HJ4DH4zzQwz1K-LYQx0rV0t=sbs343pxar2Q@mail.gmail.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ