Bug 23964 - ldconfig: file truncated while reading soname for certain libraries
Summary: ldconfig: file truncated while reading soname for certain libraries
Status: RESOLVED DUPLICATE of bug 25087
Alias: None
Product: glibc
Classification: Unclassified
Component: dynamic-link (show other bugs)
Version: 2.28
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-08 19:32 UTC by Eamonn Coughlan
Modified: 2020-04-07 15:54 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
Example fix for ldconfig (1.02 KB, patch)
2018-12-09 13:35 UTC, Eamonn Coughlan
Details | Diff
example ELF file (601.92 KB, application/x-sharedlib)
2020-04-07 15:46 UTC, Mikhail Novosyolov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eamonn Coughlan 2018-12-08 19:32:19 UTC
Dynamic libraries that have been processed by the popular patchelf utility, are ignored by ldconfig with a truncation error.

Assuming you have patchelf installed, this can be verified like so:

    ~/tmp % cp /usr/lib/libpcre.so libpcrecool.so
    ~/tmp % patchelf --set-soname libpcrecool.so.1 libpcrecool.so
    ~/tmp % ldconfig -l libpcrecool.so
    ldconfig: file libpcrecool.so is truncated

    ldconfig: No link created since soname could not be found for libpcrecool.so
    ~/tmp % readelf -d libpcrecool.so|grep SONAME
    0x000000000000000e (SONAME)             Library soname: [libpcrecool.so.1]

This is due to the loadaddr calculation in readelflib.c assuming that the vaddr which is read from the first STRTAB section in the dynamic segment can be resolved in the first LOAD segment.
The patchelf utility however changes or adds entries to .dynstr, and then relocates it to a new LOAD segment at the end of the file.

The vaddr found at the PT_DYNAMIC->(first STRTAB)->d_un.d_ptr should be checked against each LOAD segment, not just the first one.

All relevant versions up to the current master exhibit this bug.
Comment 1 Eamonn Coughlan 2018-12-09 13:35:33 UTC
Created attachment 11444 [details]
Example fix for ldconfig
Comment 2 Mikhail Novosyolov 2020-04-07 15:46:28 UTC
Created attachment 12446 [details]
example ELF file

Thanks for this patch, it solved the problem in glibc 2.24. The problem is also present in glibc 2.30. But seems that it is no more present in glibc 2.31.

rosa-2016 lib64 # ldconfig -V  |head -n 1
ldconfig (GNU libc) 2.24
rosa-2016 lib64 # ldconfig -l libstdc++-gcc10.so.6.0.28
ldconfig: file libstdc++-gcc10.so.6.0.28 truncated
<...>

user@pay2:/tmp/lib64stdc++-gcc10_6-10-0.20200301.1-rosa2016.1.x86_64/usr/lib64$ LC_ALL=C ldconfig -V | head -n 1
ldconfig (Ubuntu GLIBC 2.30-0ubuntu2.1) 2.30
user@pay2:/tmp/lib64stdc++-gcc10_6-10-0.20200301.1-rosa2016.1.x86_64/usr/lib64$ LC_ALL=C ldconfig -l libstdc++-gcc10.so.6.0.28
/sbin/ldconfig.real: file libstdc++-gcc10.so.6.0.28 is truncated
<...>

[root@rosa-2019 lib64]# ldconfig -V | head -n 1
ldconfig (GNU libc) 2.31
[root@rosa-2019 lib64]# ldconfig -l libstdc++-gcc10.so.6.0.28
[root@rosa-2019 lib64]# 

So, this bug probably can be closed.
Comment 3 Florian Weimer 2020-04-07 15:54:20 UTC
Bug 25087 fixed patchelf'ed ELF objects according to the mailing list: https://sourceware.org/pipermail/libc-alpha/2019-October/107378.html

*** This bug has been marked as a duplicate of bug 25087 ***