Re: [PATCH] - Fixes NULL pointer deference in usb-serial driver.

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Wed, Nov 16, 2005 at 09:24:16AM -0800, Greg KH wrote:
> On Wed, Nov 16, 2005 at 03:16:34PM -0200, Luiz Fernando Capitulino wrote:
> > 1. Process A calls open() and tcgetattr(). When it calls close(), the specific
> > driver function put it to sleep at usb_serial.c:242 (I'm using pl2303 driver)
> > 
> > 2. Process B calls open() and before the call to tcgetattr() it is put to
> > sleep.
> > 
> > 3. Process A wakes up and finish the close procedure (which resets
> > 'port->tty->driver_data')
> > 
> > 4. Process B wakes up, executes serial_ioctl() and gets a NULL pointer in
> > 'port->tty->driver_data'.
> 
> Ugh, the tty core should really protect us from stuff like this,
> unfortunately, there is no locking there, yet.  People are working on
> it...

No.  It is quite correct to have an overlapping open and close with
TTYs.  In fact, it's something which is rather fundamental to TTYs.

Consider: you have a modem connected to a serial like.  You want to
use it for both callin and dial out.

Your box runs a getty on the line.  The getty opens the port in non-
blocking mode, configures it, closes it and then re-opens it in blocking
mode.  The open call waits for the DCD line to become active.

Meanwhile, you want to use the modem to call out, so you open the port
in non-blocking mode.  This succeeds, and you eventually finish using
the port.  You close it.  This triggers a hang up in the usual way and
_then_ causes the first open call to return an EAGAIN error.

Hint: there's a VERY good reason the serial_core layer exists and
it's to get these kind of semantics (and bugs) centralised in one
place rather than spread across thousands of drivers.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core