bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Kernel crash on device_map DEVICE_NULL


From: John Tobey
Subject: Kernel crash on device_map DEVICE_NULL
Date: Thu, 22 Nov 2001 10:08:12 -0500
User-agent: Mutt/1.2.5i

On Sun, Nov 18, 2001 at 09:25:56PM -0500, Roland McGrath wrote:
> Well, frankly I think you're nuts.  But more power to you.
> For your stated goals and constraints, I would just go with plex86.
> But if you really get this approach to work usably, it could be interesting.

Now I don't know if the following thing can happen in Real Life, so it
may not be a bug in Mach at all, but it seems that way looking at the
backtrace.  Perhaps someone with a real installation who doesn't mind
possibly crashing Mach would be kind enough to verify it.

ext2fs.static opens the (on my system, nonexistent) "time" device,
ignores the failure return, and tries to device_map() it using a null
pointer.  The kernel fails to check this case in
mach_device_deallocate().  Boom!  Here's my suggested patch:

Index: device/dev_lookup.c
===================================================================
RCS file: /cvsroot/hurd/gnumach/device/dev_lookup.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 dev_lookup.c
--- device/dev_lookup.c 1997/02/25 21:28:14     1.1.1.1
+++ device/dev_lookup.c 2001/11/22 14:35:54
@@ -215,6 +215,9 @@
 mach_device_deallocate(device)
        register mach_device_t  device;
 {
+       if (device == DEVICE_NULL)
+           return;
+
        simple_lock(&device->ref_lock);
        if (--device->ref_count > 0) {
            simple_unlock(&device->ref_lock);
END OF PATCH.

Here is my backtrace:  (note that the line number in dev_lookup.c is
slightly off, it should be the `if (--device->ref_count > 0)' above)
(also note that the other line numbers are *not* off.:)

#0  device_deallocate (device=0x0)
    at ../../src/hacks/gnumach/device/dev_lookup.c:223
#1  0xb0033592 in _Xdevice_map (InHeadP=0x410faf7c, OutHeadP=0x411a8010)
    at device_server.c:914
#2  0xb0014174 in ipc_kobject_server (request=0x410faf6c)
    at ../../src/hacks/gnumach/kern/ipc_kobject.c:192
#3  0xb000ed1b in mach_msg_trap (msg=0x1fdf4, option=3, send_size=56, 
    rcv_size=40, rcv_name=11, time_out=0, notify=0)
    at ../../src/hacks/gnumach/ipc/mach_msg.c:1419
#4  0xb0004dab in otop_do_syscall (func=0xb000e4f0 <mach_msg_trap>, nargs=7, 
    args=0x410faa28) at ../../src/hacks/gnumach/otop/puppeteer.c:114
#5  0xb0005049 in otop_op_resume (proc=0x410faab0, thread=0xb00452d0)
    at ../../src/hacks/gnumach/otop/puppeteer.c:172
#6  0xb0004fa0 in otop_op_resume (proc=0x410faab0, thread=0xb00452d0)
    at ../../src/hacks/gnumach/otop/puppeteer.c:149
#7  0xb00046dd in syscall_return_continue ()
    at ../../src/hacks/gnumach/otop/pcb.c:181
#8  0xb808c834 in ?? ()
#9  0xb003f234 in symtab_index ()
#10 0x7 in ?? ()
Cannot access memory at address 0x14

Regards,
-John



reply via email to

[Prev in Thread] Current Thread [Next in Thread]