Fix ldconfig segmentation fault with corrupted cache (Bug 18093).
commit6a1cf708dd5681b517744d6d4fac02e4e4a0aa2e
authorAurelien Jarno <aurelien@aurel32.net>
Thu, 12 Mar 2015 01:03:50 +0000 (11 21:03 -0400)
committerCarlos O'Donell <carlos@systemhalted.org>
Thu, 12 Mar 2015 01:07:32 +0000 (11 21:07 -0400)
treea965b2d1be84995f55dbfdeb479b4a2b74f1ec69
parenta2d4cf72c0ab07d4e58b42c01ac3ed2b95ca8d9b
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.
ChangeLog
NEWS
elf/cache.c