|
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.