>Number:         11311
>Category:       port-mac68k
>Synopsis:       If adb_op_sync times out, kernel memory could be corrupted
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-mac68k-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Oct 25 10:06:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Dave Huang
>Release:        NetBSD-1.5_BETA as of October 24, 2000
>Organization:
Name: Dave Huang     |   Mammal, mammal / their names are called /
INet: khym@bga.com   |   they raise a paw / the bat, the cat /
FurryMUCK: Dahan     |   dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 24 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
>Environment:
	
System: NetBSD gedd.metonymy.com 1.5_BETA NetBSD 1.5_BETA (GEDD) #608: Wed Oct 25 11:02:21 CDT 2000     khym@dahan.metonymy.com:/usr/src.local/sys/arch/mac68k/compile/GEDD mac68k

>Description:
	If adb_op_sync() times out, but the ADB device later decides
to respond with some data, the interrupt handler routines will still
copy the data out to the buffer that was originally passed in, even
though that buffer may no longer be valid. (E.g. the buffer was on the
stack, and the calling function has already returned)

>How-To-Repeat:
	I don't know, but I'm pretty sure that's what happened when
the adb_op_sync() timeout was a bit too short for my TrackMan Marble.
The ams probe said that the TrackMan was actually a non-EMP mouse,
then the kernel crashed with a uvm_fault, with the program counter at
0x54303200 -- a rather strange address... translated to ASCII, that's
"T02\0", which happens to be part of the device ID that the TrackMan
was about to return ("LT02").

http://mail-index.netbsd.org/port-mac68k/2000/10/24/0003.html has a
bit more info...

I'm running the adb_direct code, BTW.
>Fix:
	Haven't really looked into it yet... perhaps someone who knows
the ADB code has an easy fix :) Perhaps have adb_op_sync() set
adbBuffer to NULL if it times out, and have the various adb_intr*
routines not call adb_pass_up() if adbBuffer is NULL? But even if that
works, what about the MRG_ADB case?
>Release-Note:
>Audit-Trail:
>Unformatted: