ldconfig makes system loader /lib/ld-linux.so.2 to be linked to 3rd party loaders in /lib directory

This bug was also reported in the Debian bug tracker (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655711) and some more details were posted there:

"Yes, I am doing some test/check with different ubuntu versions and this
issue observed or encountered only on Ubuntu 11.04. Also not been seeing
this on earlier versions and recent Ubuntu 11.10.

Yes, you are right that the SONAME of our loader ld-<name>.so.2 loader is
pointing to system loader ld-linux.so.2.
The output of "readelf" is below:

root@ubuntuserver1104:~# readelf -d /lib/ld-<name>.so.2 | grep SONAME
 0x0000000e (SONAME) Library soname: [ld-linux.so.2]

Its curious to know that, why this is only happening on Ubuntu 11.04? Any
specific dependent with ldconfig? and not observed on other ubuntu
versions even though the soname encoded is same as ld-linux.so.2."

Status changed to 'Confirmed' because the bug affects multiple users.

I am also experiencing this same issue, on Ubuntu 11.04. We have installed McAfee which has their own link loader, and that destabilises the entire OS. Can we get a fix for this as our systems are fragile due to this issue?
/lib/ld-linux.so.2 is linked like

/lib/ld-linux.so.2 -> i386-linux-gnu/ld-linux.so.2
 and in turn i386-linux-gnu/ld-linux.so.2 is linked as

/lib/i386-linux-gnu/ld-linux.so.2 -> ld-2.13.so

this is broken and get linked with McAfee loader whenever we install package using dpkg. Appreciate urgent solution on this !

I have same issue on Ubuntu 11.04 with McAfee. When Installing packages System get unstable

Hi Team,
 Can we get this issue resolved? I am unable to have a McAfee on Ubuntu 11.04 as it destabilises the operating system with third party loader. Tried with providing aliases to dpkg and apt-get but still unattended upgrades destabilises the OS through third party loader.

  Appreciate urgent help on this!

Cheers!
Rasika Karunathilaka.

i have encountered the same issue.
:(

Hi I have faced with the same isse with ubuntu 11.04 with McAfee

ldconfig is doing exactly what it was designed to do, which is to link SONAMEs to libraries providing that SONAME in the same directory. This is more a case of "don't do that, then" than a bug in glibc.

Since there was much asking about why this only happens in recent versions of Ubuntu, it's because the real linker (ld-2.1x.so) used to live in /lib until we moved to multiarch so, due to SHEER LUCK because of sort order, it was scanned first, and subsequent providers of the SONAME were ignored. Now that it lives in a different directory, third party linkers in /lib that provide the incorrect SONAME get picked up and symlinked. The solution here is really to not provide the same SONAME as the system linker, but a quick workaround for those affected could also be to move the offending third-party binary to the multi-arch path instead.

I could fix it in this way

http://ishanaba.com/blog/2013/02/how-did-i-fix-ubuntu-mcafee-issue/

may be not the best way

Here is something I have discoverd with this bug. The problem is caused by ldconfig following a symbolic link that points to a symbolic link. man ldconfig indicates that ldconfig should ignore symbolic links. We are running the McAfee Epo Ageent and LinuxShield. (we are also running the McAfee product on Redhat 5-enterprise, and this problem does not occur.)

In /lib, ld-nails.so.2 and ld-mfert.so.2 are both symboic links that point to a ld-linux.so.2 in McAfees /lib, ld-linux.so.2 in the mcafee libs are symbolic links to a mcafee lib. For Example. ld-mfert.so.2 in /lib points to /opt/McAfee/runtime/2.0/lib/ld-linux.so.2 which is a symbolic link to /opt/McAfee/runtime/2.0/lib/ld-2.5.so

Output of ldconfig -N -X -v shows that ldconfig is linking ld-linux.so.2 to /lib/ld-nails.so.2 or /llib/d-mfert.so.2.

ldconfig is following the symbolic link in /lib, and since the McAfee files contain the SONAME ld-linux.so.2, it links them to /lib
It appears that ldconfig is resolving the links, as the ld-linux.so.2 that it links in /lib fromo the MacAfee file (in this case ld-mfert.so.2) will point to /opt/McAfee/runtime/2.0/lib/ld-2.5.so

Note: once your system has been corrupted, an easy fix is to boot with a live cd, mount the root file system (for example, to /mnt/fubarroot) then use copy -P to copy /lib/ld-linux.so.2 from the live cd to your mounted root file system's /lib (copy -P /lib/ld-linux.so.2 /mnt/fubarroot/lib ) - reboot and all is well until ldconfig gets run again. The best workarount I have seen is to shut down nails and cma, remove the links, run updates, re-create the McAfee Links, restart cma and nails.

Scripts I use:

mcoff
#!/bin/sh
# keep McAfee from stepping on /lib/ld-linux.so.2
# turn off McAfee and unlink libs in /lib
/etc/init.d/nails stop
/etc/init.d/cma stop
rm /lib/ld-mfert.so.2
rm /lib/ld-nails.so.2
echo McAfee Agent and VSE Disabled

mcon
#!/bin/sh
# keep McAfee from stepping on /lib/ld-linux.so.2
# re-enable links and restart McAfee

ln -s /opt/McAfee/runtime/2.0/lib/ld-linux.so.2 /lib/ld-mfert.so.2
ln -s /opt/NAI/LinuxShield/lib/ld-linux.so.2 /lib/ld-nails.so.2
/etc/init.d/cma start
/etc/init.d/nails start
echo McAfee Agent and VSE enabled

Same issue in Ubuntu 10.04.4 (latest updates).

Some information from McAfee: https://kc.mcafee.com/corporate/index?page=content&id=KB75925&actp=LIST

My workaround for Ubuntu 10.04.4:
$ sudo ln -s /lib32/ld-linux.so.2 /lib/ld-~fix-linux.so.2

@Adam: thank you for the detailed explanation. Now it seems as this is a McAfee bug, however they don't agree https://kc.mcafee.com/corporate/index?page=content&id=KB75925&actp=LIST

> My workaround for Ubuntu 10.04.4:
> $ sudo ln -s /lib32/ld-linux.so.2 /lib/ld-~fix-linux.so.2
This works for Ubuntu 12.04.2 also, however make sure libc6-i386 is installed before you create a link (this is true for both 10.04 and 12.04). Otherwise ldconfig is going to remove the link.

For 32-bit system the link has to be slightly different:
$ sudo ln -s /lib/i386-linux-gnu/ld-linux.so.2 /lib/ld-~fix-linux.so.2

This bug was fixed in the package eglibc - 2.19-0ubuntu2

---------------
eglibc (2.19-0ubuntu2) trusty; urgency=medium

  * Merge with unreleased 2.19 from Debian experimental, fixing some bugs:
    - debian/patches/any/local-no-malloc-backtrace.diff: Lower the default
      for MALLOC_CHECK_ to 1, and add it to the list of insecure variables
      that can't be set for suid binaries. This allows us to not backtrace
      malloc failures by default (Closes: #739913, LP: #1266492) and skips
      backtrace for suid binaries where an attacker calling into a corrupt
      malloc internal data structure with malloc could lead to Bad Things.
    - Make ldconfig stop operating on the linker entirely, so our packaged
      symlinks take precedence and hack the postinst to skip ldconfig when
      we detect a broken setup that the old ldconfig mangles (LP: #915995)
 -- Adam Conrad <email address hidden> Sun, 23 Feb 2014 22:39:18 -0700