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]

Message-ID: <CAL87dS1Cvbxczdyk_2nviC=M2S91bMRKPXrkp1PLHXFuX=CuKg@mail.gmail.com>
Date:   Sun, 13 Nov 2022 18:22:22 +0800
From:   mingkun bian <bianmingkun@...il.com>
To:     netdev@...r.kernel.org
Subject: Re: [ISSUE] suspicious sock leak

Hi,

bpf map1:
key: cookie
value: addr daddr sport dport cookie sock*

bpf map2:
key: sock*
value: addr daddr sport dport cookie sock*

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"


mingkun bian <bianmingkun@...il.com> 于2022年11月12日周六 17:01写道：
>
> Hi,
>     I found a problem that a sock whose state is ESTABLISHED is not
> freed to slab cache by __sock_free.
>     The test scenario is as follows：
>
>     1. A HTTP Server，I insert a node to ebpf
> map(BPF_MAP_TYPE_LRU_HASH) by BPF_MAP_UPDATE_ELEM when receiving a
> "HTTP GET" request in user application.
>     ebpf map is：
>     key: cookie(getsockopt(fd, SOL_SOCKET, SO_COOKIE, &cookie, &optlen))
>     value: saddr sport daddr dport cookie...
>
>     2. I delete the corresponding ebpf map node by "kprobe __sk_free"
> in ebpf as following, bpf_map_delete_elem keeps returning 0.
>
>     SEC("kprobe/__sk_free")
>     int bpf_prog_destroy_sock(struct pt_regs *ctx)
>     {
>         struct sock *sk;
>         __u64 cookie;
>        struct  tcp_infos *value;
>
>        sk = (struct sock *) PT_REGS_PARM1(ctx);
>        bpf_probe_read(&cookie, sizeof(sk->__sk_common.skc_cookie),
> &sk->__sk_common.skc_cookie);
>        value = bpf_map_lookup_elem(&bpfmap, &cookie);
>        if (value) {
>            if (bpf_map_delete_elem(&bpfmap, &cookie) != 0) {
>                debugmsg("delete failed\n");
>            }
>        }
>     }
>
>    3. Sending pressure "HTTP GET" requests to HTTP Server for a while,
>  then stop to send and close the HTTP Server, then wait a long time,
> we can not see any tcpinfo by "netstat -anp", then error occurs：
>     We can see some node which is not deleted int ebpf map by "bpftool
> map dump id **"， it seems like "sock leak", but the sockstat's
> inuse(cat /proc/net/sockstat) does not increase quickly.
>
> 4. I did some more experiments by ebpf kprobe, I find that a
> sock(state is ESTABLISHED, HTTP server recv a "HTTP GET" requset) does
> not come in __sock_free, but the same sock will be reused by another
> tcp connection(the most frequent is "127.0.0.1") after a while.
>    What I doubt is that why a new tcp connection can resue a old sock
> while the old sock does not come in __sk_free.
>
> Thanks.