*Lethal* 2.2.x and 2.3.x core dump lockup bug (SMP specific?)

Duncan Simpson (dps@io.stargate.co.uk)
Sat, 19 Jun 1999 17:28:45 +0100


Can anyone tell me were signals are actually delviered? A function that
does it and source file would be appropiate, especially if you can
give me a line number too. kernel/signal.c seems to have functions to
do everything else, and I guess that t->sigpending becomes one when
someone successfully sends you a signal. (I can not find the code that
makes STOP and KILL immediately lethal either).

The kernels I have interested in are 2.2.x and 2.3.x to try and locate
a lethal bug illistrated by the script bellow. Anything that generates
a core dump inducing signal seems to have the same effect---I think it
is a locking mixup that calls a core dump function which promptly calls
down and everything locks.

I am using a SMP capable kernel on a single P II/350 if it helps. My expoit
program is:

/* segfault generation code */
int main(void)
{
int i;
int c[1];

i=0;
while(1)
c[i++]=42;

/* not reached */
}

alternative exploit programs include gcc-2.95 development sources. The
reasoning is the difference is that it is OK the first time due to
lack of permission to write a core file in the first run but this
fails to save us the second time (where is this check?). 2.2.9 and
2.3.5 die. From the limited testing I have done 2.3.6 is apparently
subject to the same bug. Assuming 2.3.7 lacks a fix the same probably
applies to it too.

I have fixed the mm/mmap.c get_unmapped_area bug which fails to return
a page aligned address which causes do_munmap to die, which then
causes do_mmap to die and loading an ELF shared library to fail. Exploit
programs include /bin/sh linked against glibc 2.1.x

Please cc: replies to dps@io.stargate.co.uk as I can not afford the
time (one of the phone or wall time) to read all of the kernel mailing
list. Methinks the SIGSEGV core dump lockup problem is the sort of
showstopper we can safely leave to Micro$oft operating systems.

(DoS artists could use the bug to permanently fill up your process
table with an appropiate driver program but I will not give the script
kiddies one myself).

Duncan (-:

Script started on Sat Jun 19 15:08:30 1999
/home/admin$ id
uid=405(dps) gid=6(users) groups=6(users),8(cd),14(uucp)
/home/admin$ ls -ld .
drwxrwxr-x 15 admin adm 2048 Jun 19 13:16 .
/home/admin$ strace ./seggie
execve("./seggie", ["./seggie"], [/* 24 vars */]) = 0
<stuff snipped>
getpid() = 256
brk(0) = 0x804a318
brk(0x804a4b8) = 0x804a4b8
brk(0x804b000) = 0x804b000
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
/home/admin$ su admin
Password:
~$ starce ./seggie &
uid=406(admin) gid=1(adm) groups=1(adm),6(users),7(tty),8(cd),14(uucp)
~$ strace ./seggie &
[1] 259
~$ execve("./seggie", ["./seggie"], [/* 24 vars */]) = 0
<stuff snipped>
getpid() = 260
brk(0) = 0x804a318
brk(0x804a4b8) = 0x804a4b8
brk(0x804b000) = 0x804b000
--- SIGSEGV (Segmentation fault) ---
<rest of script snipped>

/home/admin$ exit
ps auxw shows
<stuff snipped>
admin 259 0.0 0.8 1288 536 ? S 15:09 0:00 strace ./seggie
admin 260 0.0 0.4 1040 304 ? D 15:09 0:00 * *
<stuff snipped>

ps alxw shows
FLAGS UID PID PPID PRI NI SIZE RSS WCHAN STA TTY TIME COMMAND
<stuff snipped>
30 406 260 259 0 0 1040 304 down_failed D ? 0:00 * *
<stuff snipped>

which points a finger at the core dump code or the signal code.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/