netdev - Re: [PATCH V2] IPv6 : add multicast routing verify which net

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]

Message-ID: <4EF1A061.5030005@cn.fujitsu.com>
Date:	Wed, 21 Dec 2011 17:01:21 +0800
From:	Wang Xingtong <wangxingtong@...fujitsu.com>
To:	David Miller <davem@...emloft.net>
CC:	gaofeng@...fujitsu.com, netdev@...r.kernel.org
Subject: Re: [PATCH V2] IPv6 : add multicast routing verify which net_device
 is lo


> From: Gao feng <gaofeng@...fujitsu.com>
> Date: Tue, 20 Dec 2011 19:10:24 +0800
> 
>> In currently routing subsystem, when we lookup a multicast routing
>> to send muticast packets to outside, rt6_device_match will return
>> the rt6_info which it's match first. If we add a multicast route on
>> loopback devices beforce the others interface, rt6_device_match will
>> retrun the rt6_info which rt6i_dev->name is "lo". But, obviously,
>> we can't send a muticast packet to outside using loopback devices.
>> It case all multicast packets blocking.
>>
>> Commit 4af04aba93f47699e disabled kernel add multicast route on lo
>> automatically. However,  we can't surmise the routing-add order or
>> interdict add multicast routing on loopback devices in user space.
>> The bug still exist. So, i think, more stronger routing subsystem is
>> necessary.
>>
>> Signed-off-by: Wang xingtong <wangxingtong@...fujitsu.com>
> 
> Ok, this is getting rediculious.  I want to revert all of this
> stuff.
> 
> How about, instead, we stop userland adding explicit addresses to the
> loopback device since that's what started behaving differently
> recently and causes these problems in the first place?

OK, David, I reproduce this as following :

1) ip -6 route show | grep ff00
    unreachable ff00::/8 dev lo  metric 1024  error -101
    ff00::/8 dev eth1  metric 1024

2) ip -6 route del ff00::/8 dev eth1
    ip -6 route del ff00::/8 dev lo

3) ip -6 route add ff00::/8 dev lo
    ip -6 route add ff00::/8 dev eth1

now, if we join to the multicast group with the interface index is 
specified as 0, not restrict devices( oif == 0 ), not restrict saddr ( 
saddr == :: ), rt6_device_match  will return rt6_info which 
rt6i_dev->name is "lo" all the while, and rt6i_dev->error is
"-ENETUNREACH".  we got "ENODEV" at userspace,  all multicast packets 
will be blocked .

But, in fact, eth1 can be uesd and we missed. This is a bug in routing 
system， isn't it？

This patch add multicast routing check-up in rt6_device_match to arrest
it return loopback device when we isn't specified interface and saddr.

thanks,

wang xingtong







--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html