Bug#759530: Patch to fix segfault in ldconfig

[Niels Thykier <niels@thykier.net>]

Control: tags -1 patch upstream

On Wed, 25 Feb 2015 13:49:00 -0500 "Lennart Sorensen"
<lsorense@csclub.uwaterloo.ca> wrote:
> I looked at ways the aux-cache could cause a segfault, and given the
> file is mmap'd and has data offsets in it that are used as pointers
> without being checked it is not hard to see how a corrupt file could
> cause a segfault.  The following patch makes the segfaults I was able
> to think of and create go away.
> 
> I also have included an example corrupted aux-cache file
> (aux-cache-corrupt-soname-offset) which has a bad offset that causes
> a segfault.
> 


Excellent, thanks.

I am taking the liberty of adding the patch tag for this one.  If
nothing else, I would greatly appreciate having ldconfig not seg. fault. :)

> There is another problem which I haven't solved but which is not a
> segfault.  If you somehow truncate the aux-cache file by a bit and run
> the previous ldconfig without my patch, then you end up with a corrupted
> aux-cache where some entries do not have soname's even though they should,
> and that causes you to get messages like:
> 

Sounds like the aux-cache could do with a checksum or something to catch
obvious corruptions.

> [...]
> 
> Using ldconfig -i (and hence ignoring the corrupted aux-cache) makes
> that problem go away.  To solve it would of course mean you have to
> not trust the cache which rather defeats the point of having the cache,
> so I don't know if that is worth trying to solve.  It does not cause a
> segfault however.
> 
> Using ldconfig -p to show the cache at that point has entries that are
> clearly wrong such as:
> 
> [...]


Or ldconfig needs some method to (fairly) reliably detect corruptions.
If it spits out errors about directories not being links, then something
notices a problem.  Perhaps this could be extended to discarding the
cache (even if "just" a """if (!ignore_cache) execve(argv, "-i", null);""").

Thanks,
~Niels