Bug 162522 - _FORTIFY_SOURCE breaks sprintf(buffer, "%s%s", buffer, blah)
Summary: _FORTIFY_SOURCE breaks sprintf(buffer, "%s%s", buffer, blah)
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc   
(Show other bugs)
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-07-05 20:02 UTC by Nicholas Miell
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-05 20:05:59 UTC
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 20:02 UTC, Nicholas Miell
no flags Details

Description Nicholas Miell 2005-07-05 20:02:06 UTC
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 20:02:06 UTC
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 20:05:59 UTC
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.