R14B01: buffer overflow detected during compilation with -D_FORTIFY_SOURCE=2 (x86_64)

[Nico Kruber]

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):

*** buffer overflow detected ***: /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x2b64930b0067]
/lib64/libc.so.6(+0xe4e10)[0x2b64930ade10]
/usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x584047]
/usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp(erts_write_to_port+0x97f)[0x4946ef]
/usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x50fcb9]
/usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp(process_main+0x2eba)[0x53b36a]
/usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x4a1772]
/usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x5aee94]
/lib64/libpthread.so.0(+0x6a4f)[0x2b6492ba8a4f]
/lib64/libc.so.6(clone+0x6d)[0x2b649309982d]


Setting  -D_FORTIFY_SOURCE=1 allows erlang to be build but the buffer overflow is probably still there and dangerous...
R14B did not show this behaviour.

Additionally, could you correct the dependencies in the makefiles in order to allow make -j2 and higher?


Regards
Nico Kruber

[Christian Faulhammer]

Hi,

Nico Kruber <[hidden email]>:
> Setting  -D_FORTIFY_SOURCE=1 allows erlang to be build but the buffer
> overflow is probably still there and dangerous... R14B did not show
> this behaviour.

 Maybe this hides a security problems?
 
> Additionally, could you correct the dependencies in the makefiles in
> order to allow make -j2 and higher?

 Is this safe now?  Gentoo builds with -j1 for ages because of problems
reported with Erlang 11.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[Nico Kruber]

On Tuesday 14 December 2010 13:17:43 Christian Faulhammer wrote:
> Hi,
>
> Nico Kruber <[hidden email]>:
> > Setting  -D_FORTIFY_SOURCE=1 allows erlang to be build but the buffer
> > overflow is probably still there and dangerous... R14B did not show
> > this behaviour.
>
>  Maybe this hides a security problems?

that's what I suspected, too (it merely hides the error)

> > Additionally, could you correct the dependencies in the makefiles in
> > order to allow make -j2 and higher?
>
>  Is this safe now?  Gentoo builds with -j1 for ages because of problems
> reported with Erlang 11.

no - I tried with -j2 and it does not work yet :(

[Christian Faulhammer]

Hi,

Nico Kruber <[hidden email]>:
> 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):
[...]
> Setting  -D_FORTIFY_SOURCE=1 allows erlang to be build but the buffer
> overflow is probably still there and dangerous... R14B did not show
> this behaviour.

As you can see, a lot of people are hitting this problem on Gentoo:

 https://bugs.gentoo.org/show_bug.cgi?id=348559

Is there a fix available already somewhere?

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[Kenneth Lundin]

Hi,

Some questions

Has -D_FORTIFY_SOURCE been tried on R14B as well and did not show any
buffer overflow?
I am asking because we are running Valgrind extensively before every
release and shouldn't
buffer overflows be detected there as well?

As I understand it -D_FORTIFY_SOURCE is a patch to GCC developed by Redhat and
=2 can also report buffer flow for code that is correct.

If this buffer overflow indeed is a real bug then of course we want to
find it and correct it.

/Kenneth Erlang/OTP Ericsson

On Tue, Dec 14, 2010 at 11:57 AM, Nico Kruber <[hidden email]> wrote:

> 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):
>
> *** buffer overflow detected ***: /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp terminated
> ======= Backtrace: =========
> /lib64/libc.so.6(__fortify_fail+0x37)[0x2b64930b0067]
> /lib64/libc.so.6(+0xe4e10)[0x2b64930ade10]
> /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x584047]
> /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp(erts_write_to_port+0x97f)[0x4946ef]
> /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x50fcb9]
> /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp(process_main+0x2eba)[0x53b36a]
> /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x4a1772]
> /usr/src/packages/BUILD/otp_src_R14B01/bin/x86_64-unknown-linux-gnu/beam.smp[0x5aee94]
> /lib64/libpthread.so.0(+0x6a4f)[0x2b6492ba8a4f]
> /lib64/libc.so.6(clone+0x6d)[0x2b649309982d]
>
>
> Setting  -D_FORTIFY_SOURCE=1 allows erlang to be build but the buffer overflow is probably still there and dangerous...
> R14B did not show this behaviour.
>
> Additionally, could you correct the dependencies in the makefiles in order to allow make -j2 and higher?
>
>
> Regards
> Nico Kruber
>

