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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 10 Apr 2014 18:23:35 +0900 From: Lorenzo Colitti <lorenzo@...gle.com> To: Wangyufen <wangyufen@...wei.com> Cc: David Miller <davem@...emloft.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Alexey Kuznetsov <kuznet@....inr.ac.ru> Subject: Re: [PATCH net-next v6 3/3] ipv6: tcp_ipv6 policy route issue On Sat, Mar 29, 2014 at 10:27 AM, Wangyufen <wangyufen@...wei.com> wrote: > The issue raises when adding policy route, specify a particular > NIC as oif, the policy route did not take effect. The reason is > that fl6.oif is not set and route map failed. From the > tcp_v6_send_response function, if the binding address is linklocal, > fl6.oif is set, but not for global address. > > [...] > > fl6.flowi6_proto = IPPROTO_TCP; > - if (ipv6_addr_type(&fl6.daddr) & IPV6_ADDR_LINKLOCAL) > + if (rt6_need_strict(&fl6.daddr) || !oif) > fl6.flowi6_oif = inet6_iif(skb); > + else > + fl6.flowi6_oif = oif; Shouldn't this be && !oif instead of || !oif? It seems to me that the logic should be: 1. If sk->sk_bound_dev_if is set, use that interface. 2. Otherwise, if the connection came from a link-local address, use the incoming interface. 3. Otherwise, use whatever route the system happens to have without special regard to the incoming interface. If so, then I think the code now does the wrong thing in two cases: 1. If the SYN comes from a global address, and sk->sk_bound_dev_if is not set, the SYNACK is forced onto/prefers the interface the SYN came in on instead of just doing a routing lookup with no interface. 2. If the SYN comes from a link-local address, and sk->sk_bound_dev_if is set, then the SYNACK is forced onto/prefers the incoming interface instead of the one specified by sk->sk_bound_dev_if. If I am correct, then I'm happy to send out the trivial patch to fix this. (Against what? net? net-next when the tree reopens?) -- 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