Debian Bug report logs - #759530
libc-bin: ldconfig breaks a system

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Dmitrii Kashin <freehck@freehck.ru>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libc-bin: ldconfig breaks a system

Date: Thu, 28 Aug 2014 10:07:57 +0400

[Message part 1 (text/plain, inline)]

Package: libc-bin
Version: 2.19-9
Severity: grave
File: /sbin/ldconfig

Dear Maintainer,

I had an upgrade of libc6 and libc-bin packages up to the version
2.19-9 from 2.19-4 while executing `apt-get upgrade'. In the begin it
seemed as a usual upgrade but after a while (supposedly after these two
packages) an upgrade was interrupted showing numerous "segmentation
fault" errors.

Then almost for every command in shell I got "segmentation fault". I was
surprised. I tried to log into another tty, but failed. Then I tried to
reboot... And got a kernel panic after 2 seconds of system bootstrap.

I took a livecd. I failed to chroot (got the same "segfault problem"). I
supposed that I had some problems with libc6, so I took a package
libc6_2.19-9_amd64.deb from /var/cache/apt/archives and unpacked it into
the root mount point via `dpkg-deb -x <pkg>'. After that I managed to
chroot into the system.

I tried to finish an upgrade process, but I got the same faults.
I put here inline the first lines of `apt-get upgrade' output:
--------------------
# apt-get upgrade
Reading package lists...
Building dependency tree...
Reading state information...
The following packages were automatically installed and are no longer required:
  alsa-base libabw-0.0-0 libcdr-0.0-0 libe-book-0.0-0 libetonyek-0.0-0
  libfreehand-0.0-0 libgeoclue0 libmspub-0.0-0 libmwaw-0.2-2 libodfgen-0.0-0
  liborcus-0.6-0 libvisio-0.0-0 libwpd-0.9-9 libwpg-0.2-2 libwps-0.2-2
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
108 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up liblcms2-2:i386 (2.6-3) ...
Setting up libmbim-glib0:amd64 (1.8.0-1) ...
dpkg: error processing package libmbim-glib0:amd64 (--configure):
 subprocess installed post-installation script was killed by signal (Segmentation fault)
Setting up libmm-glib0:amd64 (1.2.0-1) ...
dpkg: error processing package libmm-glib0:amd64 (--configure):
 subprocess installed post-installation script was killed by signal (Segmentation fault)
Setting up libmng1:i386 (1.0.10+dfsg-3.1) ...
...
--------------------

After it I had to unpack libc6 package again.

Then I looked intently at the first package with problems
(libmbim-glib0). I unpacked it and saw in the postinst script the
command `ldconfig'.

