* [PATCH] ipv4: fix a bug in ping_err().
@ 2013-02-21 10:09 Li Wei
2013-02-21 18:08 ` David Miller
0 siblings, 1 reply; 3+ messages in thread
From: Li Wei @ 2013-02-21 10:09 UTC (permalink / raw)
To: davem; +Cc: netdev, lw
We should get 'type' and 'code' from the outer ICMP header.
Signed-off-by: Li Wei <lw@cn.fujitsu.com>
---
net/ipv4/ping.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 55c4ee1..2e91006 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -322,8 +322,8 @@ void ping_err(struct sk_buff *skb, u32 info)
struct iphdr *iph = (struct iphdr *)skb->data;
struct icmphdr *icmph = (struct icmphdr *)(skb->data+(iph->ihl<<2));
struct inet_sock *inet_sock;
- int type = icmph->type;
- int code = icmph->code;
+ int type = icmp_hdr(skb)->type;
+ int code = icmp_hdr(skb)->code;
struct net *net = dev_net(skb->dev);
struct sock *sk;
int harderr;
--
1.8.0.2
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] ipv4: fix a bug in ping_err().
2013-02-21 10:09 [PATCH] ipv4: fix a bug in ping_err() Li Wei
@ 2013-02-21 18:08 ` David Miller
2013-02-21 20:26 ` David Miller
0 siblings, 1 reply; 3+ messages in thread
From: David Miller @ 2013-02-21 18:08 UTC (permalink / raw)
To: lw; +Cc: netdev
From: Li Wei <lw@cn.fujitsu.com>
Date: Thu, 21 Feb 2013 18:09:54 +0800
> We should get 'type' and 'code' from the outer ICMP header.
>
> Signed-off-by: Li Wei <lw@cn.fujitsu.com>
> ---
> net/ipv4/ping.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
> index 55c4ee1..2e91006 100644
> --- a/net/ipv4/ping.c
> +++ b/net/ipv4/ping.c
> @@ -322,8 +322,8 @@ void ping_err(struct sk_buff *skb, u32 info)
> struct iphdr *iph = (struct iphdr *)skb->data;
> struct icmphdr *icmph = (struct icmphdr *)(skb->data+(iph->ihl<<2));
> struct inet_sock *inet_sock;
> - int type = icmph->type;
> - int code = icmph->code;
> + int type = icmp_hdr(skb)->type;
> + int code = icmp_hdr(skb)->code;
Isn't that the same thing at this point? skb->data points to the
outer IPv4 header at this point, doesn't it?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] ipv4: fix a bug in ping_err().
2013-02-21 18:08 ` David Miller
@ 2013-02-21 20:26 ` David Miller
0 siblings, 0 replies; 3+ messages in thread
From: David Miller @ 2013-02-21 20:26 UTC (permalink / raw)
To: lw; +Cc: netdev
From: David Miller <davem@davemloft.net>
Date: Thu, 21 Feb 2013 13:08:09 -0500 (EST)
> From: Li Wei <lw@cn.fujitsu.com>
> Date: Thu, 21 Feb 2013 18:09:54 +0800
>
>> We should get 'type' and 'code' from the outer ICMP header.
>>
>> Signed-off-by: Li Wei <lw@cn.fujitsu.com>
>> ---
>> net/ipv4/ping.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
>> index 55c4ee1..2e91006 100644
>> --- a/net/ipv4/ping.c
>> +++ b/net/ipv4/ping.c
>> @@ -322,8 +322,8 @@ void ping_err(struct sk_buff *skb, u32 info)
>> struct iphdr *iph = (struct iphdr *)skb->data;
>> struct icmphdr *icmph = (struct icmphdr *)(skb->data+(iph->ihl<<2));
>> struct inet_sock *inet_sock;
>> - int type = icmph->type;
>> - int code = icmph->code;
>> + int type = icmp_hdr(skb)->type;
>> + int code = icmp_hdr(skb)->code;
>
> Isn't that the same thing at this point? skb->data points to the
> outer IPv4 header at this point, doesn't it?
Answering myself...
Obviously it isn't, ip_rcv() __skb_pull()'s the IP header before it
calls down into ICMP, so we have to use the transport header here.
Applied and queued up for -stable, thanks.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-02-21 20:26 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-21 10:09 [PATCH] ipv4: fix a bug in ping_err() Li Wei
2013-02-21 18:08 ` David Miller
2013-02-21 20:26 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).