netdev - Re: [PATCH] sis900: Allocate rx replacement buffer before rx operation

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:	Fri, 20 Apr 2007 19:55:44 +0200
From:	Daniele Venzano <venza@...wnhat.org>
To:	Neil Horman <nhorman@...driver.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net,
	Jeff Garzik <jgarzik@...ox.com>
Subject: Re: [PATCH] sis900: Allocate rx replacement buffer before rx operation


Il giorno 20/apr/07, alle ore 15:54, Neil Horman ha scritto:

> Hey there-
> 	The sis900 driver appears to have a bug in which the receive routine
> passes the skbuff holding the received frame to the network stack  
> before
> refilling the buffer in the rx ring.  If a new skbuff cannot be  
> allocated, the
> driver simply leaves a hole in the rx ring, which causes the driver  
> to stop
> receiving frames and become non-recoverable without an rmmod/insmod  
> according to
> reporters.  This patch reverses that order, attempting to allocate  
> a replacement
> buffer first, and receiving the new frame only if one can be  
> allocated.  If no
> skbuff can be allocated, the current skbuf in the rx ring is  
> recycled, dropping
> the current frame, but keeping the NIC operational.
Yes, I had one report of a user actually hitting this, but it is  
quite hard to reproduce and I don't have continuos access anymore to  
my sis900 machine.
The patch seems fine by me.

> Signed-off-by: Neil Horman <nhorman@...driver.com>
Signed-off-by: Daniele Venzano <venza@...wnhat.org>

--
Daniele Venzano
http://www.brownhat.org


Download attachment "PGP.sig" of type "application/pgp-signature" (187 bytes)