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: <alpine.LFD.2.11.1404091027460.1435@ja.home.ssi.bg> Date: Wed, 9 Apr 2014 11:03:31 +0300 (EEST) From: Julian Anastasov <ja@....bg> To: Cong Wang <xiyou.wangcong@...il.com> cc: David Miller <davem@...emloft.net>, Linux Kernel Network Developers <netdev@...r.kernel.org>, "Eric W. Biederman" <ebiederm@...ssion.com>, Cong Wang <cwang@...pensource.com> Subject: Re: [Patch net] ipv4: fib: check forwarding before checking send_redirects Hello, On Tue, 8 Apr 2014, Cong Wang wrote: > > Yes, the code will fail if input route is > > tried on loopback device. My first thought was that > > you forgot to 'ip route flush cache' after clearing > > rp_filter. > > > > route cache is removed after 3.6, so I don't need to do it? route cache is now FIB cache :) My 'ip' tool still does open("/proc/sys/net/ipv4/route/flush", O_WRONLY) = 4 write(4, "-1", 2) = 2 close(4) = 0 Which invalidates the FIB cache: ipv4_sysctl_rtcache_flush -> rt_cache_flush, fnhe_genid_bump The change is noticed via rt_cache_valid and rt_is_expired. > > What kind of packet is that and why the skb lost its > > output route and now it is trying for input route? > > > > Yeah, I just noticed that for normal loopback packets its ->dst > are forced to be kept so that it will not need to lookup route > again on rx. However, in our case, we redirect the packets > from veth0 to lo when src_addr == dst_addr, its ->dst is dropped > after coming out of the network namespace, therefore goes into > the slow path to validate the reverse path and lookup the route. I'm still not sure that it is valid to process input route on loopback device. There is also a case of broadcasts/multicasts that should preserve their local output route while being looped in ip_mc_output(). In this case device is not loopback. I need more time to check the code again... > I think David's point is still valid in this case, __fib_validate_source() > should not reject the packets. So hmm... the only reason I can find is > the following code: > > if (fib_lookup(net, &fl4, &res) == 0) { > if (res.type == RTN_UNICAST) > ret = FIB_RES_NH(res).nh_scope >= RT_SCOPE_HOST; > } I think fib_validate_source is called with oif=LOOPBACK_IFINDEX and dev/idev=lo for skb without route, that is the problem. In this case fib_validate_source thinks this is forwarding from lo to lo. So, there is a reason your patch fixes the problem, alternative is to add oif == LOOPBACK_IFINDEX check: dev->ifindex != oif || !IN_DEV_TX_REDIRECTS(idev) || oif == LOOPBACK_IFINDEX > where its nh_scope == RT_SCOPE_HOST? The idea is to avoid calling __fib_validate_source, right? No need to look into __fib_validate_source. Also, I'm not sure how legal is to receive packets on lo without skb->dst... 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
Powered by blists - more mailing lists