Re: [BUG, USB, visor] Reproduceable use-after-free with visor.c and pppd

Greg KH (greg@kroah.com)
Tue, 1 Apr 2003 11:08:48 -0800


On Tue, Apr 01, 2003 at 08:44:02PM +0200, Stephan Maciej wrote:
> Hi all, Hi Greg,
>
> I can reproduce errors of the "object was modified after freeing" kind when
> connecting my Palm m505 to the internet as follows:
>
> - Choose "Connect" in one of the Palm apps
> - Wait until I see "Meldet an" ("logs on") on the Palm
> - Run pppd as root:
> pppd /dev/usb/tts/1 debug local noauth ms-dns <blah> <foo>:<bar>
> - pppd initializes the connection -> connection is up and running (not too
> long, see below)
>
> My logs show (CONFIG_USB_DEBUG=y):
>
> hub 4-0:0: port 2, status 101, change 1, 12 Mb/s
> hub 4-0:0: debounce: port 2: delay 100ms stable 4 status 0x101
> hub 4-0:0: new USB device on port 2, assigned address 6
> usb 4-2: new device strings: Mfr=1, Product=2, SerialNumber=5
> usb 4-2: Product: Palm Handheld
> usb 4-2: Manufacturer: Palm, Inc.
> SerialNumber: <wannaknowthathuh?>
> usb_new_device - registering interface 4-2:0
> usb_device_probe
> usb_device_probe - got id
> Handspring Visor / Treo / Palm 4.0 / Clié 4.x converter detected
> usb 4-2: Handspring Visor / Treo / Palm 4.0 / Clié 4.x converter now attached
> to ttyUSB0 (or usb/tts/0 for devfs)
> Handspring Visor / Treo / Palm 4.0 / Clié 4.x converter now attached to
> ttyUSB1 (or usb/tts/1 for devfs)
>
> Then I start pppd:
>
> pppd 2.4.1 started by root, uid 0
> Perms of /dev/usb/tts/1 are ok, no 'mesg n' neccesary.
> using channel 4
> Using interface ppp0
> Connect: ppp0 <--> /dev/usb/tts/1
>
> <pppd blah follows>
>
> Apr 1 20:11:25 sunrise pppd[1281]: local IP address 192.168.100.1
> Apr 1 20:11:25 sunrise pppd[1281]: remote IP address 192.168.100.10
> status = 0x0
>
> Connection is up. I wait a few seconds and kill pppd by typing ^C on the
> terminal:
>
> Apr 1 20:11:36 sunrise pppd[1281]: Terminating on signal 2.
> Apr 1 20:11:36 sunrise pppd[1281]: cbcp_lowerdown
> Apr 1 20:11:36 sunrise pppd[1281]: Script /etc/ppp/ip-down started (pid 1302)
> Apr 1 20:11:36 sunrise pppd[1281]: sent [LCP TermReq id=0x3 "User request"]
> Apr 1 20:11:36 sunrise pppd[1281]: Script /etc/ppp/ip-down finished (pid
> 1302), status = 0x0
> Apr 1 20:11:36 sunrise pppd[1281]: rcvd [LCP TermAck id=0x3 "User request"]
> Apr 1 20:11:36 sunrise pppd[1281]: Connection terminated.
> Apr 1 20:11:37 sunrise pppd[1281]: Connect time 0.3 minutes.
> Apr 1 20:11:37 sunrise pppd[1281]: Sent 97 bytes, received 82 bytes.
> Apr 1 20:11:37 sunrise pppd[1281]: Exit.
> Apr 1 20:11:41 sunrise kernel: hub 4-0:0: port 2, status 100, change 3, 12
> Mb/s
> Apr 1 20:11:41 sunrise kernel: usb 4-2: USB disconnect, address 6
> Apr 1 20:11:41 sunrise kernel: usb 4-2: unregistering interfaces
> Apr 1 20:11:41 sunrise kernel: visor ttyUSB0: Handspring Visor / Treo / Palm
> 4.0 / Clié 4.x converter now disconnected from ttyUSB0
> Apr 1 20:11:41 sunrise kernel: visor ttyUSB1: Handspring Visor / Treo / Palm
> 4.0 / Clié 4.x converter now disconnected from ttyUSB1
> Apr 1 20:11:41 sunrise kernel: visor 4-2:0: device disconnected
> Apr 1 20:11:41 sunrise kernel: usb 4-2: unregistering device
> Apr 1 20:11:41 sunrise kernel: hub 4-0:0: port 2 enable change, status 100

Looks like the USB device and visor driver is cleaned up nicely. But
then...

> Apr 1 20:11:43 sunrise kernel: Slab corruption: start=ddd2b000,
> expend=ddd2bfff, problemat=ddd2ba58

<snip>

I don't see any usb traces here in the backtrace. Or ppp code. I don't
know what could be causing this, sorry.

> Apr 1 19:52:44 sunrise kernel: drivers/usb/host/uhci-hcd.c: 9000: host controller process error. something bad happened
> Apr 1 19:52:44 sunrise kernel: drivers/usb/host/uhci-hcd.c: 9000: host controller halted. very bad
>
> At this point my USB mouse didn't want to work anymore, and the Palm stopped
> downloading stuff (how could it - the pppd process was stuck in D state).
> Sadly I a) hadn't turned debugging on before and b) was stupid enough to see
> where pppd got stuck (does that matter?).

No, this means your uhci controller had a serious fault. We've been
seeing these much more often lately, I wonder what changed...

> <whining>
> And even *if* I find something and send out a patch to LKML it's going to be
> ignored just as the past two patches I sent.
> </whining>

Did you send the patches to the maintainer of the code?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/