Skip to contentSkip to conversation

Reproduceable use-after-free with visor.c and pppd

BUG, USB, visor Greg KH 1 participant 1 message Apr 1, 2003 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Greg KH

author
#1 lore raw
Quoted 61 lines · Stephan Maciej

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
Quoted 8 lines
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...

Quoted 2 lines
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.

Quoted 7 lines
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...

Quoted 4 lines

<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