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]

Date:	Mon, 24 Aug 2009 21:42:33 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Bruno Prémont <bonbons@...ux-vserver.org>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, 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 Mon, 24 Aug 2009, Bruno [UTF-8] PrÃ©mont wrote:

> The patch does not work properly:
> 
> When I plug in the USB2serial converter (be it ftdi or pl2302) device
> node is created properly and minicom can use it.
> 
> When I exit minicom I can no longer start it again, eventually I get
> a killed minicom with NULL-dereference
> 
> A rmmod/modprobe cycle works but the end result is no device node
> created by udev and udev's path_id helper is stuck. (unable to
> determine where for now as netconsole causes trouble with netdev
> polling)
> I will have a deeper look tomorrow as this evening is already over.
> 
> Bruno
> 
> 
> Trace result for ftdi device:

> [   76.115797] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver
> [  163.471333] BUG: unable to handle kernel NULL pointer dereference at 00000064
> [  163.471531] IP: [<c115f7ae>] tty_open+0x11e/0x4b0
> [  163.471650] *pde = 00000000 
> [  163.471730] Oops: 0000 [#1] 
> [  163.471809] last sysfs file: /sys/devices/virtual/hwmon/hwmon0/temp1_input
> [  163.471944] Modules linked in: ftdi_sio usbserial squashfs zlib_inflate nfs lockd nfs_acl sunrpc 8021q snd_pcm_oss snd_mixer_oss xfs exportfs loop usb_storage snd_intel8x0 nsc_ircc snd_ac97_codec ac97_bus irda snd_pcm snd_timer snd snd_page_alloc ehci_hcd pcspkr i2c_i801 uhci_hcd usbcore crc_ccitt
> [  163.472927] 
> [  163.472967] Pid: 2157, comm: minicom Tainted: G   M       (2.6.31-rc6-gregkh #2) TravelMate 660
> [  163.473148] EIP: 0060:[<c115f7ae>] EFLAGS: 00010246 CPU: 0
> [  163.473247] EIP is at tty_open+0x11e/0x4b0

> For both cases EIP is at:
>   drivers/char/tty_io.c:1253:
> 1246:static int tty_reopen(struct tty_struct *tty)
> 1247:{
> 1248:	struct tty_driver *driver = tty->driver;
> ...
> 1253:	if (driver->type == TTY_DRIVER_TYPE_PTY &&
> 1254:	    driver->subtype == PTY_TYPE_MASTER) {

Okay, thanks for trying it out.  

Apparently the tty isn't getting removed from the driver the way it
should when minicom closes it the first time.  And no wonder -- I just
realized that my new serial_shutdown() routine doesn't call
tty_shutdown(tty).  Try inserting such a call right before
tty->driver_data gets set to NULL.

The division of labor between the TTY core and the lower drivers makes 
very little sense...

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/