________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

[Christian Faulhammer]

Hi,

Kenneth Lundin <[hidden email]>:
> Has -D_FORTIFY_SOURCE been tried on R14B as well and did not show any
> buffer overflow?

 There would have been reports (I maintain the package for Gentoo,
where users build the package on their system)...and there were none.
We use FORTIFY_SOURCE for some time now.

> As I understand it -D_FORTIFY_SOURCE is a patch to GCC developed by
> Redhat and =2 can also report buffer flow for code that is correct.

 It is included in the trunk version and used by many distributions
nowadays, especially for the server/hardened systems.

> If this buffer overflow indeed is a real bug then of course we want to
> find it and correct it.

 Would be nice.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[Nico Kruber]

On Tuesday 21 December 2010 11:56:31 Christian Faulhammer wrote:
> Kenneth Lundin <[hidden email]>:
> > Has -D_FORTIFY_SOURCE been tried on R14B as well and did not show any
> > buffer overflow?
>
>  There would have been reports (I maintain the package for Gentoo,
> where users build the package on their system)...and there were none.
> We use FORTIFY_SOURCE for some time now.

I can second this for openSUSE 11.3 - FORTIFY_SOURCE has been used before and R14B did not show this overflow (as mentioned in my first email)

> > As I understand it -D_FORTIFY_SOURCE is a patch to GCC developed by
> > Redhat and =2 can also report buffer flow for code that is correct.
>
>  It is included in the trunk version and used by many distributions
> nowadays, especially for the server/hardened systems.
>
> > If this buffer overflow indeed is a real bug then of course we want to
> > find it and correct it.
>
>  Would be nice.

[Björn-Egil Dahlberg]

Hi,

I am trying to reproduce this error, but I am sad to say that I seem to
be missing something. Now, I am not a build environment expert but this
should be straight forward right?

First off, this is otp_src_R14B01 with no distribution specific patches
applied? Seems unlikely, since both Gentoo and openSUSE hits this error.

Now, I don't have any gentoo or opensuse x86_64 available, I have a
32-bit gentoo which doesn't seem to produce this error (i didn't expect
it to), and plenty of SuSE sled/sles 10.1 - 2 x86_64, which doesn't have
the compiler.

I do have some newer x86_64 Ubuntu's so I tried with gcc (Ubuntu
4.4.3-4ubuntu5) 4.4.3. This compiler should have the fortify sources
patch (default since 9.10). -D_FORTIFY_SOURCE=2 shouldn't be needed
since -02 and higher implies this option. A small testprogram confirms
that -02 and memcpy check works anyways.

But, No luck.

I tried emulating what Nico did in his build script, like this,
 > tar -zxvf otp_src_R14B01.tar.gz
 > cd otp_src_R14B01
 >  export ERL_TOP=`pwd`
 >  export 'CFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector -funwind-tables -fasynchronous-unwind-tables
-fno-strict-aliasing'
 >  export 'CXXFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector -funwind-tables -fasynchronous-unwind-tables
-fno-strict-aliasing'
 >  export FFLAGS='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector -funwind-tables -fasynchronous-unwind-tables'
 >  ./configure --host=x86_64-unknown-linux-gnu
--build=x86_64-unknown-linux-gnu --with-ssl=/usr --enable-threads
--enable-smp-support --enable-kernel-poll --enable-hipe --enable-shared-zlib
 > ulimit -c unlimited
 > make

No errors, all is great.


So something is wrong. Either in the assumptions or the setup.
Everything from stack-protectors, valgrind and other fortifications says
everything is fine.

Is the error consistent? Does it appear everytime and on the same file?
hipe_rtl.erl? It should anyways.

Could someone please give me some pointers on how to reproduce this?

