[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1319010435.18562.3.camel@edumazet-laptop>
Date: Wed, 19 Oct 2011 09:47:15 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: David Miller <davem@...emloft.net>
Cc: despite@...il.com, netdev@...r.kernel.org,
jeffrey.t.kirsher@...el.com, jesse.brandeburg@...el.com,
bruce.w.allan@...el.com, carolyn.wyborny@...el.com,
donald.c.skidmore@...el.com, gregory.v.rose@...el.com,
peter.p.waskiewicz.jr@...el.com, alexander.h.duyck@...el.com,
john.ronciak@...el.com, e1000-devel@...ts.sourceforge.net
Subject: Re: BUG in skb_pull with e1000e, PPTP, and L2TP
Le mercredi 19 octobre 2011 à 03:31 -0400, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@...il.com>
> Date: Tue, 18 Oct 2011 05:59:53 +0200
>
> > [PATCH v2] pptp: pptp_rcv_core() misses pskb_may_pull() call
> >
> > e1000e uses paged frags, so any layer incorrectly pulling bytes from skb
> > can trigger a BUG in skb_pull()
> >
> > [951.142737] [<ffffffff813d2f36>] skb_pull+0x15/0x17
> > [951.142737] [<ffffffffa0286824>] pptp_rcv_core+0x126/0x19a [pptp]
> > [951.152725] [<ffffffff813d17c4>] sk_receive_skb+0x69/0x105
> > [951.163558] [<ffffffffa0286993>] pptp_rcv+0xc8/0xdc [pptp]
> > [951.165092] [<ffffffffa02800a3>] gre_rcv+0x62/0x75 [gre]
> > [951.165092] [<ffffffff81410784>] ip_local_deliver_finish+0x150/0x1c1
> > [951.177599] [<ffffffff81410634>] ? ip_local_deliver_finish+0x0/0x1c1
> > [951.177599] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58
> > [951.177599] [<ffffffff81410996>] ip_local_deliver+0x51/0x55
> > [951.177599] [<ffffffff814105b9>] ip_rcv_finish+0x31a/0x33e
> > [951.177599] [<ffffffff8141029f>] ? ip_rcv_finish+0x0/0x33e
> > [951.204898] [<ffffffff81410846>] NF_HOOK.clone.7+0x51/0x58
> > [951.214651] [<ffffffff81410bb5>] ip_rcv+0x21b/0x246
> >
> > pptp_rcv_core() is a nice example of a function assuming everything it
> > needs is available in skb head.
> >
> > Reported-by: Bradley Peterson <despite@...il.com>
> > Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>
>
> I assume by the driver paths in the patch that you think this
> is 'net-next' material and not suitable for plain 'net', right?
I incorrectly thought this driver was at the same location in net &
net-next, and I my net-next tree was more convenient to compile this.
I can respin patch on net tree if you prefer.
Thanks
--
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