Elf Segment Assumptions cause segfaults

[tomrittervg]

I'm not sure exactly where; but somewhere in rust there seems to be an assumption about the ELF format and when I break it (which I'm trying to do to make elfhack work on lld: https://bugzilla.mozilla.org/show_bug.cgi?id=1423822 ) I get segfaults.

I'm compiling with clang, using lld as the linker. Here's a simple reproducer that occurs because I offset the second segment 0xF0 bytes from the first PHDR segment.

root@bca724986ba7:~/myworkspace/build/rust # cat main.rs
fn main() {}

root@bca724986ba7:~/myworkspace/build/rust # cat padding.ld
SECTIONS
{
  . = SEGMENT_START("text-segment", 0) + SIZEOF_HEADERS + 0xF0;
}

root@bca724986ba7:~/myworkspace/build/rust # cat ./cargo-linker
#!/bin/sh

eval ${MOZ_CARGO_WRAP_LD} ${MOZ_CARGO_WRAP_LDFLAGS} '"$@"'

# Minimal reproducer

root@bca724986ba7:~/myworkspace/build/rust # MOZ_CARGO_WRAP_LD=clang MOZ_CARGO_WRAP_LDFLAGS="-lpthread -fuse-ld=lld -flto=thin -Wl,-T,./padding.ld -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,--build-id" /builds/worker/myworkspace/build/src/rustc/bin/rustc -C linker=./cargo-linker main.rs

root@bca724986ba7:~/myworkspace/build/rust # ./main
Segmentation fault (core dumped)
139

# Remove the padding script:

root@bca724986ba7:~/myworkspace/build/rust # MOZ_CARGO_WRAP_LD=clang MOZ_CARGO_WRAP_LDFLAGS="-lpthread -fuse-ld=lld -flto=thin  -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,--build-id" /builds/worker/myworkspace/build/src/rustc/bin/rustc -C linker=./cargo-linker main.rs

root@bca724986ba7:~/myworkspace/build/rust # ./main
(no error)

I have a second reproducer that's considerably more difficult to reproduce, it involves patching clang to not output the PHDR segment.

[glandium]

This is not a rust bug at all. What I get with your testcase is a binary with:

  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x06c510 0x06c510 R E 0x1000
  LOAD           0x06c510 0x000000000006c510 0x000000000006c510 0x003dc8 0x005004 RW  0x1000

but once loaded the process has:

555555554000-5555555c0000 r-xp 00000000 fd:01 1081097                    /tmp/main
5555555c0000-5555555c4000 r--p 0006c000 fd:01 1081097                    /tmp/main
5555555c4000-5555555c5000 rw-p 00070000 fd:01 1081097                    /tmp/main

And the crash happens at 0x5555555c05c0, which is the address of the jemalloc lock per the symbol table, which is in the second LOAD, but what's actually loaded makes it an error.

So this is actually a ld.so bug because it's not really mapping as it's supposed to, but there's also a lld bug because there's an overlap between the 2 LOADs that would need to be writable and executable at the same time.

[Mark-Simulacrum]

Closing as not a bug per the previous comment. Please let us know if you disagree.