After a while I realized that "segfaults" happen after and only after
execution of `ldconfig'.

I managed with the problem by downgrading libc6 and libc-bin (amd64 and
i386 versions both, because I'm using multiarch) back to the version
2.19-4 from the apt cache.

I suppose that there's some problems with caches which ldconfig
generates for ld.


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'stable'), (1, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc-bin depends on:
pn  libc6    <none>
ii  libcap2  1:2.24-4

libc-bin recommends no packages.

libc-bin suggests no packages.

-- Configuration Files:
/etc/gai.conf changed:

/etc/ld.so.conf changed:
include ld.so.conf.d/*.conf
include /etc/ld.so.conf.d/*.conf



-- no debconf information

[Message part 2 (application/pgp-signature, inline)]

Message #10 received at submit@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Dmitrii Kashin <freehck@freehck.ru>, 759530@bugs.debian.org

Cc: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Re: Bug#759530: libc-bin: ldconfig breaks a system

Date: Thu, 28 Aug 2014 09:47:10 +0200

On Thu, Aug 28, 2014 at 10:07:57AM +0400, Dmitrii Kashin wrote:
> Package: libc-bin
> Version: 2.19-9
> Severity: grave
> File: /sbin/ldconfig
> 
> Dear Maintainer,
> 
> I had an upgrade of libc6 and libc-bin packages up to the version
> 2.19-9 from 2.19-4 while executing `apt-get upgrade'. In the begin it
> seemed as a usual upgrade but after a while (supposedly after these two
> packages) an upgrade was interrupted showing numerous "segmentation
> fault" errors.
> 
> Then almost for every command in shell I got "segmentation fault". I was
> surprised. I tried to log into another tty, but failed. Then I tried to
> reboot... And got a kernel panic after 2 seconds of system bootstrap.
> 
> I took a livecd. I failed to chroot (got the same "segfault problem"). I
> supposed that I had some problems with libc6, so I took a package
> libc6_2.19-9_amd64.deb from /var/cache/apt/archives and unpacked it into
> the root mount point via `dpkg-deb -x <pkg>'. After that I managed to
> chroot into the system.
> 
> I tried to finish an upgrade process, but I got the same faults.
> I put here inline the first lines of `apt-get upgrade' output:
> --------------------
> # apt-get upgrade
> Reading package lists...
> Building dependency tree...
> Reading state information...
> The following packages were automatically installed and are no longer required:
>   alsa-base libabw-0.0-0 libcdr-0.0-0 libe-book-0.0-0 libetonyek-0.0-0
>   libfreehand-0.0-0 libgeoclue0 libmspub-0.0-0 libmwaw-0.2-2 libodfgen-0.0-0
>   liborcus-0.6-0 libvisio-0.0-0 libwpd-0.9-9 libwpg-0.2-2 libwps-0.2-2
> Use 'apt-get autoremove' to remove them.
> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
> 108 not fully installed or removed.
> After this operation, 0 B of additional disk space will be used.
> Setting up liblcms2-2:i386 (2.6-3) ...
> Setting up libmbim-glib0:amd64 (1.8.0-1) ...
> dpkg: error processing package libmbim-glib0:amd64 (--configure):
>  subprocess installed post-installation script was killed by signal (Segmentation fault)
> Setting up libmm-glib0:amd64 (1.2.0-1) ...
> dpkg: error processing package libmm-glib0:amd64 (--configure):
>  subprocess installed post-installation script was killed by signal (Segmentation fault)
> Setting up libmng1:i386 (1.0.10+dfsg-3.1) ...
> ...
> --------------------
> 
> After it I had to unpack libc6 package again.
> 
> Then I looked intently at the first package with problems
> (libmbim-glib0). I unpacked it and saw in the postinst script the
> command `ldconfig'.
> 
> After a while I realized that "segfaults" happen after and only after
> execution of `ldconfig'.
> 
> I managed with the problem by downgrading libc6 and libc-bin (amd64 and
> i386 versions both, because I'm using multiarch) back to the version
> 2.19-4 from the apt cache.
> 

For me it looks like the ld.so symlink is overriden when running
ldconfig, a bug which is supposed to be fixed months ago. Can you please
give me the list of libc packages installed on your system by running
the "dpkg -l libc*" command? Also what is the output of "which
ldconfig"?

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Message #18 received at 759530-submitter@bugs.debian.org (full text, mbox, reply):

From: Mathieu Malaterre <malat@debian.org>

To: 759530-submitter@bugs.debian.org

Subject: Please update bug report

Date: Wed, 17 Sep 2014 12:10:28 +0200

Control: tags -1 moreinfo

Dear submitter,

We would need more information from your side to make progress on bug #759530

Regards.

Message #25 received at submit@bugs.debian.org (full text, mbox, reply):

From: Dmitrii Kashin <freehck@freehck.ru>

To: Aurelien Jarno <aurelien@aurel32.net>

Cc: 759530@bugs.debian.org, Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Re: Bug#759530: libc-bin: ldconfig breaks a system

Date: Mon, 22 Sep 2014 12:50:48 +0400

[Message part 1 (text/plain, inline)]

Aurelien Jarno <aurelien@aurel32.net> writes:

> On Thu, Aug 28, 2014 at 10:07:57AM +0400, Dmitrii Kashin wrote:
>> Package: libc-bin
>> Version: 2.19-9
>> Severity: grave
>> File: /sbin/ldconfig
>> 
>> Dear Maintainer,
>> 
>> I had an upgrade of libc6 and libc-bin packages up to the version
>> 2.19-9 from 2.19-4 while executing `apt-get upgrade'. In the begin it
>> seemed as a usual upgrade but after a while (supposedly after these two
>> packages) an upgrade was interrupted showing numerous "segmentation
>> fault" errors.
>> 
>> Then almost for every command in shell I got "segmentation fault". I was
>> surprised. I tried to log into another tty, but failed. Then I tried to
>> reboot... And got a kernel panic after 2 seconds of system bootstrap.
>> 
>> I took a livecd. I failed to chroot (got the same "segfault problem"). I
>> supposed that I had some problems with libc6, so I took a package
>> libc6_2.19-9_amd64.deb from /var/cache/apt/archives and unpacked it into
>> the root mount point via `dpkg-deb -x <pkg>'. After that I managed to
>> chroot into the system.
>> 
>> I tried to finish an upgrade process, but I got the same faults.
>> I put here inline the first lines of `apt-get upgrade' output:
>> --------------------
>> # apt-get upgrade
>> Reading package lists...
>> Building dependency tree...
>> Reading state information...
>> The following packages were automatically installed and are no longer required:
>>   alsa-base libabw-0.0-0 libcdr-0.0-0 libe-book-0.0-0 libetonyek-0.0-0
>>   libfreehand-0.0-0 libgeoclue0 libmspub-0.0-0 libmwaw-0.2-2 libodfgen-0.0-0
>>   liborcus-0.6-0 libvisio-0.0-0 libwpd-0.9-9 libwpg-0.2-2 libwps-0.2-2
>> Use 'apt-get autoremove' to remove them.
>> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
>> 108 not fully installed or removed.
>> After this operation, 0 B of additional disk space will be used.
>> Setting up liblcms2-2:i386 (2.6-3) ...
>> Setting up libmbim-glib0:amd64 (1.8.0-1) ...
>> dpkg: error processing package libmbim-glib0:amd64 (--configure):
>>  subprocess installed post-installation script was killed by signal (Segmentation fault)
>> Setting up libmm-glib0:amd64 (1.2.0-1) ...
>> dpkg: error processing package libmm-glib0:amd64 (--configure):
>>  subprocess installed post-installation script was killed by signal (Segmentation fault)
>> Setting up libmng1:i386 (1.0.10+dfsg-3.1) ...
>> ...
>> --------------------
>> 
>> After it I had to unpack libc6 package again.
>> 
>> Then I looked intently at the first package with problems
>> (libmbim-glib0). I unpacked it and saw in the postinst script the
>> command `ldconfig'.
>> 
>> After a while I realized that "segfaults" happen after and only after
>> execution of `ldconfig'.
>> 
>> I managed with the problem by downgrading libc6 and libc-bin (amd64 and
>> i386 versions both, because I'm using multiarch) back to the version
>> 2.19-4 from the apt cache.
>> 
>
> For me it looks like the ld.so symlink is overriden when running
> ldconfig, a bug which is supposed to be fixed months ago. Can you please
> give me the list of libc packages installed on your system by running
> the "dpkg -l libc*" command? Also what is the output of "which
> ldconfig"?

Sorry for being a little bit late. I had a great pile of work.

This information could be useful:
--------------------
freehck@nb-mita3:~% apt-mark showhold
libc-bin
libc6
libc6-i686:i386
libc6:i386
--------------------
freehck@nb-mita3:~% apt-cache policy libc6 libc-bin
libc6:
  Installed: 2.19-4
  Candidate: 2.19-9
  Version table:
     2.19-9 0
        500 http://mirror.yandex.ru/debian/ jessie/main amd64 Packages
 *** 2.19-4 0
        100 /var/lib/dpkg/status
     2.13-38+deb7u2 0
          1 http://mirror.yandex.ru/debian/ wheezy/main amd64 Packages
     2.11.3-4 0
          1 http://mirror.yandex.ru/debian/ squeeze/main amd64 Packages
libc-bin:
  Installed: 2.19-4
  Candidate: 2.19-9
  Version table:
     2.19-9 0
        500 http://mirror.yandex.ru/debian/ jessie/main amd64 Packages
 *** 2.19-4 0
        100 /var/lib/dpkg/status
     2.13-38+deb7u2 0
          1 http://mirror.yandex.ru/debian/ wheezy/main amd64 Packages
     2.11.3-4 0
          1 http://mirror.yandex.ru/debian/ squeeze/main amd64 Packages
--------------------
# I understand it's more then you need, but you have asked to grep by
# `libc*' pattern. =/
freehck@nb-mita3:~% dpkg -l libc\* | grep ^ii      
ii  libcaca0:amd64                 0.99.beta19-2    amd64        colour ASCII art library
ii  libcairo-gobject2:amd64        1.12.16-2        amd64        The Cairo 2D vector graphics library (GObject library)
ii  libcairo2:amd64                1.12.16-2        amd64        The Cairo 2D vector graphics library
ii  libcanberra0:amd64             0.30-2           amd64        simple abstract interface for playing event sounds
ii  libcap-ng0:amd64               0.7.4-2          amd64        An alternate POSIX capabilities library
ii  libcap2:amd64                  1:2.24-4         amd64        POSIX 1003.1e capabilities (library)
ii  libcap2:i386                   1:2.24-4         i386         POSIX 1003.1e capabilities (library)
ii  libcap2-bin                    1:2.24-4         amd64        POSIX 1003.1e capabilities (utilities)
ii  libcdio-cdda1                  0.83-4.1         amd64        library to read and control digital audio CDs
ii  libcdio-paranoia1              0.83-4.1         amd64        library to read digital audio CDs with error correction
ii  libcdio13                      0.83-4.1         amd64        library to read and control CD-ROM
ii  libcdparanoia0:amd64           3.10.2+debian-11 amd64        audio extraction tool for sampling CDs (library)
ii  libcdr-0.0-0                   0.0.16-1         amd64        library for reading and converting Corel DRAW files
ii  libcdr-0.1-1                   0.1.0-3          amd64        library for reading and converting Corel DRAW files
ii  libcgi-pm-perl                 3.65-1           all          module for Common Gateway Interface applications
ii  libck-connector0:amd64         0.4.6-4          amd64        ConsoleKit libraries
ii  libclass-c3-perl               0.26-1           all          pragma for using the C3 method resolution order
ii  libclass-c3-xs-perl            0.13-2+b1        amd64        Perl module to accelerate Class::C3
ii  libcloog-isl4:amd64            0.18.2-1         amd64        Chunky Loop Generator (runtime library)
ii  libclucene-contribs1:amd64     2.3.3.4-4        amd64        language specific text analyzers (runtime)
ii  libclucene-core1:amd64         2.3.3.4-4        amd64        core library for full-featured text search engine (runtime)
ii  libcmis-0.4-4                  0.4.1-7          amd64        CMIS protocol client library
ii  libcolamd2.8.0:amd64           1:4.2.1-3        amd64        column approximate minimum degree ordering library for sparse matrices
ii  libcolord2:amd64               1.2.1-1          amd64        system service to manage device colour profiles -- runtime
ii  libcomerr2:amd64               1.42.11-2        amd64        common error description library
ii  libcomerr2:i386                1.42.11-2        i386         common error description library
ii  libcommon-sense-perl           3.73-1+b1        amd64        module that implements some sane defaults for Perl programs
ii  libconfig-file-perl            1.50-2           all          Parses simple configuration files
ii  libconfuse-common              2.7-5            all          Common files for libConfuse
ii  libconfuse0:amd64              2.7-5            amd64        Library for parsing configuration files
ii  libcroco3:amd64                0.6.8-3          amd64        Cascading Style Sheet (CSS) parsing and manipulation toolkit
ii  libcups2:amd64                 1.7.5-1          amd64        Common UNIX Printing System(tm) - Core library
ii  libcups2:i386                  1.7.5-1          i386         Common UNIX Printing System(tm) - Core library
ii  libcupsfilters1:amd64          1.0.58-1         amd64        OpenPrinting CUPS Filters - Shared library
ii  libcupsimage2:amd64            1.7.5-1          amd64        Common UNIX Printing System(tm) - Raster image library
ii  libcurl3:amd64                 7.37.1-1         amd64        easy-to-use client-side URL transfer library (OpenSSL flavour)
ii  libcurl3-gnutls:amd64          7.37.1-1         amd64        easy-to-use client-side URL transfer library (GnuTLS flavour)
ii  libcurses-perl                 1.31-1+b1        amd64        Curses interface for Perl
ii  libcurses-ui-perl              0.9609-1         all          curses-based OO user interface framework for Perl
ii  libcwidget3:amd64              0.5.17-1         amd64        high-level terminal interface library for C++ (runtime files)
freehck@nb-mita3:~% dpkg -l libc\* | grep ^ii      
ii  libcaca0:amd64                 0.99.beta19-2    amd64        colour ASCII art library
ii  libcairo-gobject2:amd64        1.12.16-2        amd64        The Cairo 2D vector graphics library (GObject library)
ii  libcairo2:amd64                1.12.16-2        amd64        The Cairo 2D vector graphics library
ii  libcanberra0:amd64             0.30-2           amd64        simple abstract interface for playing event sounds
ii  libcap-ng0:amd64               0.7.4-2          amd64        An alternate POSIX capabilities library
ii  libcap2:amd64                  1:2.24-4         amd64        POSIX 1003.1e capabilities (library)
ii  libcap2:i386                   1:2.24-4         i386         POSIX 1003.1e capabilities (library)
ii  libcap2-bin                    1:2.24-4         amd64        POSIX 1003.1e capabilities (utilities)
ii  libcdio-cdda1                  0.83-4.1         amd64        library to read and control digital audio CDs
ii  libcdio-paranoia1              0.83-4.1         amd64        library to read digital audio CDs with error correction
ii  libcdio13                      0.83-4.1         amd64        library to read and control CD-ROM
ii  libcdparanoia0:amd64           3.10.2+debian-11 amd64        audio extraction tool for sampling CDs (library)
ii  libcdr-0.0-0                   0.0.16-1         amd64        library for reading and converting Corel DRAW files
ii  libcdr-0.1-1                   0.1.0-3          amd64        library for reading and converting Corel DRAW files
ii  libcgi-pm-perl                 3.65-1           all          module for Common Gateway Interface applications
ii  libck-connector0:amd64         0.4.6-4          amd64        ConsoleKit libraries
ii  libclass-c3-perl               0.26-1           all          pragma for using the C3 method resolution order
ii  libclass-c3-xs-perl            0.13-2+b1        amd64        Perl module to accelerate Class::C3
ii  libcloog-isl4:amd64            0.18.2-1         amd64        Chunky Loop Generator (runtime library)
ii  libclucene-contribs1:amd64     2.3.3.4-4        amd64        language specific text analyzers (runtime)
ii  libclucene-core1:amd64         2.3.3.4-4        amd64        core library for full-featured text search engine (runtime)
ii  libcmis-0.4-4                  0.4.1-7          amd64        CMIS protocol client library
ii  libcolamd2.8.0:amd64           1:4.2.1-3        amd64        column approximate minimum degree ordering library for sparse matrices
ii  libcolord2:amd64               1.2.1-1          amd64        system service to manage device colour profiles -- runtime
ii  libcomerr2:amd64               1.42.11-2        amd64        common error description library
ii  libcomerr2:i386                1.42.11-2        i386         common error description library
ii  libcommon-sense-perl           3.73-1+b1        amd64        module that implements some sane defaults for Perl programs
ii  libconfig-file-perl            1.50-2           all          Parses simple configuration files
ii  libconfuse-common              2.7-5            all          Common files for libConfuse
ii  libconfuse0:amd64              2.7-5            amd64        Library for parsing configuration files
ii  libcroco3:amd64                0.6.8-3          amd64        Cascading Style Sheet (CSS) parsing and manipulation toolkit
ii  libcups2:amd64                 1.7.5-1          amd64        Common UNIX Printing System(tm) - Core library
ii  libcups2:i386                  1.7.5-1          i386         Common UNIX Printing System(tm) - Core library
ii  libcupsfilters1:amd64          1.0.58-1         amd64        OpenPrinting CUPS Filters - Shared library
ii  libcupsimage2:amd64            1.7.5-1          amd64        Common UNIX Printing System(tm) - Raster image library
ii  libcurl3:amd64                 7.37.1-1         amd64        easy-to-use client-side URL transfer library (OpenSSL flavour)
ii  libcurl3-gnutls:amd64          7.37.1-1         amd64        easy-to-use client-side URL transfer library (GnuTLS flavour)
ii  libcurses-perl                 1.31-1+b1        amd64        Curses interface for Perl
ii  libcurses-ui-perl              0.9609-1         all          curses-based OO user interface framework for Perl
ii  libcwidget3:amd64              0.5.17-1         amd64        high-level terminal interface library for C++ (runtime files)
--------------------
freehck@nb-mita3:~% which ldconfig                 
/sbin/ldconfig
freehck@nb-mita3:~% ll `!!`
ll `which ldconfig`
-rwxr-xr-x 1 root root 387 Jun 24 01:31 /sbin/ldconfig
--------------------

If I can help more, ask. I'm ready to provide you for more information.

[Message part 2 (application/pgp-signature, inline)]

Message #35 received at 759530@bugs.debian.org (full text, mbox, reply):

From: Hagen Fuchs <code@hfuchs.net>

To: Debian Bug Tracking System <759530@bugs.debian.org>

Subject: Re: libc-bin: ldconfig breaks a system

Date: Tue, 07 Oct 2014 23:51:34 +0200

Package: libc-bin
Version: 2.19-11
Followup-For: Bug #759530

Hello!

Something similar happened to me (after upgrade to 2.19-11).  If this
report wasn't on top of libc-bin and absolutely recent, I would not have
said a word: read on!

Foundation-laying: the scenario.  All packages that call ldconfig in their
install scripts started sputtering like this one:

   Setting up golang (2:1.3.2-1) ...
   Processing triggers for libc-bin (2.19-11) ...
   Segmentation fault
   /sbin/ldconfig.real: Path `/lib/x86_64-linux-gnu' given more than once
   /sbin/ldconfig.real: Path `/usr/lib/x86_64-linux-gnu' given more than once
   /usr/lib/x86_64-linux-gnu/libfakeroot:
           libfakeroot-0.so -> libfakeroot-tcp.so
   /usr/local/lib:
   /lib/x86_64-linux-gnu:
           libthread_db.so.1 -> libthread_db-1.0.so
           [...]
           libglib-2.0.so.0 -> libglib-2.0.so.0.4200.0
   /usr/lib/x86_64-linux-gnu:
   Segmentation fault
   dpkg: error processing package libc-bin (--configure):
    subprocess installed post-installation script returned error exit status 139
   Errors were encountered while processing:
    libc-bin

Hu?  ldconfig dies like this (strace):

   [natural-looking output]
   stat("/usr/lib/x86_64-linux-gnu/libQtScript.so.4", {st_mode=S_IFREG|0644, st_size=2692504, ...}) = 0
   stat("/usr/lib/x86_64-linux-gnu/libjasper.so.1",  <unfinished ...>
   +++ killed by SIGSEGV +++
   Segmentation fault

Oh?

   # file /usr/lib/x86_64-linux-gnu/libjasper.so.1
   Segmentation fault

Drastic measures (wtf?):

   # ls !$
   ls /usr/lib/x86_64-linux-gnu/libjasper.so.1
   Segmentation fault
   # rm /usr/lib/x86_64-linux-gnu/libjasper.so.1
   Segmentation fault
   # unlink !$
   unlink /usr/lib/x86_64-linux-gnu/libjasper.so.1
   # ls /usr/lib/x86_64-linux-gnu/libjasper.so.1
   ls: cannot access /usr/lib/x86_64-linux-gnu/libjasper.so.1: No such file or directory

Done (reinstall libjasper1).

Now, ordinarily, I'd say: severe FS corruption, something or other.
But, with this report on top, perhaps there's something deeper going on.
No idea.

Note: I now have no way of returning to the broken state.

I doubt anyone can profit from this, but I had to throw it in (as I
already mentioned).

Such is my tale of woe.

Regards,
  Hagen

Message #40 received at 759530@bugs.debian.org (full text, mbox, reply):

From: Bernd Zeimetz <bernd@bzed.de>

To: 759530@bugs.debian.org

Subject: 759530: segvault in strcmp-sse42

Date: Sun, 26 Oct 2014 15:35:57 +0100

Hi,

what I'm seeing here is a segvault in strcmp-sse42.S, although I'm
not 100% sure that this is the only issue, but as the trouble arrived
with libc 2.19 I think the problem is somewhere in the new libc,
also as running an older kernel did not help at all.

currently the szstem is completely unusable, random segvaults,
also running into some major file system issues.

The problem shows up similar to to the original mail in this bug
report, during an upgrade of unrelated libraries.


root@think:~# cat libc6_segfault.txt
Program received signal SIGSEGV, Segmentation fault.
__strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:235
235     ../sysdeps/x86_64/multiarch/strcmp-sse42.S: No such file or 
directory.
(gdb) bt full
#0  __strcasecmp_l_avx () at 
../sysdeps/x86_64/multiarch/strcmp-sse42.S:235
No locals.
#1  0x00007ffff7ac3a5e in pkgCache::FindGrp(std::string const&) () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
No symbol table info available.
#2  0x00007ffff7afa9ce in 
pkgCacheGenerator::NewGroup(pkgCache::GrpIterator&, std::string const&) 
() from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
No symbol table info available.
#3  0x00007ffff7b0148c in 
pkgCacheGenerator::ListParser::NewDepends(pkgCache::VerIterator&, 
std::string const&, std::string const&, std::string const&, unsigned 
int, unsigned int) ()
   from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
No symbol table info available.
#4  0x00007ffff7b6aaec in 
debListParser::ParseDepends(pkgCache::VerIterator&, char const*, 
unsigned int) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
No symbol table info available.
#5  0x00007ffff7b6b362 in 
debListParser::NewVersion(pkgCache::VerIterator&) () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
No symbol table info available.
#6  0x00007ffff7aff640 in ?? () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
No symbol table info available.
#7  0x00007ffff7b00e10 in 
pkgCacheGenerator::MergeList(pkgCacheGenerator::ListParser&, 
pkgCache::VerIterator*) () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
No symbol table info available.
#8  0x00007ffff7b60cef in debStatusIndex::Merge(pkgCacheGenerator&, 
OpProgress*) const () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
No symbol table info available.
#9  0x00007ffff7af942a in ?? () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
No symbol table info available.
#10 0x00007ffff7afc8da in 
pkgCacheGenerator::MakeStatusCache(pkgSourceList&, OpProgress*, MMap**, 
bool) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
No symbol table info available.
#11 0x00007ffff7ac130b in pkgCacheFile::BuildCaches(OpProgress*, bool) 
() from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
No symbol table info available.
#12 0x000055555555d8cb in ?? ()
No symbol table info available.
#13 0x00007ffff7ba4fa6 in 
CommandLine::DispatchArg(CommandLine::Dispatch*, bool) () from 
/usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
No symbol table info available.
#14 0x000055555555be14 in ?? ()
No symbol table info available.
#15 0x00007ffff6c8ab45 in __libc_start_main (main=0x55555555bc30, 
argc=3, argv=0x7fffffffe6a8, init=<optimized out>, fini=<optimized out>, 
rtld_fini=<optimized out>, stack_end=0x7fffffffe698)
    at libc-start.c:287
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 
-559760095329638525, 93824992264110, 140737488348832, 0, 0, 
559760096206268291, 559775362226726787}, mask_was_saved = 0}}, priv = 
{pad = {0x0,
              0x0, 0x7fffffffe6c8, 0x7ffff7ffe1a8}, data = {prev = 0x0, 
cleanup = 0x0, canceltype = -6456}}}
        not_first_call = <optimized out>
