linux-kernel - Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

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:	Sat, 05 May 2007 11:08:07 -0500
From:	Paul Fulghum <paulkf@...rogate.com>
To:	Antonino Ingargiola <tritemio@...il.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-usb-users@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial
	possible bug]

On Sat, 2007-05-05 at 10:43 -0600, Paul Fulghum wrote:
> There is not an input flush method for the tty driver
> and individual drivers don't process that ioctl.
> The tty drivers I've seen immediately pass receive data to the
> tty buffering and I'm not sure why a driver would
> behave otherwise.

cdc-acm does its own buffering.

In your case, the line discipline throttled the tty device
because the ldisc buffer was full.

If the line discipline throttles the driver input,
the cdc-acm driver stops giving data to the tty buffering
and instead stores them internally.

In the serial driver this usually just results in dropping
RTS to signal the remote end to stop sending. The serial
driver always immediately gives receive data to the tty buffering
without regard to the throttled state.

I would argue that cdc-acm should do the same as the serial driver.

--
Paul

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