[erlang-bugs] R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64)

[Mikael Pettersson]

Kostis Sagonas writes:
 > Christian Faulhammer wrote:
 > > Hi,
 > > 
 > > Nico Kruber <kruber@REDACTED>:
 > > 
 > >> Most distributions nowadays adds the -D_FORTIFY_SOURCE=2 flag during
 > >> package compilation. I tried updating my erlang package (openSUSE
 > >> 11.3, x86_64) from R14B to R14B01 and received the following error
 > >> (also see the attached build.log.fortsource2 - compressed due to its
 > >> file size):
 > > 
 > >  This seems to be specific to 64bit arches as people could reproduce
 > > the problem with GCC 4.4.  PLD Linux offers a fix (so they say, I still
 > > need reports from our users) in
 > >  http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/erlang/erlang-fortify.patch
 > 
 >  From the patch:
 > 
 >    -#  define FILENAME_COPY(To,From) strcpy(To,From)
 >    +#  define FILENAME_COPY(To,From) memcpy(To,From,strlen(From)+1)
 > 
 > and its comment:
 > 
 >    up to R14B01; replace strcpy with memcpy because fortify source
 >    won't allow to strcpy into too short array
 > 
 > it's not at all clear to me why this is a 64-bit specific issue.
 > 
 > It seems that this is (more of) a problem of fortify, which needs fixing 
 > here, not of Erlang/OTP.

Indeed, the above patch makes no sense at all.

If some target array is too short, then that target array needs to be
enlarged, or the copy needs to be truncated or aborted. Using memcpy()
instead is not a "fix".

It's possible that fortify sees a definition of strcpy() that's broken
(say, has an out-of-bounds write), and that that's the problem. But
no-one has shown this to be the case.

If someone thinks there's a buffer overflow, they need to say _where_
it occurs and under what circumstances it occurs.

So far I've only seen "let's silence fortify" type stuff, which based
on the patch above I have no confidence at all in.