Re: [Tinycc-devel] Segmentation fault in tccelf.c:2189, strcmp - bugfix, i think

[Diego Bauche Madero]

Evan Langlois wrote:

>On Tue, 2005-10-25 at 21:25 -0400, Diego Bauche Madero wrote:
>
>  
>
>>As you can see, `name' points to the address i said, and of course, being not 
>>an accesable address, the program just sends SIGSEGV.
>>Anyway, the core file and tcc ELF executable binary (compiled with glibc 
>>2.3.4) can be found at http://genexx.org/tcc_strcmp.tbz2
>>    
>>
>
>The question isn't if name is that address or not, the question is why
>isn't that address within the application's memory map.
>
>  
>
Oh, i got your point.

>>$ tcc -IGL /usr/X11R6/lib/libX11.so.6 /usr/X11R6/lib/libXext.so.6
>>/usr/X11R6/lib/libGLU.so /usr/X11R6/lib/libglut.so.3 -lGL -IGLU -lm -o
>>libellenbeck-fract libellenbeck-fract.c
>>Segmentation fault
>>$ gcc -IGL /usr/X11R6/lib/libX11.so.6 /usr/X11R6/lib/libXext.so.6
>>/usr/X11R6/lib/libGLU.so /usr/X11R6/lib/libglut.so.3 -lGL -IGLU -lm -o
>>libellenbeck-fract libellenbeck-fract.c
>>    
>>
>
>Well, it would seem to be a bug.  However, rogue pointers can cause
>really odd problems that may work on some systems and not others, or may
>only show on certain compilation or optimization options, etc.
>
>Can you narrow down the issue into a smaller test case, preferably
>without all the library dependancies?  Is the source available?  Its
>usually easier to look at the source than trying to look through a core
>file.
>
>-- Evan
>
>  
>
I've been looking into it a little bit, this bug is easy to reproduce.

This is very small test case:
First of all, i've seen that this has nothing to do with my code or
specific code inside the specific libraries i was using.

Apparently, if the shared libraries are compiled with gcc (i have tried
two versions, 3.3 and 4.0.1) tcc faults, but if they are compiled with
tcc, it wont:

fault:
----
cd /usr/lib
gcc -shared -o ./1.so /tmp/1.c
gcc -shared -o ./2.so /tmp/2.c
gcc -shared -o ./3.so /tmp/2.c
gcc -shared -o ./3.so /tmp/3.c
gcc -shared -o ./4.so /tmp/4.c
gcc -shared -o ./foo.so /tmp/foo.c 1.so 2.so 3.so 4.so
tcc /usr/lib/foo.so
----


and source codes:
1.c: int a;
2.c: int b;

3.c: int c;
4.c: int d;
foo.c: main() {}


I think gcc is doing something weird with the SHT_DYNAMIC section of a
shared library object (though it could be a tinyc bug somewhere else, i
don't know).

in tccelf:2125
        case SHT_DYNAMIC:
            nb_dts = sh->sh_size / sizeof(Elf32_Dyn);
            dynamic = load_data(fd, sh->sh_offset, sh->sh_size);
            break;

of course, `dynamic' gets the section memory, `nb_dts' has the number of
times to read the dynamic section entries over the for() loop that
checks if the referenced dll is already loaded and if not, it gets
loaded, etc.

The problem here is that when /usr/lib/4.so gets read, for some strange
cause the dynamic section over the shared library object appears to have
more memory to what it is supossed to have. Here's a test (i added the
debugging messages inside the "for(i = 0; i < s1->nb_loaded_dlls; i++)
{" loop btw) :

----
localhost lib # ~rewt/tcc-0.9.23/tcc /usr/lib/foo.so
[...]
loading dll '4.so'
[...]
Trying to access to 0x8080ac9 (Being dynstr 0x8080a68, dt 0x8080748,
dt->d_un 00000061 and dt->d_un.d_val = 97 and dt->d_tag 1
Trying to access to 0x74356ed4 (Being dynstr 0x8080a68, dt 0x8080810,
dt->d_un 6c2d646c and dt->d_un.d_val = 1814914156 and dt->d_tag 1
Segmentation fault
----
So, the last dynamic section entry APPEARS to contain bogus memory. This
could be some internal tinyc bug, but i wouldn't count on that, because
if i compile the shared library objects using tcc itself, it doesn't fault.

To make the story short, i tried this on several machines, just do the
test yourself.
Anyhow, here's a quick fix (on the last cvs revision) to deal with this
odd case:

--- tinycc-orig/tccelf.c        2005-10-27 02:43:35.000000000 -0400
+++ tinycc/tccelf.c     2005-10-27 02:55:19.000000000 -0400
@@ -2184,6 +2184,8 @@ static int tcc_load_dll(TCCState *s1, in
         switch(dt->d_tag) {
         case DT_NEEDED:
             name = dynstr + dt->d_un.d_val;
+            if ((Elf32_Dyn *)name > dynamic + (nb_dts * sizeof(Elf32_Dyn)))
+                goto the_end;
             for(i = 0; i < s1->nb_loaded_dlls; i++) {
                 dllref = s1->loaded_dlls[i];
                 if (!strcmp(name, dllref->name))



>
>_______________________________________________
>Tinycc-devel mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
>
>  
>

Cheers
- Diego Bauche Madero