netdev - Regression: net/ipv6/mld running system out of memory (not a 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-next>] [day] [month] [year] [list]

Message-ID: <CACna6rwD_tnYagOPs2i=1jOJhnzS5ueiQSpMf23TdTycFtwOYQ@mail.gmail.com>
Date:   Wed, 12 Feb 2020 08:37:31 +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: Regression: net/ipv6/mld running system out of memory (not a leak)

Hi, I need some help with my devices running out of memory. I've
debugging skills but I don't know net subsystem.

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.

Can you look at possible cause/fix of this problem, please? Is there
anything I can test or is there more info I can provide?

I'm not sure why this issue appears only when using monitor mode.
Using wireless __ap mode interface (with hostapd) won't expose this
issue. I guess it may be a matter of monitor interfaces not being
bridged?

-- 
Rafał