linux-kernel - Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

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, 16 Jan 2018 07:31:51 -0800
From:   Kevin Cernekee <cernekee@...omium.org>
To:     Sebastian Gottschall <s.gottschall@...wrt.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable <stable@...r.kernel.org>,
        Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

On Tue, Jan 16, 2018 at 1:18 AM, Sebastian Gottschall
<s.gottschall@...wrt.com> wrote:
>
>> According to my understanding of igmpv3_newpack(), the destination
>> address should always be IGMPV3_ALL_MCR = 224.0.0.22.  That is what I
>> see in my testing.
>>
>> However, your packet trace says 239.35.100.8.  I don't know how the
>> code that we touched would be generating an IGMPv2 packet with that
>> destination address.
>
> easy answer from wikipedia. 224.0.x.x is not the only multicast block

AFAICT the code that was changed by this patch should not have
anything to do with other multicast blocks.  It generates an IGMPv3
report with destination address 224.0.0.22.  So it would be useful to
get more information on how exactly it is causing a failure, so we can
find the root cause.

>> Would it be possible to get a stack trace for the case where the
>> source address is being cleared to 0.0.0.0 in your configuration?
>
> you mean something like dumpstack and watching the flood comes over me?

I would just add something like this into my local tree for testing:

WARN_ON_ONCE(pip->saddr == htonl(INADDR_ANY));