Re: [PATCH 2.6.13-rc3-git9] pl2303: pl2303_update_line_status data length fix

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 08 Aug 2005, Greg KH wrote:
> On Thu, Jul 28, 2005 at 03:32:20PM +0200, Horst Schirmeier wrote:
> > Minimum data length must be UART_STATE + 1, as data[UART_STATE] is being
> > accessed for the new line_state. Although PL-2303 hardware is not
> > expected to send data with exactly UART_STATE length, this keeps it on
> > the safe side.
> > 
> > Signed-off-by: Horst Schirmeier <[email protected]>
> > ---
> > 
> > --- linux-2.6.13-rc3-git9/drivers/usb/serial/pl2303.c.orig	2005-07-28 14:42:58.000000000 +0200
> > +++ linux-2.6.13-rc3-git9/drivers/usb/serial/pl2303.c	2005-07-28 14:43:16.000000000 +0200
> > @@ -826,7 +826,7 @@ static void pl2303_update_line_status(st
> >  	struct pl2303_private *priv = usb_get_serial_port_data(port);
> >  	unsigned long flags;
> >  	u8 status_idx = UART_STATE;
> > -	u8 length = UART_STATE;
> > +	u8 length = UART_STATE + 1;
> 
> "safe side" yes, but this will just prevent any line changes from going
> back to the user, right?

IMHO not, no. The PL-2303 interrupt IN endpoint has a 10 bytes FIFO and
(as far as I've observed from the type_1 model) always sends packets
with exactly this size. The UART_STATE is located at offset 0x08,
therefore the minimum packet length we need is 0x09 (UART_STATE + 1).

Here are the two different byte sequences from that endpoint I picked
up; the first with a terminal on the serial end, the second without one
(both times using the patched pl2303 module with debug=1):

a1 20 00 00 00 00 02 00 00 00
a1 20 00 00 00 00 02 00 82 00

Note the UART_STATE byte with the DSR and CTS bits set in the second
case.

> Hm, how is this working at all, it looks like we overflow the buffer...

In the unlikely case that some weird hardware sends a packet with
exactly UART_STATE (8) bytes length, yes, we do. Normal PL-2303 hardware
_should_ cause no trouble, as it always sends 10 bytes (at least my
hardware does), therefore my side note "this keeps it on the safe side".

> Have you tested this change?

Yes, I have.

> thanks,
> 
> greg k-h

Kind regards,
 Horst

-- 
PGP-Key 0xD40E0E7A

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux