[lkml]   [2010]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: unable to handle kernel NULL pointer dereference in skb_dequeue
From: Denys Fedoryshchenko <>
Date: Fri, 10 Dec 2010 21:51:04 +0200

> On Friday 03 December 2010 16:46:35 Eric Dumazet wrote:
>> Le vendredi 03 décembre 2010 à 15:37 +0100, Andrej Ota a écrit :
>> > >> Patch that works for me is below. Now I only hope I haven't
>> > >> (re)introduced a memory leak...
>> > >
>> > > Problem comes from commit 55c95e738da85 (fix return value of
>> > > __pppoe_xmit() method)
>> > >
>> > > I am not sure patch is OK
>> >
>> > Me neither. That's why I wrote "works for me". All I dare say is that it
>> > works better than current code and is probably no worse than it was
>> > before above mentioned commit. Apart from that, there is no point in
>> > having return value for __pppoe_xmit if return value isn't needed.
>> >
>> > Easiest way of triggering this BUG is by terminating PPPoE on the server
>> > side, which then hits "if (!dev) { goto abort; }". This in turn calls
>> > "kfree_skb(skb); return 0;" which returns to pppoe_rcv_core which then
>> > goto-s to "abort_put" which again calls "kfree_skb(skb)". Voila the bug.
>> >
>> > I don't know how to trigger "if (skb_cow_head(skb, ..." to see if I have
>> > just caused another BUG. However, if I read file comments at the top, I
>> > see a comment from 19/07/01 stating that I have to delete original skb
>> > if code succeeds and never delete it on failure. About the skb copy
>> > mentioned in the same comment, I don't know. 2001 was many commits ago.
>> Well, all I wanted to say was that _I_ was not sure, but probably other
>> network guys have a better diagnostic.
>> Rami, could you re-explain the rationale of your patch ?
>> Thanks
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to
>> More majordomo info at
> Is there any plans to queue any patch to stable?
> pppoe is almost dead in 2.6.36.*

I'll deal with it for -stable once I evaluate this patch for upstream,
which I haven't even gotten to yet.

When people bark about -stable this and -stable that, it just takes
more time away from me actually getting through all the patches. If
it causes a crash, I know it should go to stable and I'll take care of
it. So there is no need to make an explicit note or query about it.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2010-12-10 21:21    [W:0.082 / U:22.856 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site