Incorrect usage of dirname() in sysdep/unix/main.c causes segfault
According to POSIX, dirname() is allowed to modify the string passed to it. In fact, according to dirname(3), glibc's will do just that when libgen.h is in use. The manpage even warns you that it will segfault when passed a constant that cannot be modified... Well, I hit that bug and it took a while to track it down. --enable-debug seems to link a different dirname() that is less crappy, so the bug wouldn't show up in debug builds. The attached patch explains it better. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
On Sun, Mar 18, 2012 at 10:53:32AM -0300, Henrique de Moraes Holschuh wrote:
According to POSIX, dirname() is allowed to modify the string passed to it. In fact, according to dirname(3), glibc's will do just that when libgen.h is in use. The manpage even warns you that it will segfault when passed a constant that cannot be modified...
Well, I hit that bug and it took a while to track it down. --enable-debug seems to link a different dirname() that is less crappy, so the bug wouldn't show up in debug builds.
The attached patch explains it better.
Thanks, merged. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Mon, 19 Mar 2012, Ondrej Zajicek wrote:
On Sun, Mar 18, 2012 at 10:53:32AM -0300, Henrique de Moraes Holschuh wrote:
According to POSIX, dirname() is allowed to modify the string passed to it. In fact, according to dirname(3), glibc's will do just that when libgen.h is in use. The manpage even warns you that it will segfault when passed a constant that cannot be modified...
Well, I hit that bug and it took a while to track it down. --enable-debug seems to link a different dirname() that is less crappy, so the bug wouldn't show up in debug builds.
The attached patch explains it better.
Thanks, merged.
Thank you. FYI, I have since discobered that this patch fixed another issue: when multiple "include" statements were processed, relative paths were being corrupted: each include statement processed would remove one path component from config_name, thus: config /etc/binr/bird.conf include "foo" include "bar" include "baz" would try to read: /etc/bird/bird.conf, /etc/bird/foo, /etc/bar, and finally /baz. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
participants (2)
-
Henrique de Moraes Holschuh -
Ondrej Zajicek