bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libvirt] Stored secrets seem to get corrupted


From: Wido den Hollander
Subject: Re: [libvirt] Stored secrets seem to get corrupted
Date: Wed, 04 Jul 2012 16:17:39 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1



On 04-07-12 14:08, Eric Blake wrote:
[adding gnulib]

On 07/04/2012 02:45 AM, Daniel P. Berrange wrote:

==6825==
==6825== Invalid read of size 4
==6825==    at 0xA57E4B9: base64_encode (in 
/usr/lib/x86_64-linux-gnu/libroken.so.18.1.0)
==6825==    by 0x10DDBC98: base64_encode_alloc (base64.c:140)


This one is very interesting. It shows that the 'base64_encode' function
is doing an out-of-bounds read. More tellingly though is that it is
reporting 'base64_encode' function is in a wierd library:

    /usr/lib/x86_64-linux-gnu/libroken.so.18.1.

If this were normal, we should expect to see that function present
in 'base64.c' since this function code is provided by gnulib itself.

So something else libvirt is linking to, directly or indirectly
is using  libroken.so which also has a 'base64_encode'symbol
defined. This is overriding gnulib's symbol of the same name.

I'm willing to bet the API contract of this libroken.so base64_encode.
differs from GNULIBS, with crashtastic results


The library is libroken18-heimdal under Ubuntu 12.04:
http://packages.ubuntu.com/precise/libroken18-heimdal

When installing ubuntu-virt-server libraries like gnutls depend on
this library.


I expect that this is an internal symbol from libroken.so which
they leak into the public namespace.


It sounds like we might need to have a workaround in gnulib to
avoid this problem. With other cases where gnulib replaces existing
symbols they use some magic such that the gnulib replacement gets
prefixed with 'rpl_'.

Yuck.  Gnulib can't really probe at configure time whether an
application will link against a shared library that drags in namespace
pollution, so I don't see how to automate any 'rpl_' renaming in gnulib
directly.  It would be possible to blindly rename the gnulib functions,
but that's an interface change that would affect all clients of the
gnulib base64 module.

I'm wondering if it is better for libvirt to just #define base64_encode
to a different name in config.h.  Meanwhile, we need to open a bug
report against heimdal to fix their library namespace pollution through
libroken.


As this is getting a bit out of my league it's safe for me to assume somebody else will pick this up?

Not to take the easy way out, but I don't think I can't provide much help here other then testing any patches.

Wido




reply via email to

[Prev in Thread] Current Thread [Next in Thread]