Calling `postject_find_resource()` segfaults on `rhel8-ppc64le`

[RaisinTen]

The crash originates from here:

postject/postject-api.h

Line 141 in 3534343

if (note->n_namesz != 0 && note->n_descsz != 0 &&

while dereferencing the note pointer. Note that note is not a null pointer here.

This is happening for the case where the resource hasn't been injected into the node binary.

This is one of the blockers for the single-executable PR in core - nodejs/node#45038. I think calling postject_has_resource() first would also unblock that PR.

Refs: nodejs/build#3168

[RaisinTen]

The implementation should be something like https://github.com/iovisor/bpftrace/blob/1326f040a0f88287ccbc8c18fe8956bca4cc225d/src/utils.cpp#L1017-L1050. I'll see if I can find any obvious differences. Meanwhile maybe @dsanders11 and @robertgzr could help?

[RaisinTen]

Also, cc @nodejs/single-executable if anyone else also has any clue

[dsanders11]

The implementation should be something like https://github.com/iovisor/bpftrace/blob/1326f040a0f88287ccbc8c18fe8956bca4cc225d/src/utils.cpp#L1017-L1050. I'll see if I can find any obvious differences. Meanwhile maybe @dsanders11 and @robertgzr could help?

That implementation is a bit different - it's looking for SHT_NOTE using the section header table (SHT), while Postject's implementation uses PT_NOTE, which is a note segment. Sections are contained within segments, but they're a linker-time concept. The SHT is not used at run time and can be stripped from the executable. The the Wiki article on ELF:

The segments contain information that is needed for run time execution of the file, while sections contain important data for linking and relocation.

While SHT_NOTE sections will exist inside of a PT_NOTE segment, you can't rely on the SHT to find them at run time since that information may be stripped, so Postject walks the segments, rather than sections.

---

I don't see anything obvious, so I'll try to dig into this later and see what I can find. There might be some slight difference on ppc64le that's not being accounted for in the current implementation which leads to using the wrong offset for the pointers values.

[RaisinTen]

Hmm, weird find - I'm able to reproduce this on Linux when I compile this on an x64 Ubuntu Linux:

test.cc

#include <iostream>
#include <string>

#include "postject-api.h"

int main() {
  size_t size = 0;

  if (postject_has_resource()) {
    const void* ptr = postject_find_resource("foobar", &size, nullptr);
    if (ptr == NULL) {
      std::cerr << "ptr must not be NULL." << std::endl;
      exit(1);
    }
    if (size == 0) {
      std::cerr << "size must not be 0." << std::endl;
      exit(1);
    }
    std::cout << std::string(static_cast<const char*>(ptr), size) << std::endl;
  } else {
    const void* ptr = postject_find_resource("foobar", &size, nullptr); // <- this call segfaults
    if (ptr != nullptr) {
      std::cerr << "ptr must be nullptr." << std::endl;
      exit(1);
    }
    if (size > 0) {
      std::cerr << "size must not be greater than 0." << std::endl;
      exit(1);
    }
    std::cout << "Hello world" << std::endl;
  }

  return 0;
}

(postject-api.h - from https://github.com/nodejs/postject/blob/35343439cac8c488f2596d7c4c1dddfec1fddcae/postject-api.h)

using clang but it works fine with gcc. 🤔

$ g++ test.cc 
$ ./a.out 
Hello world
$ clang++ test.cc 
$ ./a.out 
Segmentation fault (core dumped)
$ clang++ -g test.cc 
$ gdb -q a.out
Reading symbols from a.out...
(gdb) run
Starting program: /home/parallels/Desktop/temp/project/trash/a.out 

Program received signal SIGSEGV, Segmentation fault.
0x00000000004015f0 in postject_find_resource (name=0x402004 "foobar", size=0x7fffffffdf00, options=0x0) at ./postject-api.h:141
141	      if (note->n_namesz != 0 && note->n_descsz != 0 &&
(gdb) bt
#0  0x00000000004015f0 in postject_find_resource (name=0x402004 "foobar", size=0x7fffffffdf00, options=0x0) at ./postject-api.h:141
#1  0x0000000000401401 in main () at test.cc:21
(gdb) quit
A debugging session is active.

	Inferior 1 [process 187727] will be killed.

Quit anyway? (y or n) y

System info:

$ uname -a
Linux parallels-Parallels-Virtual-Platform 5.13.0-40-generic #45~20.04.1-Ubuntu SMP Mon Apr 4 09:38:31 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

$ g++ --version
g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ clang++ --version
clang version 10.0.0-4ubuntu1 
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

[RaisinTen]

FWIW, I tried using dl_iterate_phdr to implement the runtime API for Linux using https://github.com/percona/percona-server/blob/5486efdbebd4e9a6fd94af5410853137a73d551b/mysys/build_id.cc as the base and it doesn't segfault when I compile with clang++.

@dsanders11 I'll send a PR for this soon if you're not aware of anything obviously wrong with function which I haven't considered.

[RaisinTen]

Fix - #77