PT_DYNAMIC can end up in r/o PT_LOAD segment

[mwhudson]

Reproducer:

$ cat trivialcgo.go
package main

import "C"

func main() {

}
$ go build -ldflags=-linkmode=internal /opt/opensource/go-test-cases/trivialcgo.go 
$ objcopy --remove-section .note.go.buildid   trivialcgo 
$ patchelf --set-rpath doesntmatter ./trivialcgo$ ./trivialcgo 
Segmentation fault (core dumped)

The reason for the crash is seen in readelf -l:

$ readelf -l ./trivialcgo
...
Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
...
  LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x04e270 0x04e270 R E 0x1000
  DYNAMIC        0x000270 0x0000000000400270 0x0000000000400270 0x000140 0x000140 RW  0x8
...

The PT_DYNAMIC header points into a PT_LOAD section that does not have the W flag, which causes glibc to segv very early in program startup.

[mwhudson]

The difference between this executable and ones that don't break is that shiftFile is not called when processing this executable. shiftFile creates a writable PT_LOAD/segment for the moved sections to go into and PT_DYNAMIC pointing into that works fine but when shiftFile is not called, the PT_DYNAMIC header is just updated to point to near the beginning of the file without regard to which segment that gets mapped into (I guess you could contrive a situation where it was unmapped rather than mapped read only but ...).

I don't know what the fix would be. I guess a new PT_LOAD always needs to be created and in the non-shiftFiles case, any PT_LOAD covering that part of the file adjusted to no longer cover it?

[ezquat]

Probably duplicate: #152.

[cmatsuoka]

This is also preventing go binaries to be used in classic Snap packages, which rely on rpath changes to work properly.

[domenkozar]

Can't reproduce on master:

$ ../result/bin/patchelf --print-rpath ./trivialcgo
doesntmatter

[ezquat]

I tried this with a fresh version of influxd and the same old version of patchelf, and didn't get the problem, so I suspect whatever changed was actually not a fix in patchelf. Possibly influxd (or go) doesn't happen to produce those slightly-strange executables anymore.

[grahamc]

I see there is a reproducer from @limeytexan at https://github.com/limeytexan/NixOS-patchelf-issue-146. I've uploaded a .tar.gz of the source and the patchelf'd and unpatchelf'd build results for posterity.

Log:

[nix-shell:~/projects/github.com/limeytexan/NixOS-patchelf-issue-146]$ nix-build
warning: unknown setting 'experimental-features'
these derivations will be built:
  /nix/store/rbkzib5wmpgvgzxanq12jy8azqcd23xa-issue_146.drv
warning: unknown setting 'experimental-features'
building '/nix/store/rbkzib5wmpgvgzxanq12jy8azqcd23xa-issue_146.drv' on 'ssh://[email protected]'...
copying 1 paths...
copying path '/nix/store/cy3fn6i41sa5q5h3ihkh051ayqj3fzmi-NixOS-patchelf-issue-146' to 'ssh://[email protected]'...
unpacking sources
unpacking source archive /nix/store/cy3fn6i41sa5q5h3ihkh051ayqj3fzmi-NixOS-patchelf-issue-146
source root is NixOS-patchelf-issue-146
patching sources
configuring
building
Building subPackage .
runtime/cgo
net
golang.org/x/sys/unix
github.com/sirupsen/logrus
crypto/x509
crypto/tls
net/textproto
vendor/golang.org/x/net/http/httpguts
vendor/golang.org/x/net/http/httpproxy
net/http/httptrace
net/http
issue_146
running tests
installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/w2dzcx2ncrq6hglmgbf9ri1bgnbrf46m-issue_146
shrinking /nix/store/w2dzcx2ncrq6hglmgbf9ri1bgnbrf46m-issue_146/bin/issue_146
strip is /nix/store/iygzjy14i075hkxr2gq8cpfjvk2rkx0b-binutils-2.31.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/w2dzcx2ncrq6hglmgbf9ri1bgnbrf46m-issue_146/bin
patching script interpreter paths in /nix/store/w2dzcx2ncrq6hglmgbf9ri1bgnbrf46m-issue_146
checking for references to /build/ in /nix/store/w2dzcx2ncrq6hglmgbf9ri1bgnbrf46m-issue_146...
automatically fixing dependencies for ELF files
searching for dependencies of /nix/store/w2dzcx2ncrq6hglmgbf9ri1bgnbrf46m-issue_146/bin/issue_146.patchelf
  libgssapi_krb5.so.2 -> found: /nix/store/hgn0pdimpnpcrnk1s9gfa88xsrfav6am-libkrb5-1.18/lib/libgssapi_krb5.so.2
setting RPATH to: /nix/store/hgn0pdimpnpcrnk1s9gfa88xsrfav6am-libkrb5-1.18/lib
copying 1 paths...
copying path '/nix/store/w2dzcx2ncrq6hglmgbf9ri1bgnbrf46m-issue_146' from 'ssh://[email protected]'...
/nix/store/w2dzcx2ncrq6hglmgbf9ri1bgnbrf46m-issue_146

[nix-shell:~/projects/github.com/limeytexan/NixOS-patchelf-issue-146]$ ./result/bin/issue_146.patchelf 
Segmentation fault (core dumped)

[nix-shell:~/projects/github.com/limeytexan/NixOS-patchelf-issue-146]$ ./result/bin/issue_146.wrapped

• output: patchelf-issue-146-output.tar.gz
• source:
  NixOS-patchelf-issue-146-master.tar.gz

Both are at 6a888058bc833af8260b90223371d6b2e47ca4a6, and my host is at:

[grahamc@Petunia:~/projects/github.com/limeytexan/NixOS-patchelf-issue-146]$ nix-info -m
 - system: `"x86_64-linux"`
 - host os: `Linux 5.8.6, NixOS, 20.09alpha235.e0508c81809 (Nightingale)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.7`
 - channels(root): `"nixos-20.09alpha235.e0508c81809"`
 - channels(grahamc): `"latest"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

$ for i in result/bin/*; do echo -n $i "... " && $i && echo WORKS; done
result/bin/issue_146 ... result/bin/issue_146: error while loading shared libraries: libgssapi_krb5.so.2: cannot open shared object file: No such file or directory
result/bin/issue_146.patchelf ... Segmentation fault (core dumped)
result/bin/issue_146.wrapped ... WORKS

[petrmanek]

Hi, has there been any evolution on this issue?

I have just encountered an eerily similar bug, where patchelf 0.18.0 (built from source) appears to corrupt libxcb-image.so.0 under the latest Ubuntu Focal after a single call to --set-rpath. Following the change, ldd complains that the shared object file is not a dynamic executable