Public bug reported:

The runtime linker+loader /lib/ld-linux-armhf.so.3 makes an incorrect check for 
a loadable shared library.  Subroutine check_arm_attributes_hfabi() in file 
glibc/elf/dl-load.c currently looks only at the Elf(W)Shdr records of type 
SHT_ARM_ATTRIBUTES, and ignores Elf(W)Ehdr.e_flags.  The result is that some 
shared libraries that do work correctly (in every respect) are refused loading 
with the message
   <main_program_path>: error while loading shared libraries: 
<shared_library_name>: cannot open shared object file: No such file or directory
In particular, when a shared library has no Shdr records (.e_shnum == 0) then 
ld-linux-armhf refuses to load that library, even though e_flags indicates that 
everything is correct.

An ELF file has two sets of information for a module (main program or
shared library): the execution view, and the linking view.  The
execution view is in Ehdr and Phdr, the linking view is in Ehdr and
Shdr.  The design intent is that the static linker /bin/ld takes input
only from the linking view, and the runtime linker+loader ld-linux-armhf
takes input only from the execution view.  Any use of Shdr records by
ld-linux-armhf is a violation of the design intent.

In this particular case, the relevant information in SHT_ARM_ATTRIBUTES
regarding the use of the floating-point ABI is summarized in flag bits
in .e_flags, namely the EF_ARM_ABI_FLOAT_HARD bit.  So if there are no
Shdr records, then the e_flags should be consulted.  (Actually all the
code that delves into Shdr could [should] be replaced by a simple check
of e_flags; but keeping the existing Shdr code then checking e_flags
last is in some sense the "smallest" fix.)

A patch which adds the check on e_flags is:
--- elf/dl-load.c.orig  2017-08-24 09:51:11.000000000 -0700
+++ elf/dl-load.c       2017-08-24 14:47:48.525189652 -0700
@@ -1628,6 +1628,8 @@
         }
     }
 
+  /* This one statement using e_flags could [should] replace EVERYTHING above! 
*/
+  *is_hf = !!(ehdr->e_flags & EF_ARM_ABI_FLOAT_HARD);
   return 0;
 }
 

[The problem in this bug report was discovered in
https://github.com/upx/upx/issues/116 .]

$ lsb_release -rd
Description:    Ubuntu 16.04.2 LTS
Release:        16.04
$ apt-cache policy libc6:armhf
libc6:
  Installed: 2.23-0ubuntu5
  Candidate: 2.23-0ubuntu9
  Version table:
     2.23-0ubuntu9 500
        500 http://ports.ubuntu.com xenial-updates/main armhf Packages
        500 http://ports.ubuntu.com xenial-security/main armhf Packages
 *** 2.23-0ubuntu5 100
        100 /var/lib/dpkg/status
     2.23-0ubuntu3 500
        500 http://ports.ubuntu.com xenial/main armhf Packages

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: libc6:armhf 2.23-0ubuntu5
Uname: Linux 4.4.38-v7+ armv7l
ApportVersion: 2.20.1-0ubuntu2.5
Architecture: armhf
CurrentDesktop: XFCE
Date: Thu Aug 24 15:10:30 2017
Dependencies:
 gcc-6-base 6.0.1-0ubuntu1
 libc6 2.23-0ubuntu5
 libgcc1 1:6.0.1-0ubuntu1
SourcePackage: glibc
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: glibc (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: apport-bug armhf xenial

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1712938

Title:
  error while loading shared libraries: cannot open shared object file:
  No such file or directory

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1712938/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to