Fix ldconfig segmentation fault with corrupted cache (Bug 18093).

ldconfig is using an aux-cache to speed up the ld.so.cache update. It
is read by mmaping the file to a structure which contains data offsets
used as pointers. As they are not checked, it is not hard to get
ldconfig to segfault with a corrupted file. This happens for instance if
the file is truncated, which is common following a filesystem check
following a system crash.

This can be reproduced for example by truncating the file to roughly
half of it's size.

There is already some code in elf/cache.c (load_aux_cache) to check
for a corrupted aux cache, but it happens to be broken and not enough.
The test (aux_cache->nlibs >= aux_cache_size) compares the number of
libs entry with the cache size. It's a non sense, as it basically
assumes that each library entry is a 1 byte... Instead this commit
computes the theoretical cache size using the headers and compares it
to the real size.

1 files changed, 6 insertions, 0 deletions

diff --git a/ChangeLog b/ChangeLog
index 736007961f..f12516b9a1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2015-03-11  Aurelien Jarno  <aurelien@aurel32.net>
+
+	[BZ #18093]
+	* elf/cache.c (load_aux_cache): Regenerate the cache if it has
+	the wrong size.
+
 2015-03-11  Paul Pluzhnikov  <ppluzhnikov@google.com>
 
 	[BZ #18043]