netdev - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 9 Mar 2020 13:31:16 +0100
From:   Rafał Miłecki <zajec5@...il.com>
To:     Hangbin Liu <liuhangbin@...il.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        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 09.03.2020 09:33, Hangbin Liu wrote:
> I'm very appreciate for your analyze. This makes me know why this issue
> happens and why I couldn't reproduce it.
> 
> Yes, with ARPHRD_IEEE80211_RADIOTAP, we called mld_add_delrec() every time
> when ipv6_mc_down(), but we never called mld_del_delrec() as ipv6_mc_up() was
> not called. This makes the idev->mc_tomb bigger and bigger.

Thanks, I'm happy to hear that was helpful.


>> *****************
>>   WITH YOUR PATCH
>> *****************
>>
>> Things work OK - with your changes all calls like:
>> ipv6_dev_mc_inc(ff01::1)
>> ipv6_dev_mc_inc(ff02::1)
>> ipv6_dev_mc_inc(ff02::2)
>> are now part of ipv6_mc_up() which gets never called for the
>> ARPHRD_IEEE80211_RADIOTAP.
>>
>> I got one more question though:
>>
>> Should we really call ipv6_mc_down() for ARPHRD_IEEE80211_RADIOTAP?
>>
>> We don't call ipv6_mc_up() so maybe ipv6_mc_down() should be avoided
>> too? It seems like asking for more problems in the future. Even now
> 
> 
> Yes, for me there are actually two questions.
> 
> 1. Should we avoid call ipv6_mc_down() as we don't call ipv6_mc_up() for
> non-Ethernen dev. I think the answer is yes, we could. But on the
> other hand, it seems IPv4 doesn't check the dev type and calls ip_mc_up()
> directly in inetdev_event() NETDEV_UP.
> 
> 2. Should we move ipv6_dev_mc_inc() from ipv6_add_dev() to ipv6_mc_up()?
> I don't know yet, this dependents on whether we could add multicast address
> on non-Ethernen dev.

I'm not the one to answer them surely with my limited net subsystem
understanding :( Any idea how to proceed with this? I assume your patch
is still the right step, do you think you can send it officially now?


>> we call ipv6_mc_leave_localaddr() without ipv6_mc_join_localaddr()
>> called first which seems unintuitive.
> 
> This doesn't matter much yet. As we will check if we have the address
> in __ipv6_dev_mc_dec(), if not, we just return. But yes, form logic, this
> looks asymmetric.

Right, just slightly unintuitive asymmetric code.