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:   Tue, 18 Feb 2020 09:08:54 +0100
From:   Rafał Miłecki <zajec5@...il.com>
To:     Network Development <netdev@...r.kernel.org>,
        Hangbin Liu <liuhangbin@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Cc:     Felix Fietkau <nbd@....name>, John Crispin <john@...ozen.org>,
        Jo-Philipp Wich <jo@...n.io>
Subject: Re: Regression: net/ipv6/mld running system out of memory (not a leak)

On Wed, 12 Feb 2020 at 08:37, Rafał Miłecki <zajec5@...il.com> wrote:
> I run Linux based OpenWrt distribution on home wireless devices (ARM
> routers and access points with brcmfmac wireless driver). I noticed
> that using wireless monitor mode interface results in my devices (128
> MiB RAM) running out of memory in about 2 days. This is NOT a memory
> leak as putting wireless down brings back all the memory.
>
> Interestingly this memory drain requires at least one of:
> net.ipv6.conf.default.forwarding=1
> net.ipv6.conf.all.forwarding=1
> to be set. OpenWrt happens to use both by default.
>
> This regression was introduced by the commit 1666d49e1d41 ("mld: do
> not remove mld souce list info when set link down") - first appeared
> in 4.10 and then backported. This bug exists in 4.9.14 and 4.14.169.
> Reverting that commit from 4.9.14 and 4.14.169 /fixes/ the problem.

Thinking about meaning of that commit ("do not remove mld souce list
info when set link down") made me realize one more thing.

My app accessing monitor mode brings it up and down repeatedly:
while (1) {
  ifconfig X up (ifr_flags |= IFF_UP | IFF_RUNNING)
  select(...)
  recv(...)
  ifconfig X down (ifr_flags &= ~(IFF_UP | IFF_RUNNING))
  sleep(...)
}

So maybe that bug running device out of memory was there since ever?
Maybe before 1666d49e1d41 ("mld: do not remove mld souce list info
when set link down") I just didn't notice it as every "ifconfig X
down" was flushing list. Flushing it every few seconds didn't let list
grow too big and eat all my memory?

I'm going to test some old kernel now using monitor mode all time,
without putting its interface down. Is there some of debugging
mld/ipv6 kernel lists to see if there are indeed growing huge?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