netdev - Re: [PATCH net-next v6 3/3] ipv6: tcp

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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