Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing

[Bastian Blank <waldi@debian.org>]

On Fri, Sep 20, 2013 at 03:05:37PM -0400, Yaroslav Halchenko wrote:
> long story short -- reason was the combination of optimization (-O1 was enough)
> +  -D_FORTIFY_SOURCE=2 to fall into the "undefined"  darkness of C standard(s)
> in s*printf() functions (man 3 sprintf, search for undefined or NOTES).

So the code is already full of undefined behaviour?

> On "your" code you could look for some (no multiline or more complex
> expressions, no snprintf) hits in sprintf with following grep
> grep -re 'sprintf(\s*\(\w\+\)\s*,[^,]\+,\s*\1\>' *

You search for a sprintf that references the same variable both as
source and destination?

C99 clearly stats:
| If copying takes place between objects that overlap, the behavior is
| undefined.

> To mitigate this issue, besides reporting upstream, for now I had to disable
> this fortification with
> DEB_BUILD_HARDENING_FORTIFY := 0
> preceding inclusion of /usr/share/hardening-includes/hardening.make

I would call code that hits such clear definitions too buggy to be
supported.

> P.S. Written with the sole hope to save someone unpleasant (or even
>      painful) moments of stepping into this issue on your own.

Thats why it is called undefined behaviour.

Bastian

-- 
Beam me up, Scotty!  It ate my phaser!