// Björn-Egil
    Erlang/OTP



On 2010-12-21 11:56, Christian Faulhammer wrote:

> Hi,
>
> Kenneth Lundin<[hidden email]>:
>> Has -D_FORTIFY_SOURCE been tried on R14B as well and did not show any
>> buffer overflow?
>
>   There would have been reports (I maintain the package for Gentoo,
> where users build the package on their system)...and there were none.
> We use FORTIFY_SOURCE for some time now.
>
>> As I understand it -D_FORTIFY_SOURCE is a patch to GCC developed by
>> Redhat and =2 can also report buffer flow for code that is correct.
>
>   It is included in the trunk version and used by many distributions
> nowadays, especially for the server/hardened systems.
>
>> If this buffer overflow indeed is a real bug then of course we want to
>> find it and correct it.
>
>   Would be nice.
>
> V-Li
>

________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

[Nico Kruber]

I also tried with a clean R14B01 (without distro-patches and without all the build service "overhead" from the log I provided, e.g. environment variables) - same result.

so I just used this (openSUSE 11.3, x86_64, dual-core CPU, GCC is 4.5.0_20100604-1.12):

./configure --with-ssl=/usr --enable-threads --enable-smp-support --enable-kernel-poll --enable-hipe --enable-shared-zlib
make

If you can access the openSUSE BuildService, you can exactly reproduce the environment I (normally) built my packages on:
(you can install the osc command line client from a repository in http://software.opensuse.org/download/openSUSE:/Tools/ available for a lot of distributions)

osc checkout home:tschuett erlang
cd home\:tschuett/erlang
osc build --ccache openSUSE_11.3 erlang.spec

(--ccache is just for performance in case of re-compilation)

It will download all rpms required to build the package and set up a chroot environment for it.
You can remove the distribution specific patches as well as my workaround setting D_FORTIFY_SOURCE=1 in the .spec file.

The error message is _always_ there and always in the same file.

Nico

On Wednesday 22 December 2010 14:37:38 Björn-Egil Dahlberg wrote:

> Hi,
>
> I am trying to reproduce this error, but I am sad to say that I seem to
> be missing something. Now, I am not a build environment expert but this
> should be straight forward right?
>
> First off, this is otp_src_R14B01 with no distribution specific patches
> applied? Seems unlikely, since both Gentoo and openSUSE hits this error.
>
> Now, I don't have any gentoo or opensuse x86_64 available, I have a
> 32-bit gentoo which doesn't seem to produce this error (i didn't expect
> it to), and plenty of SuSE sled/sles 10.1 - 2 x86_64, which doesn't have
> the compiler.
>
> I do have some newer x86_64 Ubuntu's so I tried with gcc (Ubuntu
> 4.4.3-4ubuntu5) 4.4.3. This compiler should have the fortify sources
> patch (default since 9.10). -D_FORTIFY_SOURCE=2 shouldn't be needed
> since -02 and higher implies this option. A small testprogram confirms
> that -02 and memcpy check works anyways.
>
> But, No luck.
>
> I tried emulating what Nico did in his build script, like this,
>  > tar -zxvf otp_src_R14B01.tar.gz
>  > cd otp_src_R14B01
>  >  export ERL_TOP=`pwd`
>  >  export 'CFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
> -fstack-protector -funwind-tables -fasynchronous-unwind-tables
> -fno-strict-aliasing'
>  >  export 'CXXFLAGS=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
> -fstack-protector -funwind-tables -fasynchronous-unwind-tables
> -fno-strict-aliasing'
>  >  export FFLAGS='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
> -fstack-protector -funwind-tables -fasynchronous-unwind-tables'
>  >  ./configure --host=x86_64-unknown-linux-gnu
> --build=x86_64-unknown-linux-gnu --with-ssl=/usr --enable-threads
> --enable-smp-support --enable-kernel-poll --enable-hipe --enable-shared-zlib
>  > ulimit -c unlimited
>  > make
>
> No errors, all is great.
>
>
> So something is wrong. Either in the assumptions or the setup.
> Everything from stack-protectors, valgrind and other fortifications says
> everything is fine.
>
> Is the error consistent? Does it appear everytime and on the same file?
> hipe_rtl.erl? It should anyways.
>
> Could someone please give me some pointers on how to reproduce this?
>
> // Björn-Egil
>     Erlang/OTP
>
>
>
> On 2010-12-21 11:56, Christian Faulhammer wrote:
> > Hi,
> >
> > Kenneth Lundin<[hidden email]>:
> >> Has -D_FORTIFY_SOURCE been tried on R14B as well and did not show any
> >> buffer overflow?
> >
> >   There would have been reports (I maintain the package for Gentoo,
> > where users build the package on their system)...and there were none.
> > We use FORTIFY_SOURCE for some time now.
> >
> >> As I understand it -D_FORTIFY_SOURCE is a patch to GCC developed by
> >> Redhat and =2 can also report buffer flow for code that is correct.
> >
> >   It is included in the trunk version and used by many distributions
> > nowadays, especially for the server/hardened systems.
> >
> >> If this buffer overflow indeed is a real bug then of course we want to
> >> find it and correct it.
> >
> >   Would be nice.
> >
> > V-Li

