NetBSD Problem Report #11311

Received: (qmail 11823 invoked from network); 25 Oct 2000 17:05:21 -0000
Message-Id: <200010251704.e9PH4ba01421@dahan.metonymy.com>
Date: Wed, 25 Oct 2000 12:04:37 -0500 (CDT)
From: Dave Huang <khym@bga.com>
Reply-To: khym@bga.com
To: gnats-bugs@gnats.netbsd.org
Subject: If adb_op_sync times out, kernel memory could be corrupted
X-Send-Pr-Version: 3.95

>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:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Oct 25 17:06:00 +0000 2000
>Closed-Date:    
>Last-Modified:  Sat Mar 02 10:14:11 +0000 2013
>Originator:     Dave Huang
>Release:        1.5_BETA 20001024
>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:
State-Changed-From-To: open->analyzed 
State-Changed-By: scottr 
State-Changed-When: Tue Nov 14 22:41:47 PST 2000 
State-Changed-Why:  
I'm not sure that the assumption that "the device later decides to respond 
with some data" is valid.  More to the point, a device _must_ respond 
within the prescribed time, according to the spec.  The variable we 
have been struggling with is queuing and a rudimentary level of parallel 
I/O processing.  In short, it is by definition not possible to time out 
without receiving data if in fact the device has any intention to send 
a response back. 

Having said all that, I can't say that it will never happen.  Malfunctioning 
hardware should not be able to bring the system down (noting of course 
that in the problem that triggered the PR, nothing was malfunctioning -- 
this has been dealt with separately in PR 11310).  I don't have an easy 
solution but clearly we'll have to come up with some way to prevent this 
from happening. 

--scott 


Responsible-Changed-From-To: port-mac68k-maintainer->scottr 
Responsible-Changed-By: scottr 
Responsible-Changed-When: Tue Nov 14 22:41:47 PST 2000 
Responsible-Changed-Why:  
Responsible-Changed-From-To: scottr->port-mac68k-maintainer
Responsible-Changed-By: tron@NetBSD.org
Responsible-Changed-When: Sat, 02 Mar 2013 10:14:11 +0000
Responsible-Changed-Why:
Assign PR to default owner.


>Unformatted:

Home	PR Database Search