sui

Problem rebuilt the entire binary through , which reconstructs the file purely from its section table. That is lossy for modern relocatable executables: 0.36 has no support — errors () on any binary carrying a section header. Any segment bytes not covered by a surviving section are silently dropped on write. So when a binary's section headers are stripped (as 's release-linux base is), the relative relocations survive only in a referenced by — and the rebuild drops them. The v8 149.4.0 bump added the first load-bearing relative relocation (a C++ static-init guard's mutex pointer). Left un-relocated, it deadlocks/aborts at startup: Only reproduces on , where the strip is aggressive enough to leave outside the section table. Verified locally against object 0.36.3: flipping a fixture section to makes fail, and only round-trips section-backed bytes. Fix Replace the full rebuild with an in-place, style append that keeps every original byte: 1. Append the note payload + an enlarged copy of the program header table at a page-aligned offset past EOF. 2. Add a mapping that region and a pointing at the note, and repoint / + at the new table (so the loader's load-bias math, , stays correct). This is what the runtime / reads. 3. When the input still has a section header table, also add a real section — relocating + growing the section header table and past EOF — so the note survives a later (BFD tools rebuild from sections). A fully stripped binary keeps the note via alone. The original program/section header tables, , segment contents, and all relocations are copied (enlarged), never edited in place — so survives unchanged. Tests executes the produced binary on Linux CI — exercises the relocated . ✅ confirms the note is recoverable after GNU . ✅ / rewritten to verify the note via its program header. ✅ New : all bytes past the ELF header preserved, section table relocated + grew by one, program header table grew by two, SUI note discoverable. ✅ All four CI runners green. Note: no version bump included — left for a follow-up release when deno bumps the libsui pin.

AI Disclosure: Claude discovered this bug while I was working on BoundaryML/baml where we use this library. The PR description and diff is 100% AI generated. Summary can place the embedded section at a virtual address that overlaps the host binary's , corrupting the embedded data (and ) at startup. The result is a binary that fails to read back its embedded section — or crashes — even though the bytes on disk are correct. Root cause derives the note's virtual address from its file offset: That equivalence only holds when the carrier 's file image and memory image coincide. A trailing section () occupies memory but no file bytes, so the segment's . Deriving from the file offset then places the note below where ends in memory — the note and the program's zero-initialized globals get assigned the same virtual addresses. At startup the globals read the note's bytes as their initial values (garbage → frequent SIGSEGV) and overwrite the embedded data, so returns corruption. It only triggers once is large enough to cross the page boundary the note is placed at, so small binaries never show it — which is why it's gone unnoticed. We hit it embedding into a ~14 MB Rust host: , note placed at , squarely inside . Fix Push the note's file offset past the carrier segment's whole memory image (), not just its file bytes, so the derived virtual address always clears . One change to the placement math; everything else (PT_NOTE reuse, segment extension, note wire format) is unchanged, so reads it back exactly as before. Test Adds : it inflates the test fixture's to cross the boundary, appends a note, and asserts the note's mapped range doesn't overlap any allocated section. It fails on () and passes with this fix. Full suite (, incl. the binaries that execute the patched ELF) stays green. Context: hit while debugging broken output on Linux; downstream workaround is BoundaryML/baml#3760, but the bug is here in , so this fixes it at the source.

Summary Fixes a high-severity integer underflow vulnerability in . Problem The function reads a field from untrusted input and performs a subtraction without checking if the value is large enough: If a malformed Mach-O file has a field less than 8 (e.g., 0-7), this subtraction causes an integer underflow. On release builds, this wraps around to a very large value (e.g., on 64-bit systems). Impact This could lead to: Memory safety issues when slicing with the wrapped-around size Potential denial of service or undefined behavior when processing malformed Mach-O files Solution Validate that before performing the subtraction, returning for malformed files: Testing Added regression tests to verify the fix handles: (less than 8) (worst case for underflow)