On Thu, 2010-08-26 at 09:34 +0100, Eric Dumazet wrote:
> Le jeudi 26 août 2010 à 09:14 +0100, Ian Campbell a écrit :
> > On Thu, 2010-08-26 at 09:03 +0100, Eric Dumazet wrote:
> > > Here is the patch, could you test it please ?
> > >
> > > Thanks !
> > >
> > > [PATCH] l2tp: test for malicious frames in l2tp_eth_dev_recv()
> > >
> > > close https://bugzilla.kernel.org/show_bug.cgi?id=16529
> > >
> > > Before calling dev_forward_skb(), we should make sure skb contains at
> > > least an ethernet header, even if length included in upper layer said
> > > so.
> >
> > Does this imply that there is some problem with xen-netfront setting
> > skb->len or skb->data_len or something incorrectly? It's not clear where
> > data_len has come from in this context.
>
> data_len is a 16bit field provided in a prior encapsulation header,
> provided by user (untrusted source)
>
> Some buggy or malicious software sent an invalid frame,
>
>
> < encapsulation [len=1000] > < 'runt' eth frame (len<14) >
>
> Another fix would be to change l2tp_recv_dequeue_skb(), and check
>
> L2TP_SKB_CB(skb)->length against skb->len, before calling
>
> (*session->recv_skb)(session, skb, length);
>
>
> I prefer the one liner patch I sent you, as a minimum fix.
Thanks, I just wanted to be sure we weren't papering over a potential
issue in xen-netfront.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home