| 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
| ||
|
Message-ID: <20120531174641.2809b5c4@nehalam.linuxnetplumber.net>
Date: Thu, 31 May 2012 17:46:41 -0700
From: Stephen Hemminger <shemminger@...tta.com>
To: netdev@...r.kernel.org
Subject: Fw: [Bug 43327] New: IP routing: cached route is applied to wrong
network interface
Begin forwarded message:
Date: Fri, 1 Jun 2012 00:18:37 +0000 (UTC)
From: bugzilla-daemon@...zilla.kernel.org
To: shemminger@...ux-foundation.org
Subject: [Bug 43327] New: IP routing: cached route is applied to wrong network interface
https://bugzilla.kernel.org/show_bug.cgi?id=43327
Summary: IP routing: cached route is applied to wrong network
interface
Product: Networking
Version: 2.5
Kernel Version: 3.1.10
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: shemminger@...ux-foundation.org
ReportedBy: dschnabel@...neta.com
Regression: No
IP routing: cached route is applied to wrong network interface
Dynamic route changes like ICMP redirects are cached in the cache routing table
of the kernel. This cache table can be displayed using the command "route -nC"
or "ip route show cache".
Routes in this table are used before checking the Routing Policy Database
(RPDB). In a certain use case a wrong route entry is created in the cache
table.
This is my network setup:
* the Linux machine has 2 network interfaces (eth0 and eth1) with IP adresses
of different subnets
** eth0: 172.16.124.217/24 (Subnet A)
** eth1: 172.16.128.219/24 (Subnet B)
* IP rules to accomplish two default gateways
** root@...ox:~# ip rule show
0: from all lookup local
32764: from 172.16.128.219 lookup E1
32765: from 172.16.124.217 lookup E0
32766: from all lookup main
32767: from all lookup default
** root@...ox:~# ip route show table E0
default via 172.16.124.254 dev eth0
** root@...ox:~# ip route show table E1
default via 172.16.128.254 dev eth1
* Both gateways are connected to Subnet C
This is how it looks like:
************
# ************
* Subnet A *
# * Subnet C *
************ +-------------------+ +-------------------+
# ************
| | | |
#
+-------------------+ GW 172.16.124.254 +------+ GW 172.16.124.18
+------#---------------+
| 172.16.124.217 | | | |
# |
+------+--------+ +-------------------+ +---------+---------+
# |
| eth0 | |
# +--------+----------+
| | |
# | Target |
| Linux Machine | ##################
# | IP 10.20.2.252 |
| | |
# +--------+----------+
| eth1 | |
#
+------+--------+ +-------------------+ |
#
| 172.16.128.219 | | |
#
+-------------------+ GW 172.16.128.254 +----------------+
#
| |
#
************ +-------------------+
#
* Subnet B *
#
************
#
I can ping the target from both interfaces:
ping 10.20.2.252 -I 172.16.124.217
ping 10.20.2.252 -I 172.16.128.219
When pining from eth0 (172.16.124.217) the Gateway 172.16.124.254 will return a
redirect to Gateway 172.16.124.18 since it's in the same network:
root@...ox:~# ping 10.20.2.252 -I 172.16.124.217
PING 10.20.2.252 (10.20.2.252) from 172.16.124.217 : 56(84) bytes of data.
64 bytes from 10.20.2.252: icmp_seq=1 ttl=63 time=81.4 ms
>From 172.16.124.254: icmp_seq=1 Redirect Host(New nexthop: 172.16.124.18)
64 bytes from 10.20.2.252: icmp_seq=2 ttl=63 time=0.277 ms
64 bytes from 10.20.2.252: icmp_seq=3 ttl=63 time=0.238 ms
64 bytes from 10.20.2.252: icmp_seq=4 ttl=63 time=0.236 ms
And this redirect will create a new entry in the cache table:
root@...ox:~# route -nC | grep 172.16.124.18
172.16.124.217 10.20.2.252 172.16.124.18 0 0 2 eth0
So far so good. Here comes the problem.
When I ping the same target now from eth1 (172.16.128.219) then it won't work
anymore:
root@...ox:~# ping 10.20.2.252 -I 172.16.128.219
PING 10.20.2.252 (10.20.2.252) from 172.16.128.219 : 56(84) bytes of data.
>From 172.16.128.219 icmp_seq=2 Destination Host Unreachable
>From 172.16.128.219 icmp_seq=3 Destination Host Unreachable
>From 172.16.128.219 icmp_seq=4 Destination Host Unreachable
^C
--- 10.20.2.252 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2999ms
I check the cache table and notice another entry:
root@...twell19:~# route -nC | grep 172.16.124.18
172.16.124.217 10.20.2.252 172.16.124.18 0 0 2 eth0
172.16.128.219 10.20.2.252 172.16.124.18 0 0 7 eth1
That means eth1 is now trying to reach 10.20.2.252 using the gateway
172.16.124.18. It's obvious that this won't work since eth1 is in a different
subnet.
So the entry in the cache table is wrong. After clearing the cache with "ip
route flush table cache" the ping from eth1 works again.
I did some research:
The cache routing table works on an AVL tree of Internet Peers. Those peers are
stored in a structure called inet_peer (include/net/inetpeer.h). A lookup is
done by the call to inet_getpeer_v4() in net/ipv4/route.c which takes the
destination address (10.20.2.252 in my case) as the first argument. So if the
destination address matches then the peer is returned and saved to the cache
table regardless of the source address.
Two possible fixes I can think of:
* A peer lookup should be done not only by the destination address but also by
the source address (or netmask)
* The inet_peer structure should contain a field for the source address (or
netmask). Then after lookup via inet_getpeer_v4() check the source address (or
netmask) of the returned peer.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
--
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
Powered by blists - more mailing lists