Bug #1343

panic: vm_map_entry_link, dup addr map

Added by alexh over 5 years ago. Updated over 5 years ago.

Status:ClosedStart date:
Priority:HighDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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?)

readdir.c Magnifier (1.15 KB) alexh, 04/23/2009 07:44 AM

dump (172 KB) alexh, 04/23/2009 03:00 PM

test5.c Magnifier (709 Bytes) alexh, 04/23/2009 05:40 PM

History

#1 Updated by alexh over 5 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.

#2 Updated by alexh over 5 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.

#3 Updated by alexh over 5 years ago

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

#4 Updated by alexh over 5 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).

#5 Updated by alexh over 5 years ago

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

#6 Updated by aoiko over 5 years ago

fixed by dillon@ in 85d25bcf562abac1b78f0828f44e3cc7e67e93fa

Also available in: Atom PDF