[Bug 1712938] Re: error while loading shared libraries: cannot open shared object file: No such file or directory

[Launchpad Bug Tracker]

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

** Changed in: glibc (Ubuntu)
       Status: New => Confirmed

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

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

Status in glibc package in Ubuntu:
  Confirmed

Bug description:
  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)

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