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, 28 Oct 2011 12:50:48 +0200
From:	Uwe Bonnes <bon@...ktron.ikp.physik.tu-darmstadt.de>
To:	Andrew Worsley <amworsley@...il.com>
CC:	Greg Kroah-Hartman <gregkh@...e.de>,
	Alan Cox <alan@...ux.intel.com>,
	Johan Hovold <jhovold@...il.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix Corruption issue in USB ftdi driver drivers/usb/serial/ftdi_sio.c

>>>>> "Andrew" == Andrew Worsley <amworsley@...il.com> writes:

    Andrew> ftdi_set_termios() is always setting the baud rate and data bits
    Andrew> and parity on every call. When called while characters are being
    Andrew> transmitted can cause the FTDI chip to corrupt the serial port
    Andrew> bit stream by stalling the output half a bit during the output
    Andrew> of a character.  Simple fix by skipping this setting if the baud
    Andrew> rate/data bits/parity are unchanged.

    Andrew> Signed-off-by: Andrew Worsley <amworsley@...il.com> ----

    Andrew> This bug was observed on 2.6.32 kernel (this patch is ported to
    Andrew> latest kernel for ease of review).  Using a FTDI USB serial chip
    Andrew> at 38400 repeatedly generating output by running a simple
    Andrew> command such as "uname -a" or "echo Linux" gives occasional
    Andrew> corruption on the output

    Andrew> ...
    >> echo Linux
    Andrew> L.$,3u=.(Bnux

Could you please give a more specific receipe to reproduce the bug. Running
with an adapter with TX/RX shorted at "stty -F /dev/ttyUSB0" 38400", several
> uname -a /dev/ttyUSB0
runs gave no artifact in a "seyon -modem /dev/ttyUSB0" console.

Doing 
> uname -a /dev/ttyUSB0
in one xterm and receiving with
>cat /dev/ttyUSB0
in another xterm gives lot of repeated lines in the receiving terminal. But
I have the same behaviour with /dev/ttyS0 on a real serial port on the
mainboard.

Otherwise, shouldn't all control transfers to the FTDI be only done with the
tx buffer in the FTDI empty? I guess the RX buffer is not affected by some
change. But this is something to be done with great knowledge...

Bye
-- 
Uwe Bonnes                bon@...ktron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