SEA building in a Linux arm64 docker container can corrupt the .gnu.hash section of the binary

Noticed in #59582, I can only reproduce it locally using docker. The Node.js devcontainer image is enough to reproduce this when run on an arm64 host:

docker pull nodejs/devcontainer:nightly
docker run -it nodejs/devcontainer:nightly

In the container:

echo 'console.log("hello")' > hello.js
echo '{"main":"./hello.js", "output":"./sea-prep.blob"}' > sea-config.json
node --experimental-sea-config sea-config.json
cp `which node` ./hello
readelf -x .gnu.hash ./hello | head -n 100 # shows the section filled with the symbol lookup table
npx postject hello NODE_SEA_BLOB sea-prep.blob --sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2
readelf -x .gnu.hash ./hello | head -n 100 # shows a bunch of zeros

This does not reproduce on a bare-metal Linux arm64 server, or Linux x64 (bare-metal or in docker), which I think is why in the Node.js pull request it only fails in the GitHub action on Linux arm64.

The result of this is that the produced Node.js SEA cannot load any addons using process.dlopen(), because it cannot look up the napi_* symbols from itself (the same can be said about any other non-napi addons, which rely on the same mechanism to look up symbols from the binary to load the addons).

From: llvm-readelf-20 --gnu-hash-table ./hello

GnuHashTable {
  Num Buckets: 32771
  First Hashed Symbol Index: 618
  Num Mask Words: 512
  Shift Count: 18
  Bloom Filter: [0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...],  # all 0s
  Buckets: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ...],  # all 0s
  Values: [0x0, 0x7B85, 0x7B86, 0x0, 0x7B89, 0x7B8B, 0x7B8F, 0x0, 0x0, 0x0, ...]
}

For comparison, from llvm-readelf-20 --gnu-hash-table $(which node)

GnuHashTable {
  Num Buckets: 32771
  First Hashed Symbol Index: 618
  Num Mask Words: 4096
  Shift Count: 18
  Bloom Filter: [0xCC410900812B3801, 0xF0842E3C470A2984, 0x11A04200080012DC, 0x2094A00C40722F02, ...],
  Buckets: [618, 0, 0, 0, 0, 619, 621, 622, 625, 0, 626, 0, 628, ... ],
  Values: [0x2C0B883F, 0x639AD598, 0xD64A05A3, 0x70B4A433, 0x87D7AF02, ...]
}

It seems postject corrupted the binary with an incorrect size of the bloom filter

This is still reproducible even with --build-sea from #61167, though hopefully it's now easier to debug without the WASM hoops..

[Edited 2026-05-20 — original claim was wrong; replaced with corrected analysis below.]

Apologies — I muddied this thread. After more digging the SIGILL I reported isn't actually downstream of the .gnu.hash corruption you diagnosed. The 5 SIGILLs visible under strace -e signal=all are normal OpenSSL ARM crypto-extension probes (_armv8_sm3_probe, _armv8_sha256_probe, etc.), all caught by OpenSSL's installed SIGILL handler — that's expected on a CPU that doesn't support every extension.

The actual death on my repro is a NULL-deref memcpy after OpenSSL init completes:

#0  memcpy ()
#1  node::BlobDeserializer<...>::ReadArithmetic<unsigned int>()
#2  node::sea::FindSingleExecutableResource()
#3  node::sea::FixupArgsForSEA(int, char**)
#4  node::Start(int, char**)

Root cause turned out to be unrelated to your bug: the unofficial-builds linux-arm64-musl binary has all .note* sections stripped and has no PT_NOTE program header at all, so postject's note injection lands in an unreachable section and postject_find_resource() returns NULL. The official node:alpine arm64 has .note.gnu.build-id + a PT_NOTE segment, which is why postject works there.

Filing on unofficial-builds for that. Sorry for the noise on your thread — your .gnu.hash diagnosis is independently real and the per-section diff data still corroborates it for any napi-addon scenario.

fix: run postject SEA injection under x64 node for both arches

test: fix Linux debug skip in SEA test guard

This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

test: fix Linux debug skip in SEA test guard

Still reproduces with postject on Linux arm64 in Docker: reproduction run

Navigation Menu

Repository navigation

SEA building in a Linux arm64 docker container can corrupt the .gnu.hash section of the binary #61483

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

SEA building in a Linux arm64 docker container can corrupt the .gnu.hash section of the binary #61483

Description

Activity

joyeecheung commented on Nov 8, 2025

joyeecheung commented on Jan 23, 2026

awbx commented on May 20, 2026

github-actions commented on Sep 3, 2026

inoway46 commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions