In __stack_smash_handler of sys-libs/glibc/files/2.3.3/ssp.c, log = SOCK_DGRAM. This of course does not work if the system syslogd is listening to SOCK_STREAM. Reproducible: Always Steps to Reproduce: 1. Configure syslogd to listen to SOCK_STREAM. 2. Trigger a stack overflow. 3. Actual Results: With this configuration the stack protector will be unable to log events. Expected Results: The stack protector is expected to log overflows using the syslog facility. I suggest using libc's syslog(3) function call because it will use SOCK_STREAM and SOCK_DGRAM in turn, possibly others. This code works with Glibc: #include <syslog.h> void __stack_smash_handler (char func[], int damaged) { const char message[] = "stack overflow in function %s"; struct sigaction sa; sigset_t mask; /* Immediately block all signal handlers from running code */ sigfillset(&mask); sigdelset(&mask, SIGABRT); sigprocmask(SIG_BLOCK, &mask, NULL); /* This may fail on a chroot jail... */ syslog(LOG_CRIT, message, func); bzero(&sa, sizeof(struct sigaction)); sigemptyset(&sa.sa_mask); sa.sa_flags = 0; sa.sa_handler = SIG_DFL; sigaction(SIGABRT, &sa, NULL); kill(getpid(), SIGABRT); _exit(127); }
good idea. I know another problem exists in the syslog handling of ssp. ahess you should stop by the norm chan and talk about 3.4.x & ssp, there are other problems which you might want to know/talk about that effect us all.
ok, this idea was merged into uClibc a while ago and i've finally merged it into glibc-2.3.5 thanks :)
