bug-gnulib
[Top][All Lists]
Advanced

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

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


From: Jim Meyering
Subject: Re: vasnprintf's "%n in writable segment" chokes with _FORTIFY_SOURCE == 2
Date: Thu, 18 Oct 2007 13:41:34 +0200

Bruno Haible <address@hidden> wrote:

> Jim Meyering wrote:
>> 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.
>
> Use of %n is valid in ISO C99 and in POSIX.
>
> At least Microsoft's C99 violation [1] [2] returns without processing the
> %n. But letting a program crash for the attempt to use a C99 feature is
> gross.
>
> I haven't seen a valid rationale for this. Not on Microsoft's site.
> [3] is vague. In [4] the real problem is the use of a user-provided string
> as format string.
>
> Can you ask these "Fortify" advocates for some rationale? Cutting down
> innocent features without properly thought-out solution isn't going to win.

%n is most definitely not "innocent".
It is a commonly-exploited feature.

>> This is why gnulib should be written to rely on posix- (or c99-)
>> compliant functions whenever possible: so that conforming systems
>> aren't penalized.
>
> A system that ignores %n or even crashes upon it is not POSIX or C99
> compliant.

That is not relevant to my point.
The fact is that the current implementation in vasnprintf.c
penalizes *all* systems for the sake of the few with snprintf
that don't return a valid count.  Plus, that code is full of
#ifdefs, many of which would disappear if it relied on a
posix-conforming snprintf.




reply via email to

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