Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.