Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

2016-11-15 Thread David Ahern
On 11/15/16 7:45 AM, Hannes Frederic Sowa wrote: >> @@ -1012,6 +1013,16 @@ static int ip6_dst_lookup_tail(struct net *net, >> const struct sock *sk, >> } >> #endif >> >> +addr_type = ipv6_addr_type(>saddr); >> +if (addr_type == IPv6_ADDR_ANY) >> +return

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

2016-11-15 Thread Hannes Frederic Sowa
Hey Jason, On 15.11.2016 01:45, Jason A. Donenfeld wrote: > I'll have a better look at this. Perhaps this should be modeled on > what we currently do for userspace, which might amount to something > more or less like: Cool, thanks! > diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c >

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

2016-11-14 Thread Jason A. Donenfeld
Hey Hannes, David, On Mon, Nov 14, 2016 at 7:33 PM, Hannes Frederic Sowa wrote: > I meant to say, we don't require the IPv6 "API" to behave in a similar > way like the IPv4 one. We do this function pointer trick to allow > _in-kernel_ tree modules to use the function

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

2016-11-14 Thread Hannes Frederic Sowa
On Mon, Nov 14, 2016, at 18:48, David Ahern wrote: > On 11/14/16 10:33 AM, Hannes Frederic Sowa wrote: > > I just also quickly read up on the history (sorry was travelling last > > week) and wonder if you ever saw a user space facing bug or if this is > > basically some difference you

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

2016-11-14 Thread David Ahern
On 11/14/16 10:33 AM, Hannes Frederic Sowa wrote: > I just also quickly read up on the history (sorry was travelling last > week) and wonder if you ever saw a user space facing bug or if this is > basically some difference you saw while writing out of tree code? I checked the

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

2016-11-14 Thread Hannes Frederic Sowa
On 14.11.2016 18:17, David Ahern wrote: > On 11/14/16 10:04 AM, Hannes Frederic Sowa wrote: >> On 14.11.2016 17:55, David Ahern wrote: >>> On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote: On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote: > This puts the IPv6 routing functions in

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

2016-11-14 Thread David Ahern
On 11/14/16 10:04 AM, Hannes Frederic Sowa wrote: > On 14.11.2016 17:55, David Ahern wrote: >> On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote: >>> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote: This puts the IPv6 routing functions in parity with the IPv4 routing functions.

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

2016-11-14 Thread Hannes Frederic Sowa
On 14.11.2016 17:55, David Ahern wrote: > On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote: >> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote: >>> This puts the IPv6 routing functions in parity with the IPv4 routing >>> functions. Namely, we now check in v6 that if a flowi6 requests an

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

2016-11-14 Thread David Ahern
On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote: > On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote: >> This puts the IPv6 routing functions in parity with the IPv4 routing >> functions. Namely, we now check in v6 that if a flowi6 requests an >> saddr, the returned dst actually corresponds

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

2016-11-14 Thread Hannes Frederic Sowa
On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote: > This puts the IPv6 routing functions in parity with the IPv4 routing > functions. Namely, we now check in v6 that if a flowi6 requests an > saddr, the returned dst actually corresponds to a net device that has > that saddr. This mirrors

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

2016-11-14 Thread David Ahern
On 11/13/16 4:28 PM, Jason A. Donenfeld wrote: > This puts the IPv6 routing functions in parity with the IPv4 routing > functions. Namely, we now check in v6 that if a flowi6 requests an > saddr, the returned dst actually corresponds to a net device that has > that saddr. This mirrors the v4 logic

[PATCH v3] ip6_output: ensure flow saddr actually belongs to device

2016-11-13 Thread Jason A. Donenfeld
This puts the IPv6 routing functions in parity with the IPv4 routing functions. Namely, we now check in v6 that if a flowi6 requests an saddr, the returned dst actually corresponds to a net device that has that saddr. This mirrors the v4 logic with __ip_dev_find in __ip_route_output_key_hash. In