netdev - Re: loopback device reference count leakage

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 8 Feb 2017 13:50:57 -0800
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Kaiwen Xu <kevin@...xu.net>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: loopback device reference count leakage

On Mon, Feb 6, 2017 at 6:32 PM, Kaiwen Xu <kevin@...xu.net> wrote:
> Hi Cong,
>
> I did some more testing, seems like your second assumption is correct.
> There is indeed some things holding the references to a particular dst
> which preventing it to be gc'ed.

Excellent!

>
> I added logging to each dst_hold (or dst_hold_safe, or
> skb_dst_force_safe) and dst_release, which formatted as following:
>
> <dev name> (<protocol>) [<dst addr>]: dst_release / dst_hold ... <refcnt> <caller function>
>
> And inside dst_gc_task(), I added logging when gc delay occurred,
> formatted as:
>
> [dst_gc_task] <dev name> (<protocol>): delayed <refcnt>
>
> I have the log attached.

The following line looks suspicious:

Feb  6 16:27:24 <hostname> kernel: [63589.458067] [dst_gc_task]
lodebug (2): delayed 19

Looks like you ended up having one dst whose refcnt is 19 in GC,
and this lasted for a rather long time for some reason.

It is hard to know if it is a refcnt leak even with your log, since there were
4K+ refcnt'ing happened on that dst...

Meanwhile, can you share your setup of your container? What network device
do you use in your container? How is it connected to outside?

Thanks.