bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

vasnprintf's "%n in writable segment" chokes with _FORTIFY_SOURCE == 2


From: Jim Meyering
Subject: vasnprintf's "%n in writable segment" chokes with _FORTIFY_SOURCE == 2
Date: Thu, 18 Oct 2007 11:21:38 +0200

Hi Bruno,

When I build a coreutils snapshot with -D_FORTIFY_SOURCE=2 on a
relatively recent fedora-based system, seq always aborts like this:

    $ ./seq 1
    *** %n in writable segment detected ***
    1zsh: abort      ./seq 1
    [Exit 134 (ABRT)]

That is due to the fact that vasnprintf writes %n into a format
string that is subsequently used by snprintf.
And why is that done?  For portability to crufty systems on which
s*printf doesn't even return a valid count.

But the particular bug that code is working around doesn't
even affect glibc's snprintf function.

This is why gnulib should be written to rely on posix- (or c99-)
compliant functions whenever possible: so that conforming systems
aren't penalized.  I haven't looked closely enough, but perhaps
vasnprintf itself could require snprintf-posix?  It looks like
that might induce a dependency loop, though, since the snprintf-posix
module uses vasnprintf.c.

Here's a minimal change to avoid using %n in this specific case.
It works because there is already code to handle the case in which
there is no %n directive, i.e., when fbp[1] == '\0'.

Another approach is to avoid using %n with any glibc-based system.

diff --git a/lib/vasnprintf.c b/lib/vasnprintf.c
index f563823..9692562 100644
--- a/lib/vasnprintf.c
+++ b/lib/vasnprintf.c
@@ -3384,7 +3384,7 @@ VASNPRINTF (DCHAR_T *resultbuf, size_t *lengthp,
                else
 #endif
                  *fbp = dp->conversion;
-#if USE_SNPRINTF
+#if USE_SNPRINTF && _FORTIFY_SOURCE != 2
                fbp[1] = '%';
                fbp[2] = 'n';
                fbp[3] = '\0';




reply via email to

[Prev in Thread] Current Thread [Next in Thread]