[Christian Faulhammer]

Hi,

Björn-Egil Dahlberg <[hidden email]>:
> I am trying to reproduce this error, but I am sad to say that I seem
> to be missing something. Now, I am not a build environment expert but
> this should be straight forward right?

 It might be depending on GCC 4.5.  4.4 seems fine.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[Björn-Egil Dahlberg-2]

My thoughts too.
// Björn-Egil

Skickat från min iPhone

22 dec 2010 kl. 17:17 skrev Christian Faulhammer <[hidden email]>:

> Hi,
>
> Björn-Egil Dahlberg <[hidden email]>:
>> I am trying to reproduce this error, but I am sad to say that I seem
>> to be missing something. Now, I am not a build environment expert but
>> this should be straight forward right?
>
> It might be depending on GCC 4.5.  4.4 seems fine.
>
> V-Li
>
> --
> Christian Faulhammer, Gentoo Lisp project
> <URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
>
> <URL:http://gentoo.faulhammer.org/>

________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

[Christian Faulhammer]

Hi,

Nico Kruber <[hidden email]>:

> 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

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[Kostis Sagonas-2]

Christian Faulhammer wrote:

> Hi,
>
> Nico Kruber <[hidden email]>:
>
>> 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.

Kostis

________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

[Mikael Pettersson-3]

Kostis Sagonas writes:
 > Christian Faulhammer wrote:
 > > Hi,
 > >
 > > Nico Kruber <[hidden email]>:
 > >
 > >> 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.

________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

[Mikael Pettersson-3]

Mikael Pettersson writes:
 > 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.

FWIW, I've just managed to reproduce the fortify error, by compiling
otp_src_R14B01 with gcc-4.5.2 on CentOS 5 / x86_64.

I did not get the fortify error with otp_src_R14B.

________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

[Mikael Pettersson-3]

Mikael Pettersson writes:
 > Mikael Pettersson writes:
 >  > 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.
 >
 > FWIW, I've just managed to reproduce the fortify error, by compiling
 > otp_src_R14B01 with gcc-4.5.2 on CentOS 5 / x86_64.
 >
 > I did not get the fortify error with otp_src_R14B.

The problem is that the Erlang VM (efile_drv.c line 3074 for the
current bug) fakes variable length arrays via the equivalent of:

    struct blah { ... ; char n[1]; };
    size_t n = sizeof(struct blah) - 1 + strlen(s) + 1;
    struct blah *p = malloc(n);
    strcpy(p->n, s);

At the strcpy() the length of p->n is known to be 1, so if strlen(s) > 1
the (false positive) out-of-bounds error is generated.

I'm surprised that using memcpy() instead "fixes" this; presumably
gcc and/or glibc does weaker checks on memcpy()s.

Doing variable-length arrays properly one should say 'char n[];',
and use offsetof() instead of sizeof() - 1, but that probably requires
GNU C or C1x.

