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] [day] [month] [year] [list]
Date:	Tue, 19 Nov 2013 16:26:57 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Eric Dumazet" <eric.dumazet@...il.com>
Cc:	"Mark Lord" <mlord@...ox.com>, "Ming Lei" <ming.lei@...onical.com>,
	<davem@...emloft.net>, <netdev@...r.kernel.org>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>,
	<stable@...r.kernel.org>
Subject: RE: net/usb/ax88179_178a driver broken in linux-3.12

> From: Eric Dumazet [mailto:eric.dumazet@...il.com]
> On Tue, 2013-11-19 at 14:43 +0000, David Laight wrote:
> 
> > It isn't directly a TSO problem.
> > There has always been a bug in the xhci driver for fragmented buffers.
> > TSO just means it is given a lot of fragmented buffers.
> >
> > As well as user-supplied fragmented buffers, the bug affects
> > internal fragmentation that happens whenever a buffer crosses a 64k
> > byte boundary (please hw engineers - stop doing this!)
> 
> TCP stack uses order-3 allocations.
> 
> This means 32KB for x86 (PAGE_SIZE=4096)
> 
> What is PAGE_SIZE for your arches ?
> 
> If there is a 6KB limit, we might adapt TCP to make sure we do not cross
> a 64KB boundary.
> 
> Other strategy would be to detect this case in the driver and split a
> problematic segment into two parts.

The xhci code does all the checks for buffer fragments crossing 64k boundaries.
I've posted a patch that uses a conservative upper limit for the
number of fragments: 2 * number_of_sg_buffs + xfer_len/65536.
This saves scanning the sg list twice.

For those not reading linux-usb:

The xhci 'bug' is that an SG list may only cross the end of a ring
segment at an aligned length.
For USB2 devices this will be 512 bytes. For USB3 the documented alignment
could be 16k (depends on a burst size), but might only be 1k.
(This is another place where the hw engineers haven't made life easy.)
The only simple solution is to ensure that a SG list doesn't cross
the end of a ring segment.

	David


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