Message ID | 20150311163414.GB5438@aurel32.net |
---|---|
State | New |
Headers | show |
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.
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 ();