|
|
Message-ID: <20150709171159.4f08479e@ncopa-desktop.alpinelinux.org>
Date: Thu, 9 Jul 2015 17:11:59 +0200
From: Natanael Copa <ncopa@...inelinux.org>
To: musl@...ts.openwall.com
Subject: dynamic linker issue
Hi,
I have a weird issue with libvirtd segfaulting:
BUG at file position route/tc.c:1009:rtnl_tc_register
Assertion failed: 0 (route/tc.c: rtnl_tc_register: 1009)
Aborted (core dumped)
It happens here:
https://github.com/thom311/libnl/blob/48182486341d1de7892494f272e892c0b18ebef5/lib/route/tc.c#L1008
gdb with a breakpoint showed that to_kind is set, but to_type is definitively wrong:
<ncopa> (gdb) print blackhole_ops
<ncopa> $1 = {to_kind = 0x614d43a1026e "blackhole", to_type = 1136841632, to_size = 0,
<ncopa> to_dump = {0x0, 0x0, 0x0}, to_msg_fill = 0x0, to_msg_fill_raw = 0x0,
<ncopa> to_msg_parser = 0x0, to_free_data = 0x0, to_clone = 0x0, to_list = {
<ncopa> next = 0x0, prev = 0x0}}
.to_type is initialized here:
https://github.com/thom311/libnl/blob/48182486341d1de7892494f272e892c0b18ebef5/lib/route/qdisc/blackhole.c
So this smells like the dynamic linker is corrupting memory when gnu
hash is used.
I believe it is related the fact that libxenlight pulls in
libnl-route-3.so.200 and libvirt.so.0 pulls in libnl.so.1. those
different versions of libnl libraries provides various symbols with
same name.
I was able to create a smaller testcase, which is attached. Note that
bot libnl-route-3.so.200 and libnl.so.1 provides 'rtnl_addr_alloc'.
Problem happens on alpine edge with those versions:
musl-1.1.10-r2
libnl3-3.2.26-r2
libnl-1.1.4-r0
gcc-5.1.0-r0
I was not able to preproduce it with alpine v3.2 (stable) with those
versions:
libnl3-3.2.25-r0
musl-1.1.9-r3
libnl-1.1.4-r0
gcc-4.9.2-r5
On edge I tried to build the libs with clang and the problem appeared.
We have changed to using gnu hash by default recently:
http://git.alpinelinux.org/cgit/aports/commit/main/binutils?id=ecd6d7d10fc37382bbdd89138199f88429797c7f
More, I tried build various musl versions from git (at least back to
v1.1.7) and problem happens. (I am only 95% sure i ran the test
properly)
So I suspect there is a bug in musl dynamic linker with gnu hash that
has been there for a long time.
It should be easy to reproduce with the 3 attached testfiles on alpine
edge.
I only tested x86_64.
Ideas?
Thanks!
-nc
Download attachment "Makefile" of type "application/octet-stream" (592 bytes)
View attachment "foo.c" of type "text/x-c++src" (198 bytes)
View attachment "libfoo3.c" of type "text/x-c++src" (151 bytes)
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.