#16 0x000055555555bfd7 in ?? ()
No symbol table info available.



-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Message #47 received at 759530@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: 759530@bugs.debian.org, 759530-submitter@bugs.debian.org

Subject: CPU info?

Date: Thu, 01 Jan 2015 22:09:58 +0100

[Message part 1 (text/plain, inline)]

Hi,

I'm not experiencing that bug, but maybe it'd help if the submitters
would provide their /proc/cpuinfo and maybe try to get a clue about
where the segfault happens (maybe with coredumps)?

Regards,
-- 
Yves-Alexis

[signature.asc (application/pgp-signature, inline)]

Message #55 received at 759530@bugs.debian.org (full text, mbox, reply):

From: Helmut Grohne <helmut@subdivi.de>

To: Yves-Alexis Perez <corsac@debian.org>, 759530@bugs.debian.org

Subject: Re: Bug#759530: CPU info?

Date: Sat, 10 Jan 2015 21:13:25 +0100

On Thu, Jan 01, 2015 at 10:09:58PM +0100, Yves-Alexis Perez wrote:
> I'm not experiencing that bug, but maybe it'd help if the submitters
> would provide their /proc/cpuinfo and maybe try to get a clue about
> where the segfault happens (maybe with coredumps)?

/proc/cpuinfo from Bernd Zeimetz (he was reporting segfaults as well):

processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
stepping	: 7
microcode	: 0x29
cpu MHz		: 813.769
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 2
apicid		: 3
initial apicid	: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4983.78
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

Helmut

Message #60 received at 759530@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: 759530@bugs.debian.org

Subject: Re: libc-bin: ldconfig breaks a system

Date: Wed, 18 Feb 2015 09:32:25 +0100

Hi,

Could this bug be caused by a corrupt aux-cache[1] (possibly, in
addition to a corrupt ld.so.cache)?

A bit of google searching suggests that a broken aux-cache can cause
ldconfig to seg. fault.  With the ld.so.cache itself being corrupt (or
sufficiently outdated?), both ldconfig and most other binaries would
simply "just seg. fault" fitting the symptoms pretty well so far.

It partly also fits with the removal of libjasper1, as the removed
library would force ldconfig to *not* use its cache for said library.
Though I cannot explain why it seems like stat itself seg. faults.

Assuming my hypothesis is correct, a broken system could be restored by
running[2]:

 $ ldconfig.real --ignore-aux-cache

Failling that:

 $ > /var/cache/ldconfig/aux-cache
 $ ldconfig.real

Maybe take a copy of the aux-cache before doing the "restore"
command(s).  This way we should be able to "re-break" the system by
re-instating the old aux-cache (and possibly breaking the ld.so.cache).

Thanks,
~Niels

[1] /var/cache/ldconfig/aux-cache

[2] Using ldconfig.real in case /bin/sh got borked by the ld.so.cache as
well.

Message #65 received at 759530@bugs.debian.org (full text, mbox, reply):

From: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>

To: 759530@bugs.debian.org

Subject: Patch to fix segfault in ldconfig

Date: Wed, 25 Feb 2015 13:49:00 -0500

[Message part 1 (text/plain, inline)]

I looked at ways the aux-cache could cause a segfault, and given the
file is mmap'd and has data offsets in it that are used as pointers
without being checked it is not hard to see how a corrupt file could
cause a segfault.  The following patch makes the segfaults I was able
to think of and create go away.

I also have included an example corrupted aux-cache file
(aux-cache-corrupt-soname-offset) which has a bad offset that causes
a segfault.

There is another problem which I haven't solved but which is not a
segfault.  If you somehow truncate the aux-cache file by a bit and run
the previous ldconfig without my patch, then you end up with a corrupted
aux-cache where some entries do not have soname's even though they should,
and that causes you to get messages like:

/sbin/ldconfig.real: /lib/i386-linux-gnu/ is not a symbolic link

/sbin/ldconfig.real: /usr/lib/i386-linux-gnu/ is not a symbolic link

/sbin/ldconfig.real: /lib64/ is not a symbolic link

/sbin/ldconfig.real: /usr/lib64/ is not a symbolic link

/sbin/ldconfig.real: /libx32/ is not a symbolic link

/sbin/ldconfig.real: /usr/libx32/ is not a symbolic link

/sbin/ldconfig.real: /usr/lib/ is not a symbolic link

/sbin/ldconfig.real: /usr/lib/i386-linux-gnu/i586/ is not a symbolic link

/sbin/ldconfig.real: /usr/lib/i386-linux-gnu/i686/cmov/ is not a symbolic link

Using ldconfig -i (and hence ignoring the corrupted aux-cache) makes
that problem go away.  To solve it would of course mean you have to
not trust the cache which rather defeats the point of having the cache,
so I don't know if that is worth trying to solve.  It does not cause a
segfault however.

Using ldconfig -p to show the cache at that point has entries that are
clearly wrong such as:

...
        day (libc6, OS ABI: Linux 2.6.32) => /lib/i386-linux-gnu/day
        __kernel_sigreturn (libc6,x32, OS ABI: Linux 3.4.0) => /libx32/__kernel_sigreturn
        X_2.6 (libc6) => /usr/lib/i386-linux-gnu/X_2.6
        LF (libc6) => /usr/lib/i386-linux-gnu/LF
 (libc6) => /usr/lib/ 
         (libc6, OS ABI: Linux 2.6.32) => /lib/i386-linux-gnu/
         (libc6, OS ABI: Linux 2.6.32) => /usr/lib/i386-linux-gnu/
 (libc6) => /lib/i386-linux-gnu/
 (libc6) => /usr/lib/i386-linux-gnu/
         (libc6) => /usr/lib/i386-linux-gnu/
         (libc6) => /usr/lib/i386-linux-gnu/
         (libc6) => /usr/lib/i386-linux-gnu/
         (libc6, OS ABI: Linux 2.6.32) => /lib/i386-linux-gnu/
         (libc6, OS ABI: Linux 2.6.32) => /usr/lib/i386-linux-gnu/
         (libc6,x32, OS ABI: Linux 3.4.0) => /libx32/
         (libc6,x32, OS ABI: Linux 3.4.0) => /usr/libx32/
         (libc6,x86-64, OS ABI: Linux 2.6.32) => /lib64/
         (libc6,x86-64, OS ABI: Linux 2.6.32) => /usr/lib64/
         (libc6, hwcap: 0x0008000000008000) => /usr/lib/i386-linux-gnu/i686/cmov/
         (libc6, hwcap: 0x0004000000000000) => /usr/lib/i386-linux-gnu/i586/
         (libc6) => /lib/i386-linux-gnu/
         (libc6) => /usr/lib/i386-linux-gnu/
         (libc6) => /usr/lib/
        � (libc6) => /lib/i386-linux-gnu/�

The file aux-cache-missing-sonames shows this corrupted state.

I hope the patch at least helps solve the worst part of the problem.

-- 
Len Sorensen

[ldconfig-segfault-fix.patch (text/x-diff, attachment)]

[aux-cache-corrupt-soname-offset (application/octet-stream, attachment)]

[aux-cache-missing-sonames (application/octet-stream, attachment)]

Message #70 received at 759530@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: 759530@bugs.debian.org

Cc: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>

Subject: Re: Patch to fix segfault in ldconfig

Date: Sun, 01 Mar 2015 22:22:05 +0100

Control: tags -1 patch upstream

On Wed, 25 Feb 2015 13:49:00 -0500 "Lennart Sorensen"
<lsorense@csclub.uwaterloo.ca> wrote:
> I looked at ways the aux-cache could cause a segfault, and given the
> file is mmap'd and has data offsets in it that are used as pointers
> without being checked it is not hard to see how a corrupt file could
> cause a segfault.  The following patch makes the segfaults I was able
> to think of and create go away.
> 
> I also have included an example corrupted aux-cache file
> (aux-cache-corrupt-soname-offset) which has a bad offset that causes
> a segfault.
> 


