[PATCH V2] ipv6: handle Redirect ICMP Message with no Redirected Header option

[PATCH V2] ipv6: handle Redirect ICMP Message with no Redirected Header option

[Duan Jiong]

From: Duan Jiong <duanj.fnst@cn.fujitsu.com>

rfc 4861 says the Redirected Header option is optional, so
the kernel should not drop the Redirect Message that has no
Redirected Header option. In this patch, the function
ip6_redirect_no_header() is introduced to deal with that
condition.

Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
 include/net/ip6_route.h |    2 ++
 net/ipv6/ndisc.c        |    4 +++-
 net/ipv6/route.c        |   22 ++++++++++++++++++++++
 3 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index 260f83f..f667248 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -135,6 +135,8 @@ extern void ip6_update_pmtu(struct sk_buff *skb, struct net *net, __be32 mtu,
 extern void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk,
 			       __be32 mtu);
 extern void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark);
+extern void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif,
+				   u32 mark);
 extern void ip6_sk_redirect(struct sk_buff *skb, struct sock *sk);
 
 struct netlink_callback;
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 79aa965..04d31c2 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1369,8 +1369,10 @@ static void ndisc_redirect_rcv(struct sk_buff *skb)
 	if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts))
 		return;
 
-	if (!ndopts.nd_opts_rh)
+	if (!ndopts.nd_opts_rh) {
+		ip6_redirect_no_header(skb, dev_net(skb->dev), 0, 0);
 		return;
+	}
 
 	hdr = (u8 *)ndopts.nd_opts_rh;
 	hdr += 8;
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index b70f897..6b17833 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1178,6 +1178,28 @@ void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark)
 }
 EXPORT_SYMBOL_GPL(ip6_redirect);
 
+void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif,
+			    u32 mark)
+{
+	const struct ipv6hdr *iph = (struct ipv6hdr *)skb_network_header(skb);
+	const struct rd_msg *msg = (struct rd_msg *)skb_transport_header(skb);
+	struct dst_entry *dst;
+	struct flowi6 fl6;
+
+	memset(&fl6, 0, sizeof(fl6));
+	fl6.flowi6_oif = oif;
+	fl6.flowi6_mark = mark;
+	fl6.flowi6_flags = 0;
+	fl6.daddr = msg->dest;
+	fl6.saddr = iph->daddr;
+
+	dst = ip6_route_output(net, NULL, &fl6);
+	if (!dst->error)
+		rt6_do_redirect(dst, NULL, skb);
+	dst_release(dst);
+}
+EXPORT_SYMBOL_GPL(ip6_redirect_no_header);
+
 void ip6_sk_redirect(struct sk_buff *skb, struct sock *sk)
 {
 	ip6_redirect(skb, sock_net(sk), sk->sk_bound_dev_if, sk->sk_mark);
-- 
1.7.3.1

Re: [PATCH V2] ipv6: handle Redirect ICMP Message with no Redirected Header option

[Hannes Frederic Sowa]

On Tue, Aug 20, 2013 at 03:13:41PM +0800, Duan Jiong wrote:
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1178,6 +1178,28 @@ void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark)
>  }
>  EXPORT_SYMBOL_GPL(ip6_redirect);
>  
> +void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif,
> +			    u32 mark)
> +{
> +	const struct ipv6hdr *iph = (struct ipv6hdr *)skb_network_header(skb);

Was there a problem with ipv6_hdr?

> +	const struct rd_msg *msg = (struct rd_msg *)skb_transport_header(skb);
> +	struct dst_entry *dst;
> +	struct flowi6 fl6;
> +
> +	memset(&fl6, 0, sizeof(fl6));
> +	fl6.flowi6_oif = oif;
> +	fl6.flowi6_mark = mark;
> +	fl6.flowi6_flags = 0;
> +	fl6.daddr = msg->dest;
> +	fl6.saddr = iph->daddr;
> +
> +	dst = ip6_route_output(net, NULL, &fl6);
> +	if (!dst->error)
> +		rt6_do_redirect(dst, NULL, skb);
> +	dst_release(dst);
> +}
> +EXPORT_SYMBOL_GPL(ip6_redirect_no_header);
> +
>  void ip6_sk_redirect(struct sk_buff *skb, struct sock *sk)
>  {
>  	ip6_redirect(skb, sock_net(sk), sk->sk_bound_dev_if, sk->sk_mark);

Introducing a new function here is the right thing. Maybe you could have
a look how these redirects could be fed to raw sockets, too?

Thanks,

  Hannes

Re: [PATCH V2] ipv6: handle Redirect ICMP Message with no Redirected Header option

[Duan Jiong]

于 2013年08月20日 19:50, Hannes Frederic Sowa 写道:
> On Tue, Aug 20, 2013 at 03:13:41PM +0800, Duan Jiong wrote:
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -1178,6 +1178,28 @@ void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark)
>>  }
>>  EXPORT_SYMBOL_GPL(ip6_redirect);
>>  
>> +void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif,
>> +			    u32 mark)
>> +{
>> +	const struct ipv6hdr *iph = (struct ipv6hdr *)skb_network_header(skb);
> 
> Was there a problem with ipv6_hdr?
> 
Actually ipv6_hdr is better, and i will modify it.
>> +	const struct rd_msg *msg = (struct rd_msg *)skb_transport_header(skb);
>> +	struct dst_entry *dst;
>> +	struct flowi6 fl6;
>> +
>> +	memset(&fl6, 0, sizeof(fl6));
>> +	fl6.flowi6_oif = oif;
>> +	fl6.flowi6_mark = mark;
>> +	fl6.flowi6_flags = 0;
>> +	fl6.daddr = msg->dest;
>> +	fl6.saddr = iph->daddr;
>> +
>> +	dst = ip6_route_output(net, NULL, &fl6);
>> +	if (!dst->error)
>> +		rt6_do_redirect(dst, NULL, skb);
>> +	dst_release(dst);
>> +}
>> +EXPORT_SYMBOL_GPL(ip6_redirect_no_header);
>> +
>>  void ip6_sk_redirect(struct sk_buff *skb, struct sock *sk)
>>  {
>>  	ip6_redirect(skb, sock_net(sk), sk->sk_bound_dev_if, sk->sk_mark);
> 
> Introducing a new function here is the right thing. Maybe you could have
> a look how these redirects could be fed to raw sockets, too?
> 
Because of no Redirected Header option, so we don't have enough
information to find out the related raw socket. So, there is no need
to deal with that condition.

Thanks,
  Duan 

Re: [PATCH V2] ipv6: handle Redirect ICMP Message with no Redirected Header option

[Hannes Frederic Sowa]

On Wed, Aug 21, 2013 at 10:12:25AM +0800, Duan Jiong wrote:
> > Introducing a new function here is the right thing. Maybe you could have
> > a look how these redirects could be fed to raw sockets, too?
> > 
> Because of no Redirected Header option, so we don't have enough
> information to find out the related raw socket. So, there is no need
> to deal with that condition.

Ah, of course. I thought we could look up the socket solely by src and
dst address. I forgot about the protocol.