[PATCH] ipv6: fix a potential use after free in sit.c

[r***@gmail.com]

From: Li RongQing <***@gmail.com>

pskb_may_pull() maybe change skb->data and make iph pointer oboslete,
fix it by geting ip header length directly.

Fixes: ca15a078 (sit: generate icmpv6 error when receiving icmpv4 error)
Cc: Oussama Ghorbel <***@pivasoftware.com>
Signed-off-by: Li RongQing <***@gmail.com>
---
net/ipv6/sit.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 6eab37c..0ccadab 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -485,11 +485,11 @@ static void ipip6_tunnel_uninit(struct net_device *dev)
*/
static int ipip6_err_gen_icmpv6_unreach(struct sk_buff *skb)
{
- const struct iphdr *iph = (const struct iphdr *) skb->data;
+ int ihl = ((const struct iphdr *)skb->data)->ihl*4;
struct rt6_info *rt;
struct sk_buff *skb2;

- if (!pskb_may_pull(skb, iph->ihl * 4 + sizeof(struct ipv6hdr) + 8))
+ if (!pskb_may_pull(skb, ihl + sizeof(struct ipv6hdr) + 8))
return 1;

skb2 = skb_clone(skb, GFP_ATOMIC);
@@ -498,7 +498,7 @@ static int ipip6_err_gen_icmpv6_unreach(struct sk_buff *skb)
return 1;

skb_dst_drop(skb2);
- skb_pull(skb2, iph->ihl * 4);
+ skb_pull(skb2, ihl);
skb_reset_network_header(skb2);

rt = rt6_lookup(dev_net(skb->dev), &ipv6_hdr(skb2)->saddr, NULL, 0, 0);

[Eric Dumazet]

Post by r***@gmail.com
pskb_may_pull() maybe change skb->data and make iph pointer oboslete,
fix it by geting ip header length directly.
Fixes: ca15a078 (sit: generate icmpv6 error when receiving icmpv4 error)
---
net/ipv6/sit.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

Acked-by: Eric Dumazet <***@google.com>

Thanks for doing all these checks !

[David Miller]

From: Eric Dumazet <***@gmail.com>
Date: Sat, 18 Oct 2014 08:52:20 -0700

Post by Eric Dumazet

Post by r***@gmail.com
pskb_may_pull() maybe change skb->data and make iph pointer oboslete,
fix it by geting ip header length directly.
Fixes: ca15a078 (sit: generate icmpv6 error when receiving icmpv4 error)
---
net/ipv6/sit.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

Thanks for doing all these checks !

Indeed, I wish we could somehow automate this.

Yes, I'm sure we could construct some sparse et al. rules but
I mean at run time. For example, having a special pointer type
that you can't dereference directly. At the time of assignment
the pointer gets some kind of state, and pskb_may_pull() et al.
calls invalidate that "state".

It probably could just be a 2-bit counter which is incremented
every time skb->data is reallocated.

The captured 2-bit generation count could be stored in the low
bits of the pointer.

Anyways, just throwing out ideas...

[Dave Taht]

Post by David Miller
Indeed, I wish we could somehow automate this.
Yes, I'm sure we could construct some sparse et al. rules but
I mean at run time. For example, having a special pointer type
that you can't dereference directly. At the time of assignment
the pointer gets some kind of state, and pskb_may_pull() et al.
calls invalidate that "state".
It probably could just be a 2-bit counter which is incremented
every time skb->data is reallocated.
The captured 2-bit generation count could be stored in the low
bits of the pointer.
Anyways, just throwing out ideas...

So far as I know, the one machine linux has never been ported
to was a LISP machine. With its 36 bit words, and tagging, that
would do what you want. I had kind of hoped with 64 bits of
addressing some of those ideas would have been reused.

/me misses truly oddball architectures


--=20
Dave T=C3=A4ht

http://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

[David Miller]

From: Dave Taht <***@gmail.com>
Date: Sat, 18 Oct 2014 10:22:35 -0700

Post by Dave Taht
So far as I know, the one machine linux has never been ported
to was a LISP machine. With its 36 bit words, and tagging, that
would do what you want. I had kind of hoped with 64 bits of
addressing some of those ideas would have been reused.
/me misses truly oddball architectures

Sparc cpus have tagged add and subtract instructions. :)