#326 Finding A: path-F gate misses absolute addresses used as values (no-reloc, no direct load/store)

[avrabe]

Follow-up from the Mythos discover pass on the #326 reloc-consumer (PR pending).

The gap

The path-F hard-error gate (module_has_direct_memory_access in merger.rs) rejects a no-reloc, non-zero-base module only when it performs a direct load/store. It does NOT catch a module that references an absolute address purely as a value — i32.const <abs>; call $import (a canonical-ABI &BUF handed to an imported memcpy/fd_write) or i32.const <abs>; return. With no reloc metadata, the legacy path emits the const verbatim (un-rebased), so such a module hands an un-rebased pointer to the host / another component → silent cross-component corruption. This is exactly datapoint A's pattern (a buffer pointer passed to an import).

Why the naive fix is wrong (empirically confirmed)

Broadening the gate to reject any i32.const/i64.const regresses the legitimate bulk-only case: test_address_rebasing_end_to_end uses i32.const values that are safely consumed by rebased bulk-memory ops (memory.copy/fill/init, dynamically rebased by append_rebased_address). The naive broadening rejected it (test FAILED). So a bare const is indistinguishable from an integer, and bulk-op-consumed consts are safe — a sound fix needs data-flow analysis to tell an escaping address-const from a rebased-bulk-consumed or plain-integer const.

Scope / severity

• Medium. Silent memory corruption, but only on the no-reloc path (already the unsupported path — meld hard-errors the load/store subset and the error advises --emit-relocs).
• Does NOT affect the supported path: --emit-relocs inputs (e.g. gale's) carry reloc metadata, so their address consts are correctly rebased via reloc.CODE.
• The residual gap is documented in module_has_direct_memory_access's doc comment (KNOWN LIMITATION).

Proposed fix

Data-flow-aware gate: reject a no-reloc non-zero-base module iff it has an i32.const/i64.const that reaches a call/call_indirect/return/store WITHOUT being consumed by a dynamically-rebased bulk-memory op. (Or: require reloc metadata for ANY no-reloc non-zero-base module with a non-trivial code section, accepting the loss of the bulk-only-without-relocs convenience — a scope decision.)

Refs #326, ADR-6 (path-F), SR-48.

[avrabe]

Disposition after a fix attempt + Mythos review: document-only (undecidable without reloc metadata)

I prototyped the proposed broadening — gate fires when a no-reloc, non-zero-base module has an address-capable const AND an escape channel (call / value-return / global.set, bulk-op operands excluded). An adversarial Mythos pass then showed the approach is a net negative:

1. Still unsound (false negative). The scan is code-section + literal-i32.const only. An absolute address that lives in a global init expr (or data segment) and escapes via global.get; return/call — with no literal const in code — is NOT detected. So it doesn't even close the hole it targets.
2. Severe over-rejection / false positives. The composed.wasm fixture behind cross_component_call.rs::test_304 does zero memory access — its consts are plain scalars (20, 22, 7). The gate rejects it solely for having any int const + a call + a value-returning function. So it hard-errors ordinary, memory-untouching wit-bindgen compositions under --memory shared --address-rebase. The surviving "admissible no-reloc" class is essentially only void/call-free bulk-only modules — i.e. the gate becomes "reject every non-trivial no-reloc module."
3. Directly un-does fuse: drop vestigial cabi_realloc / canonical-ABI adapter once the inter-component boundary is internalized (unblocks --memory shared) #298. The gate runs upstream of fuse: drop vestigial cabi_realloc / canonical-ABI adapter once the inter-component boundary is internalized (unblocks --memory shared) #298's cabi_realloc-drop / grow-defer, so a scalar-boundary component fuse: drop vestigial cabi_realloc / canonical-ABI adapter once the inter-component boundary is internalized (unblocks --memory shared) #298 was built to carry through shared+rebase is rejected by #326 Finding A: path-F gate misses absolute addresses used as values (no-reloc, no direct load/store) #339 first.

Root cause — this is the #326 undecidability. Without relocation metadata you cannot distinguish an address-const from an integer-const (a small pointer to low memory is byte-identical to the scalar 8; an address can hide in a global init). Any gate is therefore either over-broad (rejects benign scalar components + breaks #298) or under-broad (misses small / global-init addresses). There is no sound-and-precise gate here; a heuristic would give false confidence while still leaking.

Decision: keep this as a documented residual, not a code change. The path is already gated to the unsupported no-reloc case; the sound path is --emit-relocs (reloc metadata bypasses this gate entirely and gets exact rebasing via reloc.CODE), which gale and any MCU consumer already use. The existing module_has_direct_memory_access gate stays (catches the direct load/store escape); the value-as-address residual for no-reloc inputs is inherent. Recommend closing as wontfix / by-design, or re-scoping to "require reloc metadata for any non-trivial --memory shared --address-rebase input" (fail-loud, no heuristic) if a stricter contract is wanted.

[avrabe]

Another no-reloc absolute-value manifestation of this gap, in a place worth calling out separately: a wasm global initialized to a data address is not rebased under --memory shared --address-rebase, so it silently aliases the other component.

Repro (two reloc-bearing components; B has (global $g (mut i32) (i32.const 1024)), data 0xBBBBBBBB @ 1024, bptr()=global.get $g, bviaglobal()=global.get $g; i32.load; empty reloc.CODE, no reloc on the global init):

meld fuse --memory shared --address-rebase a.wasm b.wasm -o f.wasm   # exit 0, validates

Fused output moves B's data to i32.const 132096 but leaves the global at i32.const 1024. Executed (wasmtime, base_B=131072):

• bptr() → 1024 (sound: 132096) — the pointer value is stale at its source.
• bviaglobal() → 0xAAAAAAAA (A's data; sound: 0xBBBBBBBB) — cross-component read.

Same limitation as this issue (a no-reloc absolute address used as a value, here in a global-init expr rather than in code). The specific unrebased path is meld-core/src/merger.rs convert_init_expr(), which remaps global indices but never adds memory_base_offset — contrast segments.rs reindex_data_segment(), which does rebase active-data offsets. Given the #351/#352 direction (hard-fail when a site can't be safely rebased), the same treatment likely applies here: a no-reloc absolute value in a global init under shared+rebase should either be covered by a reloc or hard-fail, not silently pass. (__stack_pointer globals are safe — coalesce_stack_pointers merges them — but any other data-pointer global escapes.)

[avrabe]

Confirmed the code path: merger.rs::convert_init_expr (~3334) folds the extended-const and remaps global indices, but never adds memory_base_offset — so a global initialized to an absolute data address stays stale under --memory shared --address-rebase while the data segment moves (contrast segments.rs::reindex_data_segment, which does rebase active-data offsets). Grounded.

This is the same undecidability as the rest of #339 (a bare i32.const 1024 in a global init is indistinguishable from an integer without reloc coverage), but it fits the #351/#352 backstop philosophy cleanly: under shared+rebase, a data-address-valued global init should be rebased when reloc-covered, else hard-fail (loud, like MisalignedReloc) rather than silently alias. __stack_pointer globals stay safe (coalesce_stack_pointers). Good candidate for the next backstop increment alongside the #352 tier-2 / #353 direction — tracked.