Excellent, thanks.

I am taking the liberty of adding the patch tag for this one.  If
nothing else, I would greatly appreciate having ldconfig not seg. fault. :)

> There is another problem which I haven't solved but which is not a
> segfault.  If you somehow truncate the aux-cache file by a bit and run
> the previous ldconfig without my patch, then you end up with a corrupted
> aux-cache where some entries do not have soname's even though they should,
> and that causes you to get messages like:
> 

Sounds like the aux-cache could do with a checksum or something to catch
obvious corruptions.

> [...]
> 
> Using ldconfig -i (and hence ignoring the corrupted aux-cache) makes
> that problem go away.  To solve it would of course mean you have to
> not trust the cache which rather defeats the point of having the cache,
> so I don't know if that is worth trying to solve.  It does not cause a
> segfault however.
> 
> Using ldconfig -p to show the cache at that point has entries that are
> clearly wrong such as:
> 
> [...]


Or ldconfig needs some method to (fairly) reliably detect corruptions.
If it spits out errors about directories not being links, then something
notices a problem.  Perhaps this could be extended to discarding the
cache (even if "just" a """if (!ignore_cache) execve(argv, "-i", null);""").

Thanks,
~Niels

Message #77 received at 759530@bugs.debian.org (full text, mbox, reply):

From: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>

To: Niels Thykier <niels@thykier.net>

Cc: 759530@bugs.debian.org

Subject: Re: Patch to fix segfault in ldconfig

Date: Mon, 2 Mar 2015 13:54:56 -0500

On Sun, Mar 01, 2015 at 10:22:05PM +0100, Niels Thykier wrote:
> Excellent, thanks.
> 
> I am taking the liberty of adding the patch tag for this one.  If
> nothing else, I would greatly appreciate having ldconfig not seg. fault. :)

That makes sense to me.

> Sounds like the aux-cache could do with a checksum or something to catch
> obvious corruptions.

I very much agree, although that would of course be a format change and
then you would have to throw away the old file on upgrades.  Perfectly
reasonable and probably the best way to deal with all the corner cases
that I noticed for having it do the wrong thing when corrupted.

I wonder what upstream thinks of it.

> Or ldconfig needs some method to (fairly) reliably detect corruptions.
> If it spits out errors about directories not being links, then something
> notices a problem.  Perhaps this could be extended to discarding the
> cache (even if "just" a """if (!ignore_cache) execve(argv, "-i", null);""").

I thought that could work too.  It sounded rather ugly to do that though.

I rather like the checksum idea instead since it sounds more reliable
and simpler.

-- 
Len Sorensen

Message #82 received at 759530@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>, 759530@bugs.debian.org

Subject: Re: Bug#759530: Patch to fix segfault in ldconfig

Date: Sun, 8 Mar 2015 21:48:50 +0100

control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=18093

On 2015-02-25 13:49, Lennart Sorensen wrote:
> I looked at ways the aux-cache could cause a segfault, and given the
> file is mmap'd and has data offsets in it that are used as pointers
> without being checked it is not hard to see how a corrupt file could
> cause a segfault.  The following patch makes the segfaults I was able
> to think of and create go away.

Thanks for your work, it's nice we have been able to understand the real
issue.

> I also have included an example corrupted aux-cache file
> (aux-cache-corrupt-soname-offset) which has a bad offset that causes
> a segfault.

Unfortunately they doesn't seem to work here. That said I have been able
to reproduce the problem by truncating/changing the aux cache manually.

> There is another problem which I haven't solved but which is not a
> segfault.  If you somehow truncate the aux-cache file by a bit and run
> the previous ldconfig without my patch, then you end up with a corrupted
> aux-cache where some entries do not have soname's even though they should,
> and that causes you to get messages like:
> 
> /sbin/ldconfig.real: /lib/i386-linux-gnu/ is not a symbolic link
> 
> /sbin/ldconfig.real: /usr/lib/i386-linux-gnu/ is not a symbolic link
> 
> /sbin/ldconfig.real: /lib64/ is not a symbolic link
> 
> /sbin/ldconfig.real: /usr/lib64/ is not a symbolic link
> 
> /sbin/ldconfig.real: /libx32/ is not a symbolic link
> 
> /sbin/ldconfig.real: /usr/libx32/ is not a symbolic link
> 
> /sbin/ldconfig.real: /usr/lib/ is not a symbolic link
> 
> /sbin/ldconfig.real: /usr/lib/i386-linux-gnu/i586/ is not a symbolic link
> 
> /sbin/ldconfig.real: /usr/lib/i386-linux-gnu/i686/cmov/ is not a symbolic link
> 
> Using ldconfig -i (and hence ignoring the corrupted aux-cache) makes
> that problem go away.  To solve it would of course mean you have to
> not trust the cache which rather defeats the point of having the cache,
> so I don't know if that is worth trying to solve.  It does not cause a
> segfault however.
> 
> Using ldconfig -p to show the cache at that point has entries that are
> clearly wrong such as:
> 
> ...
>         day (libc6, OS ABI: Linux 2.6.32) => /lib/i386-linux-gnu/day
>         __kernel_sigreturn (libc6,x32, OS ABI: Linux 3.4.0) => /libx32/__kernel_sigreturn
>         X_2.6 (libc6) => /usr/lib/i386-linux-gnu/X_2.6
>         LF (libc6) => /usr/lib/i386-linux-gnu/LF
>  (libc6) => /usr/lib/ 
>          (libc6, OS ABI: Linux 2.6.32) => /lib/i386-linux-gnu/
>          (libc6, OS ABI: Linux 2.6.32) => /usr/lib/i386-linux-gnu/
>  (libc6) => /lib/i386-linux-gnu/
>  (libc6) => /usr/lib/i386-linux-gnu/
>          (libc6) => /usr/lib/i386-linux-gnu/
>          (libc6) => /usr/lib/i386-linux-gnu/
>          (libc6) => /usr/lib/i386-linux-gnu/
>          (libc6, OS ABI: Linux 2.6.32) => /lib/i386-linux-gnu/
>          (libc6, OS ABI: Linux 2.6.32) => /usr/lib/i386-linux-gnu/
>          (libc6,x32, OS ABI: Linux 3.4.0) => /libx32/
>          (libc6,x32, OS ABI: Linux 3.4.0) => /usr/libx32/
>          (libc6,x86-64, OS ABI: Linux 2.6.32) => /lib64/
>          (libc6,x86-64, OS ABI: Linux 2.6.32) => /usr/lib64/
>          (libc6, hwcap: 0x0008000000008000) => /usr/lib/i386-linux-gnu/i686/cmov/
>          (libc6, hwcap: 0x0004000000000000) => /usr/lib/i386-linux-gnu/i586/
>          (libc6) => /lib/i386-linux-gnu/
>          (libc6) => /usr/lib/i386-linux-gnu/
>          (libc6) => /usr/lib/
>         � (libc6) => /lib/i386-linux-gnu/�
> 
> The file aux-cache-missing-sonames shows this corrupted state.
> 
> I hope the patch at least helps solve the worst part of the problem.

I think the idea behind the patch is correct, but it is not fully
correct (or at least it only fixes corner cases).

> diff -ur --exclude debian --exclude build-tree glibc-2.19.ori/elf/cache.c glibc-2.19/elf/cache.c
> --- glibc-2.19.ori/elf/cache.c	2015-02-25 16:24:59.000000000 +0000
> +++ glibc-2.19/elf/cache.c	2015-02-25 17:42:18.000000000 +0000
> @@ -699,7 +699,8 @@
>    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)
> +      || sizeof(struct aux_cache_file) + (aux_cache->nlibs - 1) * sizeof(struct aux_cache_file_entry) >= aux_cache_size

Why using (aux_cache->nlibs - 1) and not directly aux_cache->nlibs here?

> +      || aux_cache->nlibs * sizeof(struct aux_cache_file_entry) + aux_cache->libs[aux_cache->nlibs - 1].soname >= aux_cache_size)

The best to catch all cases here is to compute the theoretical size of
the file using the headers and comparing it to the real one.

