linux-kernel - Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while in use

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]

Message-ID: <Pine.LNX.4.44L0.0908231142530.26309-100000@netrider.rowland.org>
Date:	Sun, 23 Aug 2009 12:15:29 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	Bruno Prémont <bonbons@...ux-vserver.org>,
	Greg KH <greg@...ah.com>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	USB list <linux-usb@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: 2.6.31-rc5 regression: Oops when USB Serial disconnected while
 in use

On Sat, 22 Aug 2009, Alan Stern wrote:

> Alan:
> 
> There's a problem with the tty->ops->shutdown method.  It needs to
> release the last port reference owned by the current tty.  But when was
> that reference originally acquired?  Evidently during the first time
> serial_open() was called for the current tty.
> 
> The problem is that serial_open() has no way to know if a particular 
> invocation is the first one for this tty!  The ASYNCB_INITIALIZED flag 
> doesn't help, because it might not get set during the first call (i.e., 
> if an error occurs).
> 
> To do this right, we need a flag in the tty_struct or the tty_port
> which serial_open() can set when acquiring that first reference and
> shutdown method can clear.  Should I add such a flag?

Never mind, I figured out an answer.  Instead of a new flag, the 
routine can simply test whether or not tty->driver_data has been set.

One more question: Under what circumstances should serial_open() 
increment port->port.count?  It seems that this should happen on every 
call unless tty->driver_data is NULL or filp has been hung up.  Is that 
right?

I have a big patch almost ready for testing.  Unfortunately I don't 
have access to my usual hardware right now, so I can't test it until 
the middle of the week.  Bruno, if you like I will send you the patch 
when it looks okay and you can try it out.

Alan Stern

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