summaryrefslogtreecommitdiff
path: root/include/net
diff options
context:
space:
mode:
authorStephen Suryaputra Lin <stephen.suryaputra.lin@gmail.com>2016-11-10 19:16:15 +0300
committerJiri Slaby <jslaby@suse.cz>2016-11-29 00:22:40 +0300
commit75ed3f35930e79bcb1a5e61d0520953fea3e30a2 (patch)
tree345c243186f489afa40651df1606b93ab86cba3a /include/net
parent34a6fca3d0eb6b8bdedd38ac463dc161ca6979f6 (diff)
downloadlinux-75ed3f35930e79bcb1a5e61d0520953fea3e30a2.tar.xz
ipv4: use new_gw for redirect neigh lookup
[ Upstream commit 969447f226b451c453ddc83cac6144eaeac6f2e3 ] In v2.6, ip_rt_redirect() calls arp_bind_neighbour() which returns 0 and then the state of the neigh for the new_gw is checked. If the state isn't valid then the redirected route is deleted. This behavior is maintained up to v3.5.7 by check_peer_redirect() because rt->rt_gateway is assigned to peer->redirect_learned.a4 before calling ipv4_neigh_lookup(). After commit 5943634fc559 ("ipv4: Maintain redirect and PMTU info in struct rtable again."), ipv4_neigh_lookup() is performed without the rt_gateway assigned to the new_gw. In the case when rt_gateway (old_gw) isn't zero, the function uses it as the key. The neigh is most likely valid since the old_gw is the one that sends the ICMP redirect message. Then the new_gw is assigned to fib_nh_exception. The problem is: the new_gw ARP may never gets resolved and the traffic is blackholed. So, use the new_gw for neigh lookup. Changes from v1: - use __ipv4_neigh_lookup instead (per Eric Dumazet). Fixes: 5943634fc559 ("ipv4: Maintain redirect and PMTU info in struct rtable again.") Signed-off-by: Stephen Suryaputra Lin <ssurya@ieee.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Diffstat (limited to 'include/net')
0 files changed, 0 insertions, 0 deletions