Bug 1325138

Summary: glibc: Corrupted aux-cache causes ldconfig to segfault
Product: Red Hat Enterprise Linux 7 Reporter: Florian Weimer <fweimer>
Component: glibcAssignee: Martin Sebor <msebor>
Status: CLOSED ERRATA QA Contact: Sergey Kolosov <skolosov>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.3CC: ashankar, codonell, cww, dkochuka, fweimer, mnewsome, msebor, pfrankli, qe-baseos-tools-bugs, skolosov
Target Milestone: rcKeywords: Patch
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: glibc-2.17-172.el7 Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of: 1325135 Environment:
Last Closed: 2017-08-01 18:06:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
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 <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.

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