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, 1 insertions, 1 deletions

diff --git a/NEWS b/NEWS
index 1cee779..6568085 100644
--- a/NEWS
+++ b/NEWS
@@ -14,7 +14,7 @@ Version 2.22
   17792, 17836, 17912, 17916, 17932, 17944, 17949, 17964, 17965, 17967,
   17969, 17978, 17987, 17991, 17996, 17998, 17999, 18019, 18020, 18029,
   18030, 18032, 18036, 18038, 18039, 18042, 18043, 18046, 18047, 18068,
-  18104, 18110, 18111.
+  18093, 18104, 18110, 18111.
 
 * Character encoding and ctype tables were updated to Unicode 7.0.0, using
   new generator scripts contributed by Pravin Satpute and Mike FABIAN (Red