[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20141018.130720.448065424567018228.davem@davemloft.net>
Date: Sat, 18 Oct 2014 13:07:20 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: eric.dumazet@...il.com
Cc: roy.qing.li@...il.com, netdev@...r.kernel.org,
ghorbel@...asoftware.com
Subject: Re: [PATCH] ipv6: fix a potential use after free in sit.c
From: Eric Dumazet <eric.dumazet@...il.com>
Date: Sat, 18 Oct 2014 08:52:20 -0700
> On Sat, 2014-10-18 at 17:33 +0800, roy.qing.li@...il.com wrote:
>> From: Li RongQing <roy.qing.li@...il.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 <ghorbel@...asoftware.com>
>> Signed-off-by: Li RongQing <roy.qing.li@...il.com>
>> ---
>> net/ipv6/sit.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Acked-by: Eric Dumazet <edumazet@...gle.com>
>
> 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...
--
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
Powered by blists - more mailing lists