On Fri, 2003-04-18 at 00:36, Warren Togami wrote: > libsafe stack protection library seems to have worked well enough as an > optional add-on to Red Hat 6.x through 8.0, but I am able to > consistently reproduce this segmentation fault on Red Hat Linux 9 with > libsafe. This same operation works fine on Red Hat Linux 8.0. > > [root@xxxxxxx:rh9 /]useradd temp2 > Segmentation fault [SNIP] > Could some change in glibc-2.3.2 have broken an assumption that libsafe > makes (thus libsafe needs fixing) or is this exposing a potential flaw > in useradd? This seems to be the only 100% reproducible libsafe induced > crash that I am able to find so far. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89145 Wow... within minutes of me posting, Enrico Scholz discovered use of uninitialized memory in useradd. A short while later he posted this patch that seems to fix the problem. useradd had a flaw, but it wasn't exposed until this combination of glibc-2.3.2 and libsafe. glibc-2.3.2 alone didn't expose the segfault, and older versions of glibc + libsafe didn't either. Interesting. If I understand the libsafe docs properly, it itself isn't supposed to introduce SIGSEGV during runtime, instead SIGKILL when it detects a buffer overflow or format string exploit. Now that I think about it, perhaps libsafe triggered some of the extremely rare random crashes of Gnome components that I began seeing this past week... Perhaps libsafe still works as promised, and combined with the new glibc it also helps you discover subtle bugs otherwised missed before? This seems interesting, I'd like to find out exactly what changed in glibc that exposed this behavior in combination with libsafe. -- Warren Togami Fedora Linux Project warren@xxxxxxxxxx http://www.fedora.us GPG 0x54A2ACF1 3rd party packaging community for Red Hat Linux 785A 304B 08C1 F291 F54F 9A68 6BDD FE8E 54A2 ACF1
Attachment:
signature.asc
Description: This is a digitally signed message part
