Bug 162522 - _FORTIFY_SOURCE breaks sprintf(buffer, "%s%s", buffer, blah)
_FORTIFY_SOURCE breaks sprintf(buffer, "%s%s", buffer, blah)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-05 16:02 EDT by Nicholas Miell
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-05 16:05:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test program. Compile with and without -D_FORTIFY_SOURCE=1 to demonstrate the problem. (187 bytes, text/plain)
2005-07-05 16:02 EDT, Nicholas Miell
no flags Details

  None (edit)
Description Nicholas Miell 2005-07-05 16:02:06 EDT
I have no idea whether using the same buffer as both a source and the
destination with sprintf is allowed, but the non-fortified version of sprintf in
glibc does the right thing and the fortified version doesn't. Existing programs
depend on the DTRT behavior.

The attached sample program does the following:

[nicholas@entropy bitbucket]$ gcc -Wall -O2 -Wp,-D_FORTIFY_SOURCE=1
fortify_sprintf.c -o fortify_sprintf
[nicholas@entropy bitbucket]$ ./fortify_sprintf
This is broken.
[nicholas@entropy bitbucket]$ gcc -Wall -O2 fortify_sprintf.c -o fortify_sprintf
[nicholas@entropy bitbucket]$ ./fortify_sprintf
This is not broken.
[nicholas@entropy bitbucket]$
Comment 1 Nicholas Miell 2005-07-05 16:02:06 EDT
Created attachment 116381 [details]
Test program. Compile with and without -D_FORTIFY_SOURCE=1 to demonstrate the problem.
Comment 2 Jakub Jelinek 2005-07-05 16:05:59 EDT
Using the same buffer as both a source and the destination triggers undefined
behaviour in both ISO C and POSIX.  Both outputs (as well as any other) are
correct implementations.
See e.g.
http://www.opengroup.org/onlinepubs/009695399/functions/sprintf.html
If copying takes place between objects that overlap as a result of a call to
sprintf() or snprintf(), the results are undefined.

Note You need to log in before you can comment on or make changes to this bug.