SEGFPE error in old ld when trying to run a binary - c

Question

I am trying to compile binaries with heap vulnerabilities to practice binary exploitation. To do so, I need an old version of the libc so that doesn't have all the security checks the modern ones do.
I have on my computer a glibc-2.3.2.so file and a ld-2.3.2.so file. I made a small test program -
7 int main()
8 {
9 char * first, *second;
10 first = malloc(0x40);
11 read(0,first,0x40);
12 free(first);
13 second = malloc(0x40);
14 ((void (*)())second)();
15
16 }
(The only thing not included are #include <stdlib.h> and #include <unistd.h>)
I turned the c file into a .o file with the command
gcc -c firstFit.c -m32
Then, I used g++ for the linking, specifying the old glibc.
g++ firstFit.o -o firstFit -Wl,--rpath=`pwd` -Wl,--dynamic-linker=`pwd`/ld-2.3.2.so -m32
It compiles just fine. However, when I try to run the file there is a floating point exception.
[1] 169605 floating point exception (core dumped) ./firstFit
I ran it under gdb to see where and
→ 0xf7fe9572 div DWORD PTR [ecx+0x164]
Using the gdb backtrace command
#0 0xf7fe9572 in ?? () from /home/zac/programming/cybersec/ctfPrepChalls/heap/ld-2.3.2.so
#1 0xf7ff6abd in ?? () from /home/zac/programming/cybersec/ctfPrepChalls/heap/ld-2.3.2.so
#2 0xf7fe8f13 in ?? () from /home/zac/programming/cybersec/ctfPrepChalls/heap/ld-2.3.2.so
#3 0xf7fe8c27 in ?? () from /home/zac/programming/cybersec/ctfPrepChalls/heap/ld-2.3.2.so
Why would ld be have a floating point error? How would I go about fixing this?
Help is appreciated

Answer 1

Then, I used g++ for the linking, specifying the old glibc.
g++ firstFit.o -o firstFit -Wl,--rpath=pwd -Wl,--dynamic-linker=pwd/ld-2.3.2.so -m32
One of the following two reasons very likely explains your crash:
You do not have complete installation of GLIBC-2.3.2 in your current directory.
In particular, g++ will link against libm.so.6, and if you end up using system libm.so.6 with $(pwd)/libc.so.6, you are very likely to have trouble (mixing bits of GLIBC which came from different builds is a no-no).
You link against system libstdc++.so.6, which has DT_GNU_HASH and no DT_HASH.
GLIBC-2.3.2 is old enough not to support GNU_HASH.
I expect the issue#2 is most likely explanation for SIGFPE.
You can confirm either of these by running
env LD_TRACE_LOADED_OBJECTS=1 ./firstFit
to find loaded objects (do not use ldd, it will lie to you), and looking at the output from:
readelf -d ./firstFit | grep HASH
readelf -d /path/to/libstdc++.so.6 | grep HASH

Answer 2

so, here is the program that only returns 0:
int main( void )
{
return 0;
}
compiling the program
gcc -ggdb3 -Wall -Wextra -Wconversion -pedantic -std=gnu11 -c "untitled1.c" -o "untitled1.o"
Compilation finished successfully.
linking the program (using gcc, not g++)
gcc -ggdb3 -o "untitled1" "untitled1.o"
Compilation finished successfully.
running the program:
./untitled1
(nothing output)
Suggest: don't mix gcc and g++ for the same program