[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/4] xen-netfront: drop skb when skb->len > 65535



On Tue, 2013-03-19 at 13:40 +0000, David Vrabel wrote:
> On 18/03/13 14:19, Wei Liu wrote:
> > On Mon, 2013-03-18 at 14:00 +0000, David Vrabel wrote:
> >> On 18/03/13 13:48, Ian Campbell wrote:
> >>> On Mon, 2013-03-18 at 13:46 +0000, David Vrabel wrote:
> >>>> On 18/03/13 10:35, Wei Liu wrote:
> >>>>> The `size' field of Xen network wire format is uint16_t, anything 
> >>>>> bigger than
> >>>>> 65535 will cause overflow.
> >>>>
> >>>> The backend needs to be able to handle these bad packets without
> >>>> disconnecting the VIF -- we can't fix all the frontend drivers.
> >>>
> >>> Agreed, although that doesn't imply that we shouldn't fix the frontend
> >>> where we can -- such as upstream as Wei does here.
> >>
> >> Yes, frontends should be fixed where possible.
> >>
> >> This is what I came up with for the backend.  I don't have time to look
> >> into it further but, Wei, feel free to use it as a starting point.
> >>
> > 
> > Thanks for this patch.
> > 
> > I haven't gone through XSA-39 discussion, this is why I didn't come up
> > with a fix for backend -- I need to make sure dropping packet like this
> > won't re-exhibit the security hole.
> 
> How are these overlarge packets generated?  How do you reproduce the issue?
> 

Inside a VM, ifconfig eth0 mtu 100, iperf -c XXXX .

But other people seeing this could not be using the same method because
nobody would set mtu to 100 in production system AFAICT.


Wei.

> David



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.