Bug#249986: ld.so crashes by SEGV on custom kernel
At Thu, 20 May 2004 12:53:54 +0400,
Alexander Gordeyev wrote:
> 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:
Cheers nice work :)
> 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.
You may get the different result with the latest glibc 2.3.2.ds1
instead of 2.2.5 old woody version.
BTW, I wonder why you don't emulate such execve behavior?
> 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.
Dynamic routine should always work fast.
Regards,
-- gotom
Reply to: