[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d314ca1b-87d4-05d5-68fd-51b23e925cb9@nonterra.com>
Date: Mon, 13 Nov 2017 21:43:15 +0100
From: Tobias Koch <tobias.koch@...terra.com>
To: musl@...ts.openwall.com
Subject: Re: diffutils crash in malloc
Hi,
I modify the cross-compiler so that it lets INTERP point to the /tools
folder
INTERP 0x0000000000000238 0x0000000000400238 0x0000000000400238
0x000000000000001f 0x000000000000001f R 0x1
[Requesting program interpreter: /tools/lib/ld-musl-x86_64.so.1]
From all I can tell, the patch works. Thanks a lot, Rich!
Tobias
On 13/11/2017 21:09, Rich Felker wrote:
> On Mon, Nov 13, 2017 at 08:43:50PM +0100, Tobias Koch wrote:
>> Hi,
>>
>> I run two stacks in parallel: the target stack emulated with Qemu
>> and a native stack in the /tools folder. Both are cross-compiled
>> from a glibc-based system. In very simple cases, an application in
>> the tools folder is configured via
>>
>> ../configure --host=x86_64-cross-linux-musl --prefix=/tools
>>
>> The diffutils build system seems to insist on putting libc.so in the
>> needed library section twice. Only the RUNPATH entry I could get rid
>> of via --disable-rpath. An strace of the crashing diff invocation
>> looks like this:
>>
>> execve("/tools/bin/diff", ["/tools/bin/diff", "a", "b"], [/* 33 vars
>> */]) = 0
>> arch_prctl(ARCH_SET_FS, 0x7f5011a98b68) = 0
>> set_tid_address(0x7f5011a98ba0) = 26946
>> open("/tools/lib/libc.so", O_RDONLY|O_CLOEXEC) = 3
>> fcntl(3, F_SETFD, FD_CLOEXEC) = 0
>> fstat(3, {st_mode=S_IFREG|0755, st_size=3816240, ...}) = 0
>> read(3,
>> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\00055\7\0\0\0\0\0"...,
>> 960) = 960
>> mmap(NULL, 2772992, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x7f5011550000
>> mmap(0x7f50117f0000, 20480, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_FIXED, 3, 0xa0000) = 0x7f50117f0000
>> mmap(0x7f50117f2000, 12288, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f50117f2000
>> close(3) = 0
>> munmap(0x7f5011550000, 2772992) = 0
> OK, you've found a bug in the new code for avoiding multiple libc
> instances getting loaded if it happens at program-load time rather
> than via dlopen at runtime. The code that reclaims slack space at the
> edges of the writable LOAD mapping for the newly loaded library runs
> before checking if the library is a duplicate of libc. If it's found
> to be a duplicate, it's unloaded, and the space that was just donated
> to malloc is invalid.
>
> The attached patch should correct the issue. Note that, in order for
> it to help, the copy of musl that's in /lib/ld-musl-x86_64.so.1 needs
> to be updated; it is the only one that is actually running/used. If
> you really want the one in /tools to be used, your $CC or $LDFLAGS
> needs to include -Wl,-dynamic-linker,/tools/lib/ld-musl-x86_64.so.1 or
> similar.
>
> Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
