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  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:	Fri, 13 Jun 2008 15:14:00 +0100
From:	Mark McLoughlin <markmc@...hat.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Jeff Garzik <jeff@...zik.org>, netdev@...r.kernel.org,
	virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH 1/3] virtio: fix virtio_net xmit of freed skb bug

On Thu, 2008-05-29 at 16:34 +1000, Rusty Russell wrote:
> On Tuesday 27 May 2008 21:06:26 Mark McLoughlin wrote:
> > On Mon, 2008-05-26 at 17:42 +1000, Rusty Russell wrote:
> > > If we fail to transmit a packet, we assume the queue is full and put
> > > the skb into last_xmit_skb.  However, if more space frees up before we
> > > xmit it, we loop, and the result can be transmitting the same skb twice.
> > >
> > > Fix is simple: set skb to NULL if we've used it in some way, and check
> > > before sending.
> 
> Great! It's a corner case, but it's no more complicated to do it your way.
> 
> Minor mod, I find it clearer to have the vi->last_xmit_skb = NULL; under
> the branch:
> 
> Subject: [PATCH] virtio_net: Delay dropping tx skbs
> Date: Tue, 27 May 2008 12:06:26 +0100
> From: Mark McLoughlin <markmc@...hat.com>
> 
> Currently we drop the skb in start_xmit() if we have a
> queued buffer and fail to transmit it.
> 
> However, if we delay dropping it until we've stopped the
> queue and enabled the tx notification callback, then there
> is a chance space might become available for it.

Hmm, we lost this one somewhere along the way ...

Cheers,
Mark.

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