execstack --set-execstack<path> Aborted (core dump)

Bug #1850861 reported by Jamie Strandboge
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
prelink (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Reproducer:

$ cp /bin/ls /tmp
$ execstack --set-execstack /tmp/ls
execstack: dso.c:877: reopen_dso: Assertion `dso->shdr[j].sh_size == 0' failed.
Aborted (core dumped)
[134]

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: execstack 0.0.20131005-1
ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
Uname: Linux 5.3.0-19-generic x86_64
ApportVersion: 2.20.11-0ubuntu8
Architecture: amd64
CurrentDesktop: GNOME
Date: Thu Oct 31 16:35:17 2019
InstallationDate: Installed on 2016-10-01 (1125 days ago)
InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
 TERM=xterm-256color
 XDG_RUNTIME_DIR=<set>
 PATH=(custom, user)
SourcePackage: prelink
UpgradeStatus: Upgraded to eoan on 2019-10-27 (4 days ago)

Revision history for this message
Jamie Strandboge (jdstrand) wrote :
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

$ hardening-check /tmp/ls
/tmp/ls:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
 Stack clash protection: yes
 Control flow integrity: yes

On older releases, we can use --set-execstack on /bin/ls. hardening-check is different:

$ hardening-check /tmp/ls-bionic
/tmp/ls-bionic:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
 Stack clash protection: unknown, no -fstack-clash-protection instructions found
 Control flow integrity: unknown, no -fcf-protection instructions found!

Revision history for this message
Sander Jonkers (jonkers) wrote :

On Ubuntu 20.04, I have the same problem:

$ execstack -s hello
execstack: dso.c:877: reopen_dso: Assertion `dso->shdr[j].sh_size == 0' failed.
Aborted (core dumped)

sander@witte2004:~/hello-world$ gcc -o hello hello.c

sander@witte2004:~/hello-world$ ./hello
Hello, world!

sander@witte2004:~/hello-world$ ldd hello
 linux-vdso.so.1 (0x00007fffe01f4000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f66793b0000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f66795bf000)

sander@witte2004:~/hello-world$ execstack -s hello
execstack: dso.c:877: reopen_dso: Assertion `dso->shdr[j].sh_size == 0' failed.
Aborted (core dumped)

Revision history for this message
Sander Jonkers (jonkers) wrote :

And same same with /usr/bin/ls :

sander@witte2004:~/hello-world$ cp /usr/bin/ls /tmp/

sander@witte2004:~/hello-world$ ll /tmp/ls
-rwxr-xr-x 1 sander sander 142144 jun 8 20:43 /tmp/ls*

sander@witte2004:~/hello-world$ execstack -s /tmp/ls
execstack: dso.c:877: reopen_dso: Assertion `dso->shdr[j].sh_size == 0' failed.
Aborted (core dumped)

sander@witte2004:~/hello-world$ execstack -q /tmp/ls
- /tmp/ls

Revision history for this message
Sander Jonkers (jonkers) wrote :

FWIW: On Ubuntu 18.04 no problem:

sander@brixit:~$ execstack -s /tmp/ls
sander@brixit:~$

sander@brixit:~$ execstack -q /tmp/ls
X /tmp/ls

So it seems Ubuntu 20.04 specific?

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in prelink (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.