Bug 1325138 - glibc: Corrupted aux-cache causes ldconfig to segfault
Summary: glibc: Corrupted aux-cache causes ldconfig to segfault
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc
Version: 7.3
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Martin Sebor
QA Contact: Sergey Kolosov
Depends On:
Blocks: 1298243 1413146 1325135
TreeView+ depends on / blocked
Reported: 2016-04-08 11:47 UTC by Florian Weimer
Modified: 2019-10-10 11:49 UTC (History)
10 users (show)

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.
Clone Of: 1325135
Last Closed: 2017-08-01 18:06:55 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:1916 0 normal SHIPPED_LIVE Moderate: glibc security, bug fix, and enhancement update 2017-08-01 18:05:43 UTC
Sourceware 18093 0 P2 RESOLVED Corrupted aux-cache causes ldconfig to segfault 2021-02-15 15:20:18 UTC
Sourceware 20890 0 P2 RESOLVED ldconfig: fsync the files before atomic rename 2021-02-15 15:20:18 UTC

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

How reproducible:

Steps to Reproduce:
1. Remove some entries from /var/cache/ldconfig/aux-cache to make corrupt file.
2. Run ldconfig to rebuild cache

Actual results:
# ldconfig 
Segmentation fault (core dumped)

Expected results:
ldconfig should check for corrupt cache and rebuild it again.

Additional info:

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.


Note You need to log in before you can comment on or make changes to this bug.