(The sizeof() - 1 is wrong anyway, because in the real type there's a
nested union involved, and there's no guarantee that &n[0] is the last
byte of the surrounding struct, so there may be some over-allocation.)

/Mikael

________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

[pan]

Hi,

I've looked into it and found what _FORTIFY_SOURCE does not like.

The construct name[1] is as Mikael explained to later dynamically allocate
larger arrays, a common "trick" used throughout the VM to allow structures
with different sized buffers. C99 allows structures to contain arrays with
*no* size last in a struct, but the VM is not written in C99, as Mikael
also correctly pointed out. We are however discussing using this C99
feature in future releases as very few people use a gcc or a MSVC++ that
is too old to have that feature. GCC i think has all of C99 implemented
and so does MSVC++, at least in the latest release. One of the reasons to
use [] instead of [1] is the over-allocation Mikael pointed out, which
happens regardless of unions as the sizeof() struct returns an aligned
size.

Anyway, the problem here is that the name field is actually not the last
field in the struct, which is plain wrong. It does not actually produce
any real buffer overflow, but the member b of the surrounding struct is
the one which should be used for the dynamic buffer. This is old code that
is really strange, but has worked despite that (b is never accessed when
name is used, so it only generates even more over-allocation). It now got
exposed as I started to use strcpy on the field when i implemented unicode
filenames. Didn't notice the strange name field when i rewrote it though.

So - it is in reality no buffer overflow. In fact, given that the last
field is used, as the code intended, -D_FORTIFY_SOURCE allows this kind of
constructs. It does not complain if the last member of a structure is
indexed outside it's bounds and the actually allocated area is large
enough.

So, any workaround to silence -D_FORTIFY_SOURCE will do the trick, there
is no real buffer overflow. I've made the change to use the "b" field for
this callback and removed the strange "name" field in the union, which
also makes _FORTIFY_SOURCE happy and makes the code in some way more
understandable. Changing to the C99 way will be made in the future, when
I'm sure it wont cause problems for people with strange/old platforms out
there. That change will however touch a lot of structures in the VM as
this kind of code is used at several places (for performance reasons).

The change that fixes this will be visible at github as soon as out daily
builds has accepted it, most probably before the end of the week.

Cheers,
/Patrik


________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]

[Christian Faulhammer]

Hi,

<[hidden email]>:
> The change that fixes this will be visible at github as soon as out
> daily builds has accepted it, most probably before the end of the
> week.

 At least talking about a bad fix made you create a better one. :)
The fix from https://github.com/erlang/otp/commit/3b7fd1030711ad56fa45d18dc6e0f1d0beee2399
gets applied in Gentoo land, although this is my last action as
maintainer due to work constraints.  Dirkjan Ochtman (djc AT
gentoo.org) takes over.  Bye and thanks for being a really friendly
upstream to all Erlang developers.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[pan]

Hi!

On Tue, 18 Jan 2011, Christian Faulhammer wrote:

> Hi,
>
> <[hidden email]>:
>> The change that fixes this will be visible at github as soon as out
>> daily builds has accepted it, most probably before the end of the
>> week.
>
> At least talking about a bad fix made you create a better one. :)
Yes - it tends to do that :)

> The fix from https://github.com/erlang/otp/commit/3b7fd1030711ad56fa45d18dc6e0f1d0beee2399
> gets applied in Gentoo land, although this is my last action as
> maintainer due to work constraints.  Dirkjan Ochtman (djc AT
> gentoo.org) takes over.  Bye and thanks for being a really friendly
> upstream to all Erlang developers.

Great that it gets applied!
Sorry to hear though that it's your last action as a maintainer.

Cheers,
/Patrik

PS. Welcome Dirkjan! Hope we can make Erlang work great with gentoo! DS.

>
> V-Li
>
> --
> Christian Faulhammer, Gentoo Lisp project
> <URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
>
> <URL:http://gentoo.faulhammer.org/>
>

________________________________________________________________
erlang-bugs (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:[hidden email]