Using a libc.so from a previous kernel patch (Just Don't)
By Alan Hargreaves-Oracle on Jul 30, 2012
I was just assisting a colleague with an issue that after patching they found that there was higher lock spinning in malloc() in libc.
He just told me that the customer copied the old libc into a directory in /tmp, changed LD_LIBRARY_PATH to point there first and ran their application observing that the issue went away.
OK, where do we start here, ...
Two things immediately spring to mind as to why this is a bad idea.
- libc is tightly linked to the kernel system call interfaces. These interfaces are private to libc. As such they can be changed as long as the same change is made in the libc code. If you mismatch libc and the kernel you risk incorrectly calling system calls, with potentially fatal consequences.
- Placing a library into /tmp (or a directory under /tmp). Picture the following scenario. Someone builds their own library (doesn't have to be libc, just has to be something that your application uses) and places it into the directory you added to your search path (eg renaming your directory and creating their own). Now we have the potential of having your application run trojan code with any kind of side effect. Similar issues if you leave the path in a startup script and reboot, if the directory doesn't exist, anyone can create it and do the same thing.
In short, please don't.