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 05:44:19 +0100
From:   Sebastian Gottschall <s.gottschall@...wrt.com>
To:     Kevin Cernekee <cernekee@...omium.org>
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

Am 16.01.2018 um 05:32 schrieb Kevin Cernekee:
> On Mon, Jan 15, 2018 at 8:26 PM, Sebastian Gottschall
> <s.gottschall@...wrt.com> wrote:
>> havent check the source addresses right now. i basicly discovered that this
>> patch breaks the igmp routing and all traffic stops
>> this here is from a working system with the reverted patch. if you really
>> need that i break it again using the patch you need to wait a little bit
>>
>> 05:14:22.697962 IP 10.88.195.138 > 239.35.100.8: igmp v2 report 239.35.100.8
> The patch should only affect IGMPv3 behavior.  I did not intend to
> change IGMPv2 behavior.  If it does, that might be a bug.
it does change the behaviour indeed. i dont know the reason. but i while 
discovering the issue on 4.14 last week and newly on 4.9 this week while 
testing
(my latest firmware i builded was from 30. december and worked) i got 
tracked it down to this small patch and it immediatly worked after 
reverting it
> Is it possible that the kernel is using a source IP of 0.0.0.0, but
> another host does not recognize it because it does not comply with RFC
> 3376?
this is possible yes, but i cannot look into the "deutsche telekom" host
>
> Before/after packet traces would be the best way to see if the kernel
> change is causing it to violate the standard.
let me just take a look into our patch
+ for_ifa(in_dev) {
+ if (inet_ifa_match(fl4->saddr, ifa))
+ return fl4->saddr;
+ } endfor_ifa(in_dev);
this looks like you're checking if the source address matches to a local 
interface, if not you return 0.0.0.0 instead of the source address

(193.158.35.251, 239.35.20.4)    Iif: ppp0       Oifs: briptv

our first source address here 193.158.35.251 is from a remote network. 
so your patch also will change the behaviour since the source address 
will get ignored
>

-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@...wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565