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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 Mar 2013 13:40:08 +0000
From:	Wei Liu <wei.liu2@...rix.com>
To:	David Vrabel <david.vrabel@...rix.com>
CC:	<wei.liu2@...rix.com>, Ian Campbell <Ian.Campbell@...rix.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"annie.li@...cle.com" <annie.li@...cle.com>,
	"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/4] xen-netfront: drop skb when skb->len >
 65535

On Wed, 2013-03-20 at 20:02 +0000, David Vrabel wrote:

> >  		first->size -= txp->size;
> > @@ -938,6 +949,12 @@ static int netbk_count_requests(struct xenvif *vif,
> >  			return -EINVAL;
> >  		}
> >  	} while ((txp++)->flags & XEN_NETTXF_more_data);
> > +
> > +	if (drop) {
> > +		netbk_tx_err(vif, txp, idx + frags);
> 
> This needs to be netbk_tx_err(vif, first, idx + frags) or the guest will
> crash as we push a bunch of invalid responses.
> 

Can this really handle the situation when first->size overflows? In that
case frag == 0, the netbk_tx_err call is in fact netbk_tx_err(vif, txp,
idx). idx is the ring index of first txp, so in fact you're only
responding to the head txp, ignoring other tx requests for the same skb?

Even first->size doesn't overflow, a malicious / buggy frontend can
still generate tx req that makes txp->size > first->size. In that case
there could be also some trailing tx requests left un-responded.

I check the code before XSA-39 fix, its logic is more or less the same,
but it did work. My suspicion is that those trailing tx requests are
invalidated in future loops of xen_netbk_tx_build_gops.

I think the correct action is to just take first txp and loop responding
until we consume the whole packet.

Wei.

> David
> 
> > +		return -EIO;
> > +	}
> > +
> >  	return frags;
> >  }
> > 
> > @@ -1327,7 +1344,7 @@ static unsigned xen_netbk_tx_build_gops(struct
> > xen_netbk *netbk)
> >  				continue;
> >  		}
> > 
> > -		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
> > +		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do, idx);
> >  		if (unlikely(ret < 0))
> >  			continue;

--
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