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

[Mikael Pettersson]

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