Launchpad has imported 9 comments from the remote bug at http://sourceware.org/bugzilla/show_bug.cgi?id=7075.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2008-12-07T17:42:25+00:00 Kees Cook wrote: Anders Kaseorg noticed that the use of _FORTIFY_SOURCE breaks a specific use of sprintf (see attached): $ gcc -O0 -o foo foo.c && ./foo not fail $ gcc -O2 -o foo foo.c && ./foo not fail $ gcc -O2 -D_FORTIFY_SOURCE=2 -o foo foo.c && ./foo fail The original report was filed in Ubuntu, where -D_FORTIFY_SOURCE=2 is enabled by default: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/305901 C99 states: The sprintf function is equivalent to fprintf, except that the output is written into an array (specified by the argument s) rather than to a stream. A null character is written at the end of the characters written; it is not counted as part of the returned value. If copying takes place between objects that overlap, the behavior is undefined. The man page does not mention this limitation, and prior to the use of __sprintf_chk, this style of call worked as expected. As such, a large volume of source code uses this style of call: http://web.mit.edu/andersk/Public/sprintf-results It seems that it would make sense to fix __sprintf_chk, or very loudly mention the C99-described overlap-is-undefined behavior in sprintf documentation. Reply at: https://bugs.launchpad.net/glibc/+bug/305901/comments/4 ------------------------------------------------------------------------ On 2008-12-07T17:42:53+00:00 Kees Cook wrote: Created attachment 3095 test case Reply at: https://bugs.launchpad.net/glibc/+bug/305901/comments/5 ------------------------------------------------------------------------ On 2008-12-07T17:49:37+00:00 Andreas Schwab wrote: sprintf(buf, "%sfoo", buf) is UNDEFINED. Reply at: https://bugs.launchpad.net/glibc/+bug/305901/comments/6 ------------------------------------------------------------------------ On 2008-12-07T18:33:34+00:00 Kees Cook wrote: Thanks for the clarification. However, I think it is still a bug that the limitation is not mentioned in the manpage. Reply at: https://bugs.launchpad.net/glibc/+bug/305901/comments/7 ------------------------------------------------------------------------ On 2008-12-07T19:05:38+00:00 Andreas Schwab wrote: Then contact whoever wrote it. Reply at: https://bugs.launchpad.net/glibc/+bug/305901/comments/8 ------------------------------------------------------------------------ On 2008-12-07T22:56:34+00:00 Jakub Jelinek wrote: man 3p sprintf certainly documents it: "If copying takes place between objects that overlap as a result of a call to sprintf() or snprintf(), the results are undefined." Reply at: https://bugs.launchpad.net/glibc/+bug/305901/comments/18 ------------------------------------------------------------------------ On 2008-12-07T23:38:40+00:00 Petr Baudis wrote: I have submitted a patch for linux-manpages: http://thread.gmane.org/gmane.linux.man/639 Reply at: https://bugs.launchpad.net/glibc/+bug/305901/comments/19 ------------------------------------------------------------------------ On 2008-12-19T16:57:40+00:00 Michael Kerrisk wrote: (In reply to comment #6) > I have submitted a patch for linux-manpages: > http://thread.gmane.org/gmane.linux.man/639 I've applied the following patch for man-pages-3.16. --- a/man3/printf.3 +++ b/man3/printf.3 @@ -133,6 +133,17 @@ string that specifies how subsequent arguments (or arguments accessed via the variable-length argument facilities of .BR stdarg (3)) are converted for output. + +C99 and POSIX.1-2001 specify that the results are undefined if a call to +.BR sprintf (), +.BR snprintf (), +.BR vsprintf (), +or +.BR vsnprintf () +would cause to copying to take place between objects that overlap +(e.g., if the target string array and one of the supplied input arguments +refer to the same buffer). +See NOTES. .SS "Return value" Upon successful return, these functions return the number of characters printed (not including the @@ -851,6 +862,26 @@ and conversion characters \fBa\fP and \fBA\fP. glibc 2.2 adds the conversion character \fBF\fP with C99 semantics, and the flag character \fBI\fP. .SH NOTES +Some programs imprudently rely on code such as the following + + sprintf(buf, "%s some further text", buf); + +to append text to +.IR buf . +However, the standards explicitly note that the results are undefined +if source and destination buffers overlap when calling +.BR sprintf (), +.BR snprintf (), +.BR vsprintf (), +and +.BR vsnprintf (). +.\" http://sourceware.org/bugzilla/show_bug.cgi?id=7075 +Depending on the version of +.BR gcc (1) +used, and the compiler options employed, calls such as the above will +.B not +produce the expected results. + The glibc implementation of the functions .BR snprintf () and Reply at: https://bugs.launchpad.net/glibc/+bug/305901/comments/20 ------------------------------------------------------------------------ On 2008-12-24T17:40:22+00:00 Kees Cook wrote: Created attachment 3625 work-around pre-trunc behavior This patch restores the prior sprintf behavior. Looking through _IO_str_init_static_internal seems to indicate that nothing actually requires "s" to lead with a NULL. Is there anything wrong with this work-around, which could be used until the number of affected upstream sources is not quite so large? Reply at: https://bugs.launchpad.net/glibc/+bug/305901/comments/27 ** Changed in: glibc Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nagios-plugins in Ubuntu. https://bugs.launchpad.net/bugs/305901 Title: Intrepid gcc -O2 breaks string appending with sprintf(), due to fortify source patch -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
