dynamic linker issue

[Natanael Copa <ncopa@alpinelinux.org>]

[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]

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

[-- Attachment #2: Makefile --]
[-- Type: application/octet-stream, Size: 592 bytes --]

# Makefile
CFLAGS = -fPIC
LIBNL3_CFLAGS := $(shell pkg-config --cflags libnl-route-3.0)
LIBNL3_LIBS := $(shell pkg-config --libs libnl-route-3.0)

LIBNL_CFLAGS := $(shell pkg-config --cflags libnl-1)
LIBNL_LIBS := $(shell pkg-config --libs libnl-1)

run: foo
	LD_LIBRARY_PATH=$(PWD) $(HOME)/src/musl/lib/libc.so -- ./foo

foo: foo.c libfoo3.so
	$(CC) $(CFLAGS) $(LIBNL_CFLAGS) -L. -o $@ $< $(LIBNL_LIBS) -lfoo3

libfoo3.so: libfoo3.c libfoo3.h
	$(CC) $(CFLAGS) $(LIBNL3_CFLAGS) -o $@ -shared $< $(LIBNL3_LIBS)

libfoo3.h:
	echo "int foo_alloc();" >$@

clean:
	rm -f libfoo3.so foo libfoo3.h


[-- Attachment #3: foo.c --]
[-- Type: text/x-c++src, Size: 198 bytes --]

/* foo.c */
#include <netlink/route/addr.h>
#include <stdio.h>
#include "libfoo3.h"

int main(void)
{
	struct rtnl_addr *a = rtnl_addr_alloc();
	printf("foo_alloc: %i\n", foo_alloc());
	return 0;
}

[-- Attachment #4: libfoo3.c --]
[-- Type: text/x-c++src, Size: 150 bytes --]

/* libfoo3.c */
#include <netlink/route/addr.h>

int foo_alloc() {
	struct rtnl_addr *addr = NULL;
	addr = rtnl_addr_alloc();
	return addr != NULL;
}