netdev - Re: ipv4: broadcast sometimes leaves wrong interface (since commit e066008b38ca9ace1b6de8dbbac8ed460640791d)

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:	Wed, 30 Nov 2011 01:06:46 +0200 (EET)
From:	Julian Anastasov <ja@....bg>
To:	Jeroen van Ingen <jeroen@...ndomein.nl>
cc:	netdev@...r.kernel.org
Subject: Re: ipv4: broadcast sometimes leaves wrong interface (since commit
 e066008b38ca9ace1b6de8dbbac8ed460640791d)


	Hello,

On Tue, 29 Nov 2011, Jeroen van Ingen wrote:

> Hi,
> 
> We're having an issue on our Linux PPTP servers. After the first PPTP
> client is connected, locally generated broadcast packets go out the ppp0
> interface while the routing rules should select eth0.
> 
> Some details were already mentioned on the linux-kernel list, see eg
> http://lkml.indiana.edu/hypermail/linux/kernel/1111.2/00290.html for
> reference.
> 
> Finally we were able to narrow it down to one specific commit:
> e066008b38ca9ace1b6de8dbbac8ed460640791d ("ipv4: Fix __ip_dev_find() to
> use ifa_local instead of ifa_address."). With all recent kernels (tested
> up to 3.2.0rc3) we observe this issue and it's solved by reverting this
> single patch.
> 
> This is the first time we've had to debug a kernel issue. Any advice on
> how to proceed would be very welcome. If it's not possible to have this
> patch reverted in the kernel, hopefully someone can explain how to work
> around this behavior.

	__ip_dev_find can cause problem if same IP is added on many
interfaces because it uses hash table implemented with hlist.
Old versions used only routing lookup and the routing returns
the first created local route, i.e. the first device where this
IP was added is returned.

	And now it is risky to use __ip_dev_find in
ip_route_output_slow when:

- saddr is provided
- desired oif is 0
- daddr is multicast/lbcast

	We select oif by ignoring route ordering. May be some
ppp device wins here because it has this saddr added last but
is first in hlist.

	What is the case after first client is connected, can
you show output from:

ip addr show
ip route list table local

	If the above is true may be we have to find a
way to return the first device where the IP is added.
May be this is the main rule that is used when one adds
same IP on many interfaces.

	May be the solution is to convert inet_addr_lst
from hlist to normal list, so that we can append new
addresses at tail and __ip_dev_find to find the first
device where IP was added.

Regards

--
Julian Anastasov <ja@....bg>
--
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