Project

General

Profile

Actions

Bug #1343

closed

panic: vm_map_entry_link, dup addr map

Added by alexh almost 15 years ago. Updated almost 15 years ago.

Status:
Closed
Priority:
High
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

The attached test program, when ran with a high argument (100000 or more) causes
this panic.

(gdb) bt
#0 Debugger (msg=0xc056c357 "panic") at ../../platform/pc32/i386/db_interface.c:335
#1 0xc02f455a in panic (fmt=0xc05b8ea8 "vm_map_entry_link: dup addr map %p ent
%p") at ../../kern/kern_shutdown.c:798
#2 0xc04870c0 in _vm_map_clip_end (map=0xc204a1d0, entry=0xd36e6bc0, end=4096,
countp=0xd2baba6c) at ../../vm/vm_map.c:695
#3 0xc0487f57 in vm_map_stack (map=0xc204a1d0, addrbos=4294049792,
max_ssize=1052672, prot=7 '\a', max=7 '\a', cow=0) at ../../vm/vm_map.c:3064
#4 0xc0489bda in vm_mmap (map=0xc204a1d0, addr=0xd2babc88, size=1052672, prot=7
'\a', maxprot=7 '\a', flags=<value optimized out>, handle=0x0, foff=0) at
../../vm/vm_mmap.c:1106
#5 0xc048a231 in kern_mmap (vms=0xc204a1d0, uaddr=0xfff20000<error reading
variable>, ulen=1052672, uprot=<value optimized out>, uflags=1024, fd=-1,
upos=0, res=0xd2babcf0)
at ../../vm/vm_mmap.c:404
#6 0xc048a2aa in sys_mmap (uap=0xd2babcf0) at ../../vm/vm_mmap.c:419
#7 0xc05036f1 in syscall2 (frame=0xd2babd40) at
../../platform/pc32/i386/trap.c:1357
#8 0xc04f2aa6 in Xint0x80_syscall () at ../../platform/pc32/i386/exception.s:876
#9 0xd2babd40 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


Files

readdir.c (1.15 KB) readdir.c alexh, 04/23/2009 07:44 AM
dump (172 KB) dump alexh, 04/23/2009 03:00 PM
test5.c (709 Bytes) test5.c alexh, 04/23/2009 05:40 PM
Actions #1

Updated by alexh almost 15 years ago

I've confirmed this bug on two Virtual Machines and on one real machine
(laptop). Often an argument of 10000 is enough, too.
This can be used by a non-privileged user to crash the system.

Actions #2

Updated by alexh almost 15 years ago

I've reduced the test case (not attached) to just create many many pthreads
doing readdir, as before, but without the exits and printfs.
There seems to be no panic when linked against libc_r, ONLY with libthread_xu.

Actions #3

Updated by alexh almost 15 years ago

NB: readdir can be substituted by anything else, for example for(;;) sleep(1);

Actions #4

Updated by alexh almost 15 years ago

As suggested by aggelos, added dump of /proc/pid/map with one thread less than
the required to crash (argument is 7133, so 7134 threads created).

Actions #5

Updated by alexh almost 15 years ago

new test case I'm using. Remember to compile with -lthread_xu, as it only seems
to affect this lib.

Actions #6

Updated by aoiko almost 15 years ago

fixed by dillon@ in 85d25bcf562abac1b78f0828f44e3cc7e67e93fa

Actions

Also available in: Atom PDF