|Summary:||glibc: Corrupted aux-cache causes ldconfig to segfault|
|Product:||Red Hat Enterprise Linux 7||Reporter:||Florian Weimer <fweimer>|
|Component:||glibc||Assignee:||Martin Sebor <msebor>|
|Status:||CLOSED ERRATA||QA Contact:||Sergey Kolosov <skolosov>|
|Version:||7.3||CC:||ashankar, codonell, cww, dkochuka, fweimer, mnewsome, msebor, pfrankli, qe-baseos-tools-bugs, skolosov|
|Fixed In Version:||glibc-2.17-172.el7||Doc Type:||Bug Fix|
In prior releases processing a corrupted /var/cache/ldconfig/aux-cache file with ldconfig would cause the program to crash. In this release ldconfig has been enhanced to detect and gracefully handle the corrupted cache file.
|Last Closed:||2017-08-01 18:06:55 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||1298243, 1413146, 1325135|
Description Florian Weimer 2016-04-08 11:47:12 UTC
+++ This bug was initially created as a clone of Bug #1325135 +++ Description of problem: ldconfig segfaults if the /var/cache/ldconfig/aux-cache is corrupted. Version-Release number of selected component (if applicable): Red Hat Enterprise Linux 6 glibc-2.12-1.166.el6_7.7.x86_64 How reproducible: Always Steps to Reproduce: 1. Remove some entries from /var/cache/ldconfig/aux-cache to make corrupt file. 2. Run ldconfig to rebuild cache 3. Actual results: # ldconfig Segmentation fault (core dumped) Expected results: ldconfig should check for corrupt cache and rebuild it again. Additional info: https://sourceware.org/bugzilla/show_bug.cgi?id=18093
Comment 1 Florian Weimer 2016-04-08 16:08:16 UTC
The upstream patch is incomplete because it does not perform an fsync before the rename, and some file systems need that.
Comment 2 Carlos O'Donell 2016-11-25 14:51:53 UTC
We need to fix the fsync issue and backport this patch. I'm setting devel_cond_nak+ upstream/capacity for this since we need a fix upstream before this is complete, but leaving flags Patch because we could backport the existing fix and move incrementally in the right direction (towards upstream solution). commit 6a1cf708dd5681b517744d6d4fac02e4e4a0aa2e Author: Aurelien Jarno <email@example.com> 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.
Comment 7 errata-xmlrpc 2017-08-01 18:06:55 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:1916