meld --memory shared --address-rebase skips R_WASM_MEMORY_ADDR_SLEB relocations: a rebased module's i32.const data pointer stays stale -> silent cross-component aliasing (gap in #340)

[avrabe]

Summary

meld fuse --memory shared --address-rebase rebases a module's data segment and its memarg
load/store offsets (R_WASM_MEMORY_ADDR_LEB) but does not apply R_WASM_MEMORY_ADDR_SLEB
relocations — the ones that materialize a data address as an i32.const in code. So when a rebased
module takes a pointer to its own data (returns &buf[0], passes a buffer address to memcpy,
returns a string/struct pointer), the i32.const stays at the pre-rebase address, pointing into the
other fused component's memory region. Silent cross-component pointer aliasing; the fused module
validates cleanly.

Distinct from #326 (runtime-computed operands that carry no relocation) and #339 (absolute addresses
used as values with no reloc): here a relocation exists (MemoryAddrSleb) and is simply dropped
by the #340 reloc-driven rebasing. Verified on meld 0.41.1.

Reproduction (executed vs wasmtime)

Two C modules, each with a static array at wasm-ld's default base 0x10000, built with
-Wl,--emit-relocs, componentized, fused with --memory shared --address-rebase. In the fused core
module dataB is rebased to 0x30000 (196608), dataA stays at 0x10000:

export	fused result	expected
get-b(0) (i32.load offset=… — LEB, rebased)	0xB0B0B0B0	0xB0B0B0B0 ✓
ptr-b() (returns &dataB[0] — i32.const, SLEB)	65536 (0x10000, dataA's region)	196608 (0x30000)

So ptr-b returns a pointer 128 KB low — into dataA. A guest dereferencing it reads/writes the
other component's buffer.

Root cause (source)

meld-core/src/reloc.rs recognizes MemoryAddrSleb as a memory-address reloc
(RelocType::MemoryAddrSleb code 4; is_memory_addr includes it at ~:136-140), and the input
carries it — b_core.wasm's reloc.CODE = 3 entries MemoryAddrLeb@13, MemoryAddrLeb@33, MemoryAddrSleb@42. But the code-relocation rebase path applies the two MemoryAddrLeb sites and
leaves the MemoryAddrSleb site unrewritten (the i32.const value is unchanged in the fused
output). The data-segment pointer rebasing (rebase_data_segment_pointers, #326 Part C) and the
memarg-offset rebasing are handled; the code i32.const address-materialization (SLEB) is the gap.

Impact

• Any reloc-bearing component that materializes a pointer to its own static data — extremely common
  (return &buf, pass a buffer to a host import, string/struct pointers across the canonical ABI) —
  silently addresses the wrong component's memory after --address-rebase. This is the exact
  "isolation" property --memory shared --address-rebase (fix(326): reloc-driven shared-memory address rebasing (sound --memory shared) #340, "sound --memory shared") is meant to
  provide, so it's a soundness hole in that feature.
• Silent: wasm-tools validate → VALID; no warning. Deterministic across re-fuses.

Suggested fix

In the code-relocation rebase path, handle MemoryAddrSleb (and MemoryAddrRelSleb) the same as
MemoryAddrLeb — add the module's rebase delta to the i32.const value and re-encode the signed
LEB128 in place (SLEB is fixed-width-padded by wasm-ld, so length is preserved). Add a regression test
that fuses a module returning &data[0] and asserts the pointer equals the rebased base.

Reported by the pulseengine-challenge harness (research-agent lead; clean-room reverified — input SLEB
reloc present, meld output i32.const unchanged, wasmtime execution shows the stale pointer).

[avrabe]

Thanks for the detailed writeup and the wasmtime oracle — that's exactly the right way to file a soundness report. I tried to reproduce it and, on v0.41.1 (HEAD 3218503), I get the correct rebasing, so I need a bit more to pin down the discrepancy.

What I built (matching your repro shape)

Two C modules, static array at wasm-ld's default 0x10000, --emit-relocs, componentized, fused --memory shared --address-rebase — with get_b doing constant-index loads (→ R_WASM_MEMORY_ADDR_LEB on the memarg offset) and ptr_b returning &dataB[0] (→ R_WASM_MEMORY_ADDR_SLEB on the i32.const). That produces exactly your "2× MemoryAddrLeb + 1× MemoryAddrSleb" shape:

reloc.CODE = 05 03  03 0a 01 00   03 16 01 04   04 1f 01 00
             │  │   └MemAddrLeb@10 └MemAddrLeb@22(addend4) └MemAddrSleb@31
             │  count=3
             section=5(code)

Fused output (v0.41.1)

(func $get_b0  i32.const 0  i32.load offset=196608 ...)   ;; rebased ✓
(func $get_b1  i32.const 0  i32.load offset=196612 ...)   ;; rebased ✓ (+addend 4)
(func $ptr_b   i32.const 196608 ...)                       ;; SLEB const REBASED ✓
(data (i32.const 196608) "\b0\b0\b0\b0...")               ;; dataB rebased ✓
(data (i32.const 65536)  "\a0\a0\a0\a0...")               ;; dataA unchanged ✓

Runtime oracle (wasmtime 41.0.0)

$ wasmtime run --invoke ptr_b fused.wasm  →  196608   (0x30000, your "expected")
$ wasmtime run --invoke ptr_a fused.wasm  →  65536    (0x10000, dataA unchanged)

So the MemoryAddrSleb i32.const pointer is rebased — ptr_b returns 196608, matching your expected column, not the 65536 you observed.

Why "LEB rebases, SLEB doesn't" is surprising in this code

Since #326, both forms go through the same addr_reloc flag: RelocInfo::code_memory_addr_offsets() includes MemoryAddrSleb (reloc.rs is_memory_addr), the per-operator matcher flags whichever operator the site lands on (r ∈ [old_pos, op_end)), and the I32Const arm adds memory_base_offset (rewriter.rs). There's no separate SLEB path to drop. And SLEB width (even 5-byte zero-padded) only widens the operator's byte range, so it can't cause a missed match. That's consistent with the repro rebasing correctly.

To reconcile — could you share:

1. The exact un-fused b_core.wasm (or its wasm-tools print -v / objdump) — specifically the ptr_b i32.const bytes + the reloc.CODE entry for it.
2. The fused output's ptr_b i32.const (is the operand literally unchanged at 0x10000?).
3. Toolchain versions: clang/LLVM + wasm-ld, and crucially the link mode — was this a normal executable link (wasm-ld --no-entry ... --emit-relocs, addresses resolved) or the relocatable path (wasm-ld -r / --emit=obj, addresses symbol-relative at base 0)? Those are different consumption models and I'd like to test the exact one you hit.

My toolchain here: clang 22.1.8, LLD 22.1.4, meld 3218503 (v0.41.1), wasmtime 41.0.0. Happy to add your exact b_core.wasm as a regression fixture once I can see the byte-level difference — if it does reproduce with a specific toolchain/link mode, that's a real fixture worth locking in.

[avrabe]

Thanks for the detailed pushback — it made me go back and reproduce from scratch, and I have both things you asked for. Short version: it reproduces on a freshly-built v0.41.1, it's the resolved executable link (not -r), and my original root-cause note was wrong about the mechanism — I'm correcting it below.

1. It reproduces on v0.41.1 (freshly rebuilt from v0.41.1-1-g3218503)

meld fuse a.wasm b.wasm --memory shared --address-rebase -o f.wasm
# wasmtime: ptr-b() = 65536   (expected 196608)

Fused output, one row per B-side function (B rebased to 0x30000=196608):

func	site	reloc	fused immediate
get-b	i32.load offset=	MEMORY_ADDR_LEB	196608 ✓ rebased
set-b	i32.store offset=	MEMORY_ADDR_LEB	196608 ✓ rebased
ptr-b	i32.const	MEMORY_ADDR_SLEB	65536 ✗ stale

data (;0;) (B's) correctly rebased to i32.const 196608; only ptr-b's pointer stayed at 65536, now aliasing A's region.

2. Link mode — it's the resolved executable path, NOT -r

Your leading hypothesis was the -r relocatable path (i32.const holds addend at base 0). It isn't that: in my b_core, ptr-b is i32.const 65536 — the resolved data address — the data segment is placed at i32.const 65536, __stack_pointer=65536, and every reloc entry has addend 0. This is a normal executable link with addresses already resolved. Toolchain (from the core module's producers): Homebrew clang 22.1.4 + wit-component 0.245.1.

reloc.CODE decodes to: target=code(6), 3 entries, all symbol #4, addend 0 — LEB@13, LEB@33, SLEB@42.

3. Correcting my root cause: it is NOT "only LEB is handled"

You were right to doubt that framing. In current source:

• is_memory_addr() and code_memory_addr_offsets() both include SLEB — the SLEB site is collected.
• rewrite_operators' I32Const arm does rebase when addr_reloc is true (the fuse --memory auto/shared silently corrupts memory across components: load/store dynamic addresses are not rebased (no memory.grow; distinct from #172/#299) #326 block) — that path is present and correct.

Yet set-b (func 1) rebased and ptr-b (func 2) did not — so it's neither function-position nor a missing reloc type. The only thing left: addr_reloc is not being set true for the i32.const operand site, while it is for the two memarg sites. That flag comes from old_pos <= r < op_end in rewrite_operators. A memarg reloc points mid-instruction (into the offset field); an i32.const reloc points at the operand right after the opcode — a tighter window. My read is the reloc-offset↔operator-offset reference frames drift for the const-operand case. That's the locus to instrument, not the reloc-type filter.

One thing I can't disambiguate from a single module: const-specific vs. highest-offset-site. set-b (memarg, func 1) works and ptr-b (const, func 2) doesn't, but ptr-b is also the last site. If you drop an SLEB const-pointer into function 0 of a multi-function module and it rebases, it's position/frame; if it still stalls, it's const-specific. Your fixture generator can settle that in seconds.

4. The exact reproducing inputs (base64, 850 B each)

These are the exact bytes above — real clang, resolved link.

a.wasm

AGFzbQ0AAQABggQAYXNtAQAAAAEPA2ABfwF/YAJ/fwBgAAF/AwQDAAECBQMBAAIGCAF/AUGAgAQLBzQFBm1lbW9yeQIAD19fc3RhY2tfcG9pbnRlcgMABWdldC1hAAAFc2V0LWEAAQVwdHItYQACDAEBCioDDwAgAEEDcUECdCgCgIAECxEAIABBA3FBAnQgATYCgIAECwYAQYCABAsLGAEAQYCABAsQoKCgoKGhoaGioqKio6OjowBaB2xpbmtpbmcCCEQFAKQBAARnZXRBAKQBAQRzZXRBAKQBAgRwdHJBBQQAGV9faW5kaXJlY3RfZnVuY3Rpb25fdGFibGUBAgVkYXRhQQAAEAUJAQUuZGF0YQQAABkKcmVsb2MuQ09ERQYDAw0EAAMhBAAEKgQAAEUJcHJvZHVjZXJzAQxwcm9jZXNzZWQtYnkCDkhvbWVicmV3IGNsYW5nBjIyLjEuNA13aXQtY29tcG9uZW50BzAuMjQ1LjEAlAEPdGFyZ2V0X2ZlYXR1cmVzCCsPbXV0YWJsZS1nbG9iYWxzKxNub250cmFwcGluZy1mcHRvaW50KwtidWxrLW1lbW9yeSsIc2lnbi1leHQrD3JlZmVyZW5jZS10eXBlcysKbXVsdGl2YWx1ZSsPYnVsay1tZW1vcnktb3B0KxZjYWxsLWluZGlyZWN0LW92ZXJsb25nAgQBAAAABgwBAAIBAAZtZW1vcnkHCAFAAQFpegB5BgsBAAABAAVnZXQtYQgGAQAAAAAACwsBAAVnZXQtYQEAAAcLAUACAWl6AXZ5AQAGCwEAAAEABXNldC1hCAYBAAABAAELCwEABXNldC1hAQIABwUBQAAAeQYLAQAAAQAFcHRyLWEIBgEAAAIAAgsLAQAFcHRyLWEBBAAAeg5jb21wb25lbnQtbmFtZQEYAAADAAVnZXQtYQEFc2V0LWECBXB0ci1hAQsAAgEABm1lbW9yeQEJABEBAARtYWluAQkAEgEABG1haW4BLAEGAAVnZXQtYQEFZ2V0LWECBXNldC1hAwVzZXQtYQQFcHRyLWEFBXB0ci1hAC8JcHJvZHVjZXJzAQxwcm9jZXNzZWQtYnkBDXdpdC1jb21wb25lbnQHMC4yNDUuMQ==

b.wasm

AGFzbQ0AAQABggQAYXNtAQAAAAEPA2ABfwF/YAJ/fwBgAAF/AwQDAAECBQMBAAIGCAF/AUGAgAQLBzQFBm1lbW9yeQIAD19fc3RhY2tfcG9pbnRlcgMABWdldC1iAAAFc2V0LWIAAQVwdHItYgACDAEBCioDDwAgAEEDcUECdCgCgIAECxEAIABBA3FBAnQgATYCgIAECwYAQYCABAsLGAEAQYCABAsQsLCwsLGxsbGysrKys7OzswBaB2xpbmtpbmcCCEQFAKQBAARnZXRCAKQBAQRzZXRCAKQBAgRwdHJCBQQAGV9faW5kaXJlY3RfZnVuY3Rpb25fdGFibGUBAgVkYXRhQgAAEAUJAQUuZGF0YQQAABkKcmVsb2MuQ09ERQYDAw0EAAMhBAAEKgQAAEUJcHJvZHVjZXJzAQxwcm9jZXNzZWQtYnkCDkhvbWVicmV3IGNsYW5nBjIyLjEuNA13aXQtY29tcG9uZW50BzAuMjQ1LjEAlAEPdGFyZ2V0X2ZlYXR1cmVzCCsPbXV0YWJsZS1nbG9iYWxzKxNub250cmFwcGluZy1mcHRvaW50KwtidWxrLW1lbW9yeSsIc2lnbi1leHQrD3JlZmVyZW5jZS10eXBlcysKbXVsdGl2YWx1ZSsPYnVsay1tZW1vcnktb3B0KxZjYWxsLWluZGlyZWN0LW92ZXJsb25nAgQBAAAABgwBAAIBAAZtZW1vcnkHCAFAAQFpegB5BgsBAAABAAVnZXQtYggGAQAAAAAACwsBAAVnZXQtYgEAAAcLAUACAWl6AXZ5AQAGCwEAAAEABXNldC1iCAYBAAABAAELCwEABXNldC1iAQIABwUBQAAAeQYLAQAAAQAFcHRyLWIIBgEAAAIAAgsLAQAFcHRyLWIBBAAAeg5jb21wb25lbnQtbmFtZQEYAAADAAVnZXQtYgEFc2V0LWICBXB0ci1iAQsAAgEABm1lbW9yeQEJABEBAARtYWluAQkAEgEABG1haW4BLAEGAAVnZXQtYgEFZ2V0LWICBXNldC1iAwVzZXQtYgQFcHRyLWIFBXB0ci1iAC8JcHJvZHVjZXJzAQxwcm9jZXNzZWQtYnkBDXdpdC1jb21wb25lbnQHMC4yNDUuMQ==

base64 -d → meld fuse a.wasm b.wasm --memory shared --address-rebase -o f.wasm → wasmtime --invoke ptr-b f.wasm 0 returns 65536. SHA-256 b.wasm: 481c36137ebe6b75b1699b757065cca4fb9cd8ae2b4f18ee00732f625b19d3a3.

[avrabe]

Reproduced on your exact bytes (b.wasm sha256 481c…d3a3 matches) — wasmtime --invoke ptr-b f.wasm returns 65536. You were right; my synthetic fixtures just never hit the failing codegen. And your instinct about addr_reloc not being set for the const is correct — here's the precise mechanism, which is not const-specific.

Byte-level root cause: stale reloc.CODE offsets from LEB relaxation

Your reloc.CODE sites vs. the actual operand positions in the emitted (minimal-LEB) code section (content frame, func-count byte = 0):

func	rebasable immediate	actual offset	reloc offset	drift
0 get-b	i32.load offset= LEB	13	13	0
1 set-b	i32.store offset= LEB	31	33	+2
2 ptr-b	i32.const operand	38	42	+4

The reloc offsets drift +2 per preceding function — the signature of LEB relaxation: the producer (wit-component 0.245.1 / the linker) re-encoded each address immediate from 5-byte-padded to 3-byte-minimal (−2 bytes each) but did not rewrite the reloc.CODE offsets to match. So every reloc points into the pre-relaxation layout.

meld's rewrite_operators tests old_pos ≤ r < op_end against the actual (relaxed) operator positions:

• get-b memarg: reloc 13 ∈ load range [11,16) ✓ rebased.
• set-b memarg: reloc 33 ∈ store range [29,34) ✓ rebased — survives only because the +2 drift stays inside the store's multi-byte immediate.
• ptr-b const: operand at 38, operator range [37,41); stale reloc 42 ≥ 41 → falls past op_end → addr_reloc=false → silently not rebased. i32.const 65536 stays stale → aliases A.

So it isn't const-vs-memarg and isn't reloc-type filtering: it's that the memargs' wider immediates tolerate the accumulated drift and the const's tighter window doesn't. A memarg would fail identically with enough preceding relaxations.

Two defects, two fixes

1. Upstream (wasm-tools/wit-component): emitting reloc.CODE with offsets that don't match the relaxed code is a producer bug — the relocs are unusable by any consumer. I'll file this against wasm-tools with your fixture.
2. meld (soundness): meld must never silently skip a memory-address reloc — that's the "never silently corrupt" invariant fuse --memory auto/shared silently corrupts memory across components: load/store dynamic addresses are not rebased (no memory.grow; distinct from #172/#299) #326 is built on. I'm implementing a fix so meld rebases correctly despite the drift (matching each reloc to its intended immediate robustly, value-confirmed, not by byte-exact offset), with a hard-fail backstop if a site can't be confidently resolved. Tracking here; will link the PR.

Thanks for the clean reproduction and the base64 — that's now a locked-in regression fixture.

[avrabe]

Upstream (producer) defect filed: pulseengine/wasm-tools#3 (stale reloc.CODE offsets after LEB relaxation — the +2/reloc drift). meld-side fix proceeding in parallel (layered: hard-fail backstop so this can never silently corrupt, then robust drift-tolerant rebasing so wit-component output fuses correctly).

[avrabe]

Backstop landed on main (#352, squash 48410f1): meld now hard-fails with MisalignedReloc on stale/drifted reloc.CODE offsets instead of silently miscompiling. Drift-tolerant correct rebasing (so such inputs fuse) remains tracked; the PIC/shared-everything direction (#353) may supersede it.

[avrabe]

Confirmed the hard-fail fix (48410f1 / #352) on the exact fixture from this issue, freshly built release meld @ v0.41.1-2-g48410f1:

meld fuse harness/meld_sleb/a.wasm b.wasm --memory shared --address-rebase -o f.wasm
  → exit 1, no module produced
  → Error: component 'b.wasm' module 0: relocation site at code offset 42 (reloc.CODE) does not land
    on a rebasable address immediate — the relocation metadata is stale relative to the emitted code
    (a producer relaxed LEB immediates without updating reloc offsets; see pulseengine/wasm-tools#3 and
    meld#351). Cannot rebase safely under `--memory shared --address-rebase`

The silent cross-component pointer aliasing is gone — the previously-stale ptr-b no longer yields a fused module at all. Fail-safe is the right call given the stale-offset producer issue (wasm-tools#3). My regression probe now guards the hard-fail (a fuse that succeeds and aliases would re-fail it). Thanks for the precise diagnosis on the producer-side LEB relaxation — that explains why offset 42 never matched the immediate.

[avrabe]

Thanks for confirming the hard-fail on a fresh build — that closes the loop on the backstop (tier-1). Leaving this open to track the tier-2 (drift-tolerant correct rebasing) vs the #353 PIC direction that may supersede it.