[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#249986: ld.so crashes by SEGV on custom kernel



Package: libc6
Version: 2.2.5-6

I participate in development some kind of Linux emulator under Windows. We
use Debian as packaging system in our project, because I'm reporting
straighit to you (as glibc guys reccomended). The bug (I beleive its the
bug) we met couldn't be reproduced under usual Linux kernels, so I provide
you with details. When I invoke almost any program, it killed by SEGV:


/windrives/c/devel/projects/pd/release#ls
Segmentation fault


Our own strace-like log is quite informative about this:


[14] execve("/bin/ls", ["ls", "-A", "--color=auto"], 0x080db2d0) {
} = 0
Exception 0xc0000005 (ACCESS_VIOLATION) at address 0x00951658 (read from
0x0000001c)
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
     00950000-00963000 r-xp 00000000 00:01 383554 /lib/ld-2.2.5.so
     00963000-00964000 rw-p 00013000 00:01 383554 /lib/ld-2.2.5.so
     08048000-08053000 r-xp 00000000 00:01 383114 /bin/ls
     08053000-08054000 rw-p 0000a000 00:01 383114 /bin/ls
     0fe00000-10000000 rwxp ffffc000 00:00 0


I've done some work and found the bug in $glibc-2.2.5\elf\dynamic-link.h,
_ELF_DYNAMIC_DO_RELOC macro:


struct { ElfW(Addr) start, size; int lazy; } ranges[2]; \

ranges[0].lazy = 0; \

ranges[0].size = ranges[1].size = 0; \

ranges[0].start = 0; \

\



As one can see, `ranges' array is allocated on stack and *not* initialized.
Its ok under native Linux, because just after `execve' system call, process
stack is always cleared and `ranges' always became filled by zeroes. But our
environment can not (should it?) guarantee stack contents, and ranges[1] got
unpredictable values. Well, just few lines later, in conditional branch
where ld combines sections, ranges[1].start and ranges[1].size are crap.

So, I propose to fix _ELF_DYNAMIC_DO_RELOC macro and clear the`ranges'
variable (at least with undefined ELF_MACHINE_PLTREL_OVERLAP macro), since
virtually possible another architecture, where just-after-execve-stack is
not cleared.

PS. If you not interested in this fix, please inform me. Thank you.







Reply to: