Bug: libc invalid ELF header (not always)

[tomash]

Describe the bug

Xperia XZ2 Compact, Userland running Ubuntu with LXDE. These are my first hours with Userland.

At first I was getting error with not found libdl:

tomek@localhost:~$ wget https://cache.ruby-lang.org/pub/ruby/2.6/ruby-2.6.6.tar.bz2
wget: error while loading shared libraries: libdl.so: cannot open shared object file: No such file or directory

So I did apt install build-essential, it all went fine (despite a few warnings from update-alternatives) but now wget and curl (for example) throw libc ELF header error:

tomek@localhost:~$ wget
wget: error while loading shared libraries: /usr/lib/aarch64-linux-gnu/libc.so: invalid ELF header
tomek@localhost:~$ curl
curl: error while loading shared libraries: /usr/lib/aarch64-linux-gnu/libc.so: invalid ELF header

BUT, and this is where it gets weird: terminal windows that open with starting a new LXDE session have proper, running wget and curl (these are the ones I'm interested mostly at the moment because I'm setting up a development environment with asdf). But new terminal session, both xterm and lxdeterminal, throw that invalid ELF header error.

I've poked a bit and found the difference between these terminal sessions: the new, faulty ones, have LD_LIBRARY_PATH environment variable set:

tomek@localhost:~$ env | grep LD
LD_LIBRARY_PATH=/data/user/0/tech.ula/files/support

while the "startup", working ones don't have this at all. And if I override this env variable then suddenly voila, everything works again:

tomek@localhost:~$ LD_LIBRARY_PATH="" wget
wget: missing URL
Usage: wget [OPTION]... [URL]...

Try `wget --help' for more options.

And of course export LD_LIBRARY_PATH="" fixes the problem permanently for a given session. So, at least there's a workaround. Still, it's a bug and it's weird.

Steps to reproduce the behavior:

Besides apting a few packages, the only modification I did to stock system was adding autocutsel to ~/.vnc/xstartup.

Screenshots

Device Information

Device: Xperia XZ2 Compact (H8324) Android Version: 10.0.
UserLAnd Version: 2.7.3.
Whether the device is rooted: no Whether the device is running LineageOS: no

[murry2018]

Same problem occurs from cmake, in Debian only when running on xfce session. on ssh session, it works fine. Also I tried to install cmake from source, but it didn't work.

This is the error produced by cmake: cmake: error while loading shared libraries: /usr/lib/aarch64-linux-gnu/libc.so: invalid ELF header

This is my device information: Device: Samsung Galaxy Tab S7(SM-T870) Android version: 11 UserLAnd version: 2.7.3 root: no

[longqzh]

Same problem occurs from pip3, openssl ...

I found that the file (/usr/lib/aarch64-linux-gnu/libc.so) is a text file

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-littleaarch64)
GROUP ( /lib/aarch64-linux-gnu/libc.so.6 /usr/lib/aarch64-linux-gnu/libc_nonshared.a  AS_NEEDED ( /lib/aarch64-linux-gnu/ld-linux-aarch64.so.1 ) )

So I tried to make a soft link to /lib/aarch64-linux-gnu/libc-2.28.so to instead of /usr/lib/aarch64-linux-gnu/libc.so, but pip3 and openssl still couldn't work

• for pip3, the error is fish: 'pip3 install rich' terminated by signal SIGSEGV (Address boundary error)
• for openssl, the error is openssl: symbol lookup error: /data/user/0/tech.ula/files/support/libcrypto.so.1.1: undefined symbol: __sF

Then I compared the ELF header of libc.so and libcrypto.so.1.1, and found that their OS/ABI are different!

# readelf -h /lib/aarch64-linux-gnu/libc-2.28.so 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - GNU
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           AArch64
  Version:                           0x1
  Entry point address:               0x20e70
  Start of program headers:          64 (bytes into file)
  Start of section headers:          1434872 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         10
  Size of section headers:           64 (bytes)
  Number of section headers:         73
  Section header string table index: 72

#readelf -h /data/user/0/tech.ula/files/support/libcrypto.so.1.1
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           AArch64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          2104392 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         7
  Size of section headers:           64 (bytes)
  Number of section headers:         23
  Section header string table index: 22

One is UNIX - System V(00), and another is UNIX - GNU(03).

This is my device information: Device: Samsung Galaxy Tab S4 (SM-T835N) Android version: 10 UserLAnd version: 2.7.3 root: no

It seems like a compiling mistake, does anybody have idea about it?

[ddjm1973]

See this bug report: https://github.com/CypherpunkArmory/UserLAnd/issues/1410

e.g. try executing this: export LD_LIBRARY_PATH=""

... and then try running your program again. Chances are it might work now.