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: Eric Blake
Subject: Re: [libvirt] Stored secrets seem to get corrupted
Date: Wed, 04 Jul 2012 06:08:59 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

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

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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