linux-kernel - Re: usbtmc makes Rigol DS1052E oscilloscope crash

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]

Message-ID: <alpine.DEB.2.00.1008231624260.19912@cervantes>
Date:	Mon, 23 Aug 2010 16:49:32 -0400 (EDT)
From:	Mark Whitis <whitis@...elabs.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: usbtmc makes Rigol DS1052E oscilloscope crash

On Thu, 29 Jul 2010, Mark Whitis wrote:

> On my system, I have a similar problem but with somewhat different symptoms.
>
> I only get 2018 bytes back, whether the scope sends 8192 or 524288 bytes. 
> 610 bytes and 1210 bytes read ok.
>
> ...

Another data point: 
The author of one libusb based driver for this scope, after corresponding 
with rigol, found it necessary to limit the first usb read from the bulk 
endpoint to 64 bytes.   After that continuation requests were allowed to 
be full size.    It is possible this is what is causing the symptoms, 
though it is a bit odd that the error doesn't show up until 2K later.

If this is the source of the problem (and if it isn't, it is apparently 
still the source of other problems), it could be worked around by having 
an IOCTL to limit the size of the first low level read and to optionally 
limit the sizes of other reads   This can't be fixed at the application level by changing the size passed to read() 
because of the nature of the usbtmc api in which read() returns entire 
messages rather than being stream oriented.

The DS1052E uses the same firmware as some other models.    The company 
makes other test equipment that may share the offending code and knockoffs 
of older models are sold under a couple brand names.   Thus the number of 
devices which might be affected could be in the dozens.    Other unrelated 
devices may also have similar problems with USBs very limiting timing 
constraints.    The DS1052E, in particular, is popular with linux users 
due to its price/performance ratio, its hackability, and the fact that 
more technical info and discussion has been posted on forums than for 
other DSOs. Thus, incorporating some defensive programming into the 
usbtmc driver would seem warranted.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/