>      {
>        close (fd);
>        init_aux_cache ();
> @@ -712,12 +713,14 @@
>    const char *aux_cache_data
>      = (const char *) &aux_cache->libs[aux_cache->nlibs];
>    for (unsigned int i = 0; i < aux_cache->nlibs; ++i)
> -    insert_to_aux_cache (&aux_cache->libs[i].id,
> -			 aux_cache->libs[i].flags,
> -			 aux_cache->libs[i].osversion,
> -			 aux_cache->libs[i].soname == 0
> -			 ? NULL : aux_cache_data + aux_cache->libs[i].soname,
> -			 0);
> +    /* Only use entries with sane offsets */
> +    if (aux_cache->libs[i].soname < aux_cache_size)

The check is incorrect here, the address in aux_cache->libs[i].soname is
relative to aux_cache_data, so it probably catches very few cases.

> +      insert_to_aux_cache (&aux_cache->libs[i].id,
> +			   aux_cache->libs[i].flags,
> +			   aux_cache->libs[i].osversion,
> +			   aux_cache->libs[i].soname == 0
> +			   ? NULL : aux_cache_data + aux_cache->libs[i].soname,
> +			   0);
>  
>    munmap (aux_cache, aux_cache_size);
>    close (fd);


Please find a new patch below. I have submitted it upstream as bz 18093.
I am planning to wait for upstream answer or comment for other people a
few days. I'll then prepare an upload fixing this bug.

diff --git a/ChangeLog b/ChangeLog
index 4a5cd16..5086267 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2015-03-08  Aurelien Jarno  <aurelien@aurel32.net>
+
+	[BZ #18093]
+	* elf/cache.c (load_aux_cache): Regenerate the cache if it has the
+	wrong size. Ignore entries pointing outside of the mmaped memory.
+
 2015-03-08  Paul Pluzhnikov  <ppluzhnikov@google.com>
 
 	[BZ #16734]
diff --git a/elf/cache.c b/elf/cache.c
index 1732268..9131e08 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 ();
@@ -711,12 +713,13 @@ load_aux_cache (const char *aux_cache_name)
   const char *aux_cache_data
     = (const char *) &aux_cache->libs[aux_cache->nlibs];
   for (unsigned int i = 0; i < aux_cache->nlibs; ++i)
-    insert_to_aux_cache (&aux_cache->libs[i].id,
-			 aux_cache->libs[i].flags,
-			 aux_cache->libs[i].osversion,
-			 aux_cache->libs[i].soname == 0
-			 ? NULL : aux_cache_data + aux_cache->libs[i].soname,
-			 0);
+    if (aux_cache->libs[i].soname < aux_cache->len_strings)
+      insert_to_aux_cache (&aux_cache->libs[i].id,
+			   aux_cache->libs[i].flags,
+			   aux_cache->libs[i].osversion,
+			   aux_cache->libs[i].soname == 0
+			   ? NULL : aux_cache_data + aux_cache->libs[i].soname,
+			   0);
 
   munmap (aux_cache, aux_cache_size);
   close (fd);

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Message #89 received at 759530@bugs.debian.org (full text, mbox, reply):

From: "Lennart Sorensen" <lsorense@csclub.uwaterloo.ca>

To: Aurelien Jarno <aurelien@aurel32.net>

Cc: 759530@bugs.debian.org

Subject: Re: Bug#759530: Patch to fix segfault in ldconfig

Date: Sun, 8 Mar 2015 18:36:48 -0400

On Sun, Mar 08, 2015 at 09:48:50PM +0100, Aurelien Jarno wrote:
> Thanks for your work, it's nice we have been able to understand the real
> issue.

Well I thing the best summary of the problem is that the aux-cache
handling code is awful and doesn't check anything before using the
incoming data as a source for pointers.  Corrupt aux-cache files was
not even remotely considered.  Safest option right now would be to disable
the use of the aux-cache if you want to avoid segfaults in ldconfig.

> Unfortunately they doesn't seem to work here. That said I have been able
> to reproduce the problem by truncating/changing the aux cache manually.

Well it segfaulted on my amd64 system when I tried that file.  Of course
it may need to have the same set of libraries installed as I have.

> I think the idea behind the patch is correct, but it is not fully
> correct (or at least it only fixes corner cases).

I don't doubt I missed some of the problem cases.  Seems the best answer
would be to redesign it with a checksum and a size indicator or something
else that would catch corruption in general.

> > diff -ur --exclude debian --exclude build-tree glibc-2.19.ori/elf/cache.c glibc-2.19/elf/cache.c
> > --- glibc-2.19.ori/elf/cache.c	2015-02-25 16:24:59.000000000 +0000
> > +++ glibc-2.19/elf/cache.c	2015-02-25 17:42:18.000000000 +0000
> > @@ -699,7 +699,8 @@
> >    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)
> > +      || sizeof(struct aux_cache_file) + (aux_cache->nlibs - 1) * sizeof(struct aux_cache_file_entry) >= aux_cache_size
> 
> Why using (aux_cache->nlibs - 1) and not directly aux_cache->nlibs here?

Hmm, I seem to have misread the way the structure is defined, and thought
it always had one aux_cache_file_entry in the aux_cache_file struct,
but no it has 0 of them.

> > +      || aux_cache->nlibs * sizeof(struct aux_cache_file_entry) + aux_cache->libs[aux_cache->nlibs - 1].soname >= aux_cache_size)
> 
> The best to catch all cases here is to compute the theoretical size of
> the file using the headers and comparing it to the real one.

Well the filenames seem to be just stored at the end of the other data
with pointers to it (which is where most of the chances for segfaults
occur).  The format doesn't seem to actually have anything to cover the
size of that pile of strings.  There is really no way to know what the
filesize should be given the end is just a heap of c strings.  Did I
miss something?  You seem to be using anpother header thing that mentions
the string lengths.  Maybe I missed that existing.  That would be useful.

> >      {
> >        close (fd);
> >        init_aux_cache ();
> > @@ -712,12 +713,14 @@
> >    const char *aux_cache_data
> >      = (const char *) &aux_cache->libs[aux_cache->nlibs];
> >    for (unsigned int i = 0; i < aux_cache->nlibs; ++i)
> > -    insert_to_aux_cache (&aux_cache->libs[i].id,
> > -			 aux_cache->libs[i].flags,
> > -			 aux_cache->libs[i].osversion,
> > -			 aux_cache->libs[i].soname == 0
> > -			 ? NULL : aux_cache_data + aux_cache->libs[i].soname,
> > -			 0);
> > +    /* Only use entries with sane offsets */
> > +    if (aux_cache->libs[i].soname < aux_cache_size)
> 
> The check is incorrect here, the address in aux_cache->libs[i].soname is
> relative to aux_cache_data, so it probably catches very few cases.

Well it catches any where the offset is corrupt by a larger value
(doesn't have to be that large either).  But yes I did get that check
slightly wrong.  I think I changed it a few times while working out what
the code was trying to do with the data structure.

> > +      insert_to_aux_cache (&aux_cache->libs[i].id,
> > +			   aux_cache->libs[i].flags,
> > +			   aux_cache->libs[i].osversion,
> > +			   aux_cache->libs[i].soname == 0
> > +			   ? NULL : aux_cache_data + aux_cache->libs[i].soname,
> > +			   0);
> >  
> >    munmap (aux_cache, aux_cache_size);
> >    close (fd);
> 
> 
> Please find a new patch below. I have submitted it upstream as bz 18093.
> I am planning to wait for upstream answer or comment for other people a
> few days. I'll then prepare an upload fixing this bug.
> 
> diff --git a/ChangeLog b/ChangeLog
> index 4a5cd16..5086267 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,9 @@
> +2015-03-08  Aurelien Jarno  <aurelien@aurel32.net>
> +
> +	[BZ #18093]
> +	* elf/cache.c (load_aux_cache): Regenerate the cache if it has the
> +	wrong size. Ignore entries pointing outside of the mmaped memory.
> +
>  2015-03-08  Paul Pluzhnikov  <ppluzhnikov@google.com>
>  
>  	[BZ #16734]
> diff --git a/elf/cache.c b/elf/cache.c
> index 1732268..9131e08 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))

Yeah that looks right.

>      {
>        close (fd);
>        init_aux_cache ();
> @@ -711,12 +713,13 @@ load_aux_cache (const char *aux_cache_name)
>    const char *aux_cache_data
>      = (const char *) &aux_cache->libs[aux_cache->nlibs];
>    for (unsigned int i = 0; i < aux_cache->nlibs; ++i)
> -    insert_to_aux_cache (&aux_cache->libs[i].id,
> -			 aux_cache->libs[i].flags,
> -			 aux_cache->libs[i].osversion,
> -			 aux_cache->libs[i].soname == 0
> -			 ? NULL : aux_cache_data + aux_cache->libs[i].soname,
> -			 0);
> +    if (aux_cache->libs[i].soname < aux_cache->len_strings)
> +      insert_to_aux_cache (&aux_cache->libs[i].id,
> +			   aux_cache->libs[i].flags,
> +			   aux_cache->libs[i].osversion,
> +			   aux_cache->libs[i].soname == 0
> +			   ? NULL : aux_cache_data + aux_cache->libs[i].soname,
> +			   0);
>  
>    munmap (aux_cache, aux_cache_size);
>    close (fd);

I think that is at least a big improvement.  Not sure what would happen
if the null terminator on the last string got lost.  Hmm.  I didn't
test that.

Of course none of this solves the problem of the ld.so.cache being corrupt
already because the old ldconfig was run with a corrupt file but without
a segfault.  The only fix for that would be a sane check for corruption,
or not using the cache at all.

-- 
Len Sorensen

Message #96 received at 759530-close@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurel32@debian.org>

To: 759530-close@bugs.debian.org

Subject: Bug#759530: fixed in glibc 2.19-16

Date: Thu, 12 Mar 2015 22:34:34 +0000

Source: glibc
Source-Version: 2.19-16

We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 759530@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Aurelien Jarno <aurel32@debian.org> (supplier of updated glibc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Thu, 12 Mar 2015 22:00:40 +0100
Source: glibc
Binary: libc-bin libc-dev-bin glibc-doc glibc-source locales locales-all nscd multiarch-support libc6 libc6-dev libc6-dbg libc6-pic libc6-udeb libc6.1 libc6.1-dev libc6.1-dbg libc6.1-pic libc6.1-udeb libc0.3 libc0.3-dev libc0.3-dbg libc0.3-pic libc0.3-udeb libc0.1 libc0.1-dev libc0.1-dbg libc0.1-pic libc0.1-udeb libc6-i386 libc6-dev-i386 libc6-sparc libc6-dev-sparc libc6-sparc64 libc6-dev-sparc64 libc6-s390 libc6-dev-s390 libc6-amd64 libc6-dev-amd64 libc6-powerpc libc6-dev-powerpc libc6-ppc64 libc6-dev-ppc64 libc6-mips32 libc6-dev-mips32 libc6-mipsn32 libc6-dev-mipsn32 libc6-mips64 libc6-dev-mips64 libc0.1-i386 libc0.1-dev-i386 libc6-x32 libc6-dev-x32 libc6-i686 libc6-xen libc0.1-i686 libc0.3-i686 libc0.3-xen libc6.1-alphaev67 libc6-loongson2f libnss-dns-udeb libnss-files-udeb
Architecture: source all amd64
Version: 2.19-16
Distribution: unstable
Urgency: medium
Maintainer: Aurelien Jarno <aurel32@debian.org>
Changed-By: Aurelien Jarno <aurel32@debian.org>
Description:
 glibc-doc  - GNU C Library: Documentation
 glibc-source - GNU C Library: sources
 libc-bin   - GNU C Library: Binaries
 libc-dev-bin - GNU C Library: Development binaries
 libc0.1    - GNU C Library: Shared libraries
 libc0.1-dbg - GNU C Library: detached debugging symbols
 libc0.1-dev - GNU C Library: Development Libraries and Header Files
 libc0.1-dev-i386 - GNU C Library: 32bit development libraries for AMD64
 libc0.1-i386 - GNU C Library: 32bit shared libraries for AMD64
 libc0.1-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc0.1-pic - GNU C Library: PIC archive library
 libc0.1-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc0.3    - GNU C Library: Shared libraries
 libc0.3-dbg - GNU C Library: detached debugging symbols
 libc0.3-dev - GNU C Library: Development Libraries and Header Files
 libc0.3-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc0.3-pic - GNU C Library: PIC archive library
 libc0.3-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc0.3-xen - GNU C Library: Shared libraries [Xen version]
 libc6      - GNU C Library: Shared libraries
 libc6-amd64 - GNU C Library: 64bit Shared libraries for AMD64
 libc6-dbg  - GNU C Library: detached debugging symbols
 libc6-dev  - GNU C Library: Development Libraries and Header Files
 libc6-dev-amd64 - GNU C Library: 64bit Development Libraries for AMD64
 libc6-dev-i386 - GNU C Library: 32-bit development libraries for AMD64
 libc6-dev-mips32 - GNU C Library: o32 Development Libraries for MIPS
 libc6-dev-mips64 - GNU C Library: 64bit Development Libraries for MIPS64
 libc6-dev-mipsn32 - GNU C Library: n32 Development Libraries for MIPS64
 libc6-dev-powerpc - GNU C Library: 32bit powerpc development libraries for ppc64
 libc6-dev-ppc64 - GNU C Library: 64bit Development Libraries for PowerPC64
 libc6-dev-s390 - GNU C Library: 32bit Development Libraries for IBM zSeries
 libc6-dev-sparc - GNU C Library: 32bit Development Libraries for SPARC
 libc6-dev-sparc64 - GNU C Library: 64bit Development Libraries for UltraSPARC
 libc6-dev-x32 - GNU C Library: X32 ABI Development Libraries for AMD64
 libc6-i386 - GNU C Library: 32-bit shared libraries for AMD64
 libc6-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc6-loongson2f - GNU C Library: Shared libraries (Loongson 2F optimized)
 libc6-mips32 - GNU C Library: o32 Shared libraries for MIPS
 libc6-mips64 - GNU C Library: 64bit Shared libraries for MIPS64
 libc6-mipsn32 - GNU C Library: n32 Shared libraries for MIPS64
 libc6-pic  - GNU C Library: PIC archive library
 libc6-powerpc - GNU C Library: 32bit powerpc shared libraries for ppc64
 libc6-ppc64 - GNU C Library: 64bit Shared libraries for PowerPC64
 libc6-s390 - GNU C Library: 32bit Shared libraries for IBM zSeries
 libc6-sparc - GNU C Library: 32bit Shared libraries for SPARC
 libc6-sparc64 - GNU C Library: 64bit Shared libraries for UltraSPARC
 libc6-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc6-x32  - GNU C Library: X32 ABI Shared libraries for AMD64
 libc6-xen  - GNU C Library: Shared libraries [Xen version]
 libc6.1    - GNU C Library: Shared libraries
 libc6.1-alphaev67 - GNU C Library: Shared libraries (EV67 optimized)
 libc6.1-dbg - GNU C Library: detached debugging symbols
 libc6.1-dev - GNU C Library: Development Libraries and Header Files
 libc6.1-pic - GNU C Library: PIC archive library
 libc6.1-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libnss-dns-udeb - GNU C Library: NSS helper for DNS - udeb (udeb)
 libnss-files-udeb - GNU C Library: NSS helper for files - udeb (udeb)
 locales    - GNU C Library: National Language (locale) data [support]
 locales-all - GNU C Library: Precompiled locale data
 multiarch-support - Transitional package to ensure multiarch compatibility
 nscd       - GNU C Library: Name Service Cache Daemon
Closes: 583088 759530 779442
Changes:
 glibc (2.19-16) unstable; urgency=medium
 .
   [ Samuel Thibault ]
   * patches/hurd-i386/cvs-libpthread-dlopen.diff: New patch to allow
     libpthread.so to be dynamically loaded from a dlopened library.
   * patches/hurd-i386/cvs-libpthread-libc-lockP{,2}.diff: New patch to
     dynamically call pthread functions from libc.
 .
   [ Aurelien Jarno ]
   * We have a transition mechanism for the locales, as the Debian archive
     used to expose arch:all packages on all architectures even when the
     corresponding arch:any package is not available yet. This has been
     fixed long time ago, the transition mechanism has not been used
     correctly for a lot of time and has been broken by the split out of
     libc-bin. The breakage has been partially fixed by the "Breaks: locales
     (<< 2.19)" added to libc6. It's now time to add the missing "Depends:
     libc-bin (>> 2.19)" to locales and remove the transition mechanism.
     Closes: #583088, #779442
   * patches/any/cvs-ldconfig-aux-cache.diff: new patch from upstream to
     ignore corrupted aux-cache instead of segfaulting. Closes: #759530.
Checksums-Sha1:
 b9d5202953beafba67e6d6520c8fc64ceacc0a27 8208 glibc_2.19-16.dsc
 97b0e66d684c717c76dfe16a9161dac24aa5bf98 1030480 glibc_2.19-16.debian.tar.xz
 9206372adf26cbcf1e54baa19e6e11a97213d6ed 2265710 glibc-doc_2.19-16_all.deb
 cac0585fdf9ab0aab344c83e379ddc1ea19b25e1 13966080 glibc-source_2.19-16_all.deb
 fa5e285d26606bd970f27f79cb04101a9342954e 3932484 locales_2.19-16_all.deb
 6f37f1fd74abf5dec00616fcfa92516138803cc9 4659012 libc6_2.19-16_amd64.deb
 6d920efa65114019917686dc46c0b81d061629a1 1996932 libc6-dev_2.19-16_amd64.deb
 be59337ea3d723143bddea44e796f34769086b97 1473898 libc6-pic_2.19-16_amd64.deb
 6353152c145278a88a24d9c46e50313e98d13b56 1283362 libc-bin_2.19-16_amd64.deb
 533fb737fd0aa6d41b6383c3be5e389c9acf83ae 236592 libc-dev-bin_2.19-16_amd64.deb
 0addc6d748c88e2193ba261aa1a4c905cc25b99f 178580 multiarch-support_2.19-16_amd64.deb
 e75082721ab164527acd2fd4fd29e0af41a433b8 3195342 locales-all_2.19-16_amd64.deb
 644f13140907c0f960e85413da80f0fbfdd7b501 2366580 libc6-i386_2.19-16_amd64.deb
 7b5cd905020f7c3e0aeb307a643ee56743771ec3 1314122 libc6-dev-i386_2.19-16_amd64.deb
 b1c61af4ec488ddc42b0811ecee233800c99fedb 2594410 libc6-x32_2.19-16_amd64.deb
 2b6a1a57d2d699a7f8aa073c7b47ce5049fec915 1581394 libc6-dev-x32_2.19-16_amd64.deb
 9247673be492b7fa442d6eded4e89735317cfc56 241930 nscd_2.19-16_amd64.deb
 a4d156250ba8a9394bb4eb96aee4b4cc8ee99e7c 3417462 libc6-dbg_2.19-16_amd64.deb
 14ec7d5a22f4e435be4ef2914d6ae8032862080d 1058590 libc6-udeb_2.19-16_amd64.udeb
 3bc41f081b5e74ad76a49b25c1bb85e080296044 10058 libnss-dns-udeb_2.19-16_amd64.udeb
 c0cbd6598bdc9d10a7178a95000f85345d222ac8 16406 libnss-files-udeb_2.19-16_amd64.udeb
Checksums-Sha256:
 14f4a3f751967426d801c71d8848c64790d8eba2719d3d24285f884a96cc49d7 8208 glibc_2.19-16.dsc
 a3bbd93bb0fbe47454deca8738190d365c8ed3f2613a32618c4fbd8267a12efe 1030480 glibc_2.19-16.debian.tar.xz
 b2e53e6d1578a6c24013530f77a5471d1a44fbfcb809b8c9fe21236845eaf32d 2265710 glibc-doc_2.19-16_all.deb
 8df25ab32411ae5fb97c8493c114b47968430c131b094ca3b492bff143c128e3 13966080 glibc-source_2.19-16_all.deb
 b3dd50f0f74a82d944f77d2917608e0fde57c3fcc9476264d4de3923b082aab4 3932484 locales_2.19-16_all.deb
 0fb076febf78c9c939c11a261b25694f25b836fe31e2f965c960d387fdd32fda 4659012 libc6_2.19-16_amd64.deb
 b3be96623cc5a79b3937b3365a9f329864da14b44aaa2fa2c033fd551643b699 1996932 libc6-dev_2.19-16_amd64.deb
 6a26ba1c7604166a28066c0bf9022ca45de4fc0b2a168bc4fc0bbef495ab81fa 1473898 libc6-pic_2.19-16_amd64.deb
 15a60f5985301afa917a43b1e915b15f49bec05d450518b5b9cb1c9f7e56f9c7 1283362 libc-bin_2.19-16_amd64.deb
 e86002937d6a587641e07d67744dc06c60bf39f498a5e5f0c4dd8abb3729420e 236592 libc-dev-bin_2.19-16_amd64.deb
 6469fd4ef84337c194e1df50aaf9f560d5f48bde9690dbfe6389639ed2e36a7a 178580 multiarch-support_2.19-16_amd64.deb
 2076c9715a1fd67f57b24990dca7ab1c7bcded0316d9ee8907c3b9ba4c93269a 3195342 locales-all_2.19-16_amd64.deb
 0d5cad53821ad84cdf559cb189bfe1f41f7c862dade8b21e3e81afa8dbbe929e 2366580 libc6-i386_2.19-16_amd64.deb
 1e0b49560893bb7855989d8ba96682f33442331329c62e4f9d1ac1950824aa44 1314122 libc6-dev-i386_2.19-16_amd64.deb
 4500e2ef58be2f3da78ec14681aeb8a5e1196276a61ce0d98b8a471e726f887a 2594410 libc6-x32_2.19-16_amd64.deb
 2e38aeaa41845a2080c3094bd632f8cbae60c6a9b5632bf40316c991abc02dd4 1581394 libc6-dev-x32_2.19-16_amd64.deb
 ed4341af99e2705af2ff335e5165ec11edf1c02406726bc89686364b2631c8fe 241930 nscd_2.19-16_amd64.deb
 6db0e549ffecdf51df4d32f8d7cc3081717292a906a209c92251c16ca788dbb3 3417462 libc6-dbg_2.19-16_amd64.deb
 6dcb5fc8b7d29aae06cfe9aaa6f2755b625d0346449814bc3b77b04525a0b198 1058590 libc6-udeb_2.19-16_amd64.udeb
 2ec4c728d2d8a6fe947ce7a983269bb996864fbc6267b044a5ec39d7f73d83bf 10058 libnss-dns-udeb_2.19-16_amd64.udeb
 d7cae65e06f2a5ed2ee4a867a9049ccc6bdb6dff408fc9ee7d1ddf4d4df73d27 16406 libnss-files-udeb_2.19-16_amd64.udeb
Files:
 657092b5a73a56ce386c0cad5cadcf1f 8208 libs required glibc_2.19-16.dsc
 9b44df6a4ddbf973d5a3e1181d3e196b 1030480 libs required glibc_2.19-16.debian.tar.xz
 4b559176c04a8e02e54311671247ea4c 2265710 doc optional glibc-doc_2.19-16_all.deb
 7795fd6638e576ba839e56086eb92b99 13966080 devel optional glibc-source_2.19-16_all.deb
 f633ae004e4f92daa2ba4c71e309a652 3932484 localization standard locales_2.19-16_all.deb
 eeecf89341835c6d830eaded997c648b 4659012 libs required libc6_2.19-16_amd64.deb
 fd183fce61c6094e1d2092983f46baed 1996932 libdevel optional libc6-dev_2.19-16_amd64.deb
 6a1953ac8cdfb12605cc886c1f040032 1473898 libdevel optional libc6-pic_2.19-16_amd64.deb
 8e7e6c9223e6c09534fba55c6a630621 1283362 libs required libc-bin_2.19-16_amd64.deb
 baa35ac1b61ff16f957315ceea3c7168 236592 libdevel optional libc-dev-bin_2.19-16_amd64.deb
 5176306a19171e98d173881680ef0d1a 178580 libs required multiarch-support_2.19-16_amd64.deb
 0df92659b9fd9ccb1eb8120704f7233e 3195342 localization extra locales-all_2.19-16_amd64.deb
 c79ffe01eba2c923f30f13e57c9ca15c 2366580 libs optional libc6-i386_2.19-16_amd64.deb
 0dded248048825a5fddf1bc7c5534ca8 1314122 libdevel optional libc6-dev-i386_2.19-16_amd64.deb
 6833e069137df57ce21b99cdd6d56020 2594410 libs optional libc6-x32_2.19-16_amd64.deb
 19108d513f57dc70406e18e45dbcf03d 1581394 libdevel optional libc6-dev-x32_2.19-16_amd64.deb
 cc44035053d5c065afaf2d1c9ec16e7f 241930 admin optional nscd_2.19-16_amd64.deb
 e5f13839d0db2f77afe95eef24596bd8 3417462 debug extra libc6-dbg_2.19-16_amd64.deb
 b458e5a54e8243bf6a3a5455cce27347 1058590 debian-installer extra libc6-udeb_2.19-16_amd64.udeb
 6de515576383e99d0cb92ec91af9f814 10058 debian-installer extra libnss-dns-udeb_2.19-16_amd64.udeb
 51f3067bd7fec85eb6f9b7f7a065ff4d 16406 debian-installer extra libnss-files-udeb_2.19-16_amd64.udeb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVAg4KAAoJELqceAYd3YybO7IP/2J85/ERUkfAnGCrFgSthXnn
Qs3Uvf/r5v1hGzu4B0nnzguidpvkUXsS0aWGnxQFS7yWPKL5lA9slEn6yh2RnRPP
LFkhNcfp4aaFWfXT/FpZLsVPjBQb2X2YvpsvPr6UdRGVzzUlyU35VPODcrHF7iDM
2E++l7yFrmmjZAnZiG2aAEn1pAKrM0WKjBjVBtRWkR4SpPMMRLv7a2CYiVymoOa+
ZNZ1EVGjG6OOeWqrk+gtw3ayIs2wVFNdc53Zjy1EtvnpbOIm4yHYnUGj0HL5y06e
bPtR55rZLcP86C8GOXZQUWYCdrWG1Ooc02LmhDCM7DwZVWc60zHqVDtMcDmPYHYF
xUYpqtietqF8+/+Wr5pvrofBq88AOU9A64ZNWTjyS23H4llr4PuUArdN55yThS5E
vJFh8SSVYvN6xPGjJzPQ30GVxOaxRr87lR7BV8lD+2kGaO2bzWlIhLt8C4ciebF7
nLZ043HVDzwxty8nvr2ROsanPYYbLw5TvclwZMRpV6HShpmIEkzPzMeZ9Asgx4/y
erOkFD0+mwzOpMOrEt1joWE5yLE82QvUuMZyMFZjq5oQncK+UMANGNpuDAkOMYkk
+V8hBPhQ2j1MVpfXTqsBs7+Kn0fnBKqIHYNJfli8ykBve8+3qVBUHFBCUl0kEX6m
2yRLAngWKnSKB0Zm6NLs
=yl+H
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.