[v2,BUG,18093] Fix ldconfig segmentation fault with corrupted cache

  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 the patch below
computes the theoretical cache size using the headers and compares it
to the real size.

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.
  

On 03/11/2015 12:34 PM, Aurelien Jarno wrote:
> 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 the patch below
> computes the theoretical cache size using the headers and compares it
> to the real size.
> 
> 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.
>
> diff --git a/elf/cache.c b/elf/cache.c
> index 1732268..bde7984 100644
> --- a/elf/cache.c
> +++ b/elf/cache.c
> @@ -698,7 +698,9 @@ load_aux_cache (const char *aux_cache_name)
>    if (aux_cache == MAP_FAILED
>        || aux_cache_size < sizeof (struct aux_cache_file)
>        || memcmp (aux_cache->magic, AUX_CACHEMAGIC, sizeof AUX_CACHEMAGIC - 1)
> -      || aux_cache->nlibs >= aux_cache_size)
> +      || aux_cache_size != (sizeof(struct aux_cache_file) +
> +			    aux_cache->nlibs * sizeof(struct aux_cache_file_entry) +
> +			    aux_cache->len_strings))
>      {
>        close (fd);
>        init_aux_cache ();
> 

I verified on Fedora Rawhide that without the patch
a truncated aux cache causes ldconfig to crash, and with the
new patch we re-initialize the cache.

I also verified with a debugger that it isn't just triggering
all the time resetting the cache.

Committed.

commit 6a1cf708dd5681b517744d6d4fac02e4e4a0aa2e
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Wed Mar 11 21:03:50 2015 -0400

    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.

Cheers,
Carlos.