netdev - Fw: [Bug 216680] New: 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>] [day] [month] [year] [list]

Message-ID: <20221111085245.0c0cd18c@hermes.local>
Date:   Fri, 11 Nov 2022 08:52:45 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     netdev@...r.kernel.org
Subject: Fw: [Bug 216680] New: suspicious sock leak

Begin forwarded message:

Date: Fri, 11 Nov 2022 13:59:04 +0000
From: bugzilla-daemon@...nel.org
To: stephen@...workplumber.org
Subject: [Bug 216680] New: suspicious sock leak

https://bugzilla.kernel.org/show_bug.cgi?id=216680

            Bug ID: 216680
           Summary: suspicious sock leak
           Product: Networking
           Version: 2.5
    Kernel Version: 4.18.0
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
          Assignee: stephen@...workplumber.org
          Reporter: bianmingkun@...il.com
        Regression: No

1. A HTTP Server，I will insert a node to ebpf map(BPF_MAP_TYPE_LRU_HASH) by
BPF_MAP_UPDATE_ELEM when receving a "HTTP GET" packet,
ebpf map
key: cookie(by SO_COOKIE)
value: saddr sport daddr dport

2. I will delete the corresponding ebpf map node by "kprobe __sk_free" in ebpf.

3. Sending pressure "HTTP GET" to HTTP Server for a while，then stop sending and
closing 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 by "bpftool map dump id **"， it
seems look like "sock leak", but the sockstat's inuse does not increase
quickly.

4. I did some more experiments by ebpf' kprobe, I find that a sock* does not
come int __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

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.