Post-action context: subparser words silently alias other fields or revert OOB (generalizes Protofire M02 #2619)

[thedavidmeister]

Summary

The RaindexV6 subparser exposes all context words globally with no per-entrypoint gating. In the add/remove-order post-action context (which only populates base column 0 + calling-context column 1 rows 0–1), words that map to absent columns/rows are footguns. Protofire M02 (#2619) named the reverting case for order-counterparty(); this generalizes it and adds a more dangerous silent-value variant.

Observed (verified on current main)

• Silent wrong value. deposit-token() maps to calling-context column 1 row 0 — the same slot order-hash() uses. In an addOrder4 post-action that slot holds the order hash, so deposit-token() does not revert — it silently returns the order hash. Repro testProbeDepositTokenSilentlyReturnsOrderHash passes (it asserts deposit-token() == order-hash()). The same slot-aliasing affects withdraw-token() and other col1-row0/row1 words across entrypoints.
• Generalized reverts. calculated-max-output() (col 2), input-token() (col 3) — and every other word for a column/row absent in the post-action context — revert with panic: array out-of-bounds access (0x32), the same revert M02 flagged for order-counterparty(). Repros testProbeAddOrderCalculatedMaxOutput / testProbeAddOrderInputToken fail (revert) on main.

Why it matters / triage

The silent-value case is the concerning one: an author who uses deposit-token() in the wrong entrypoint gets a plausible-looking 32-byte value (an unrelated field) with no signal, and it would survive a fix that only addresses the reverting words. The generalized reverts mean a per-word point-fix for order-counterparty() leaves the rest of the class broken.

Whether slot-aliasing across entrypoints is "by design" (words documented for their own entrypoints) is a maintainer call — surfaced for triage, not adjudicated.

Relationship

Generalizes / extends Protofire M02 (#2619) (same root cause: a single global word surface with no per-entrypoint gating). The audit recommendation — "make context availability explicit per entrypoint rather than presenting one global word surface" — covers the whole class.

Provenance

Surfaced and verified by an adversarial review pass over current main. Repro tests live on a throwaway scratch branch (uncommitted); happy to push them if useful.

[linear]

RAI-843

[thedavidmeister]

Full solution-space analysis (incl. the subparser-word-marker approach that catches the silent-alias case this issue raises) written up on the parent finding: #2619 — see the 'Solution space + severity reassessment' comment. The key point for this issue: the silent alias is only catchable via the word identity (which the subparser uniquely knows), not via operand/bytecode scanning — so approach D there is the no-upstream path that addresses it.

[thedavidmeister]

Deferred post-prod along with the parent finding — see the Disposition: deferred (post-prod) comment on #2619 for the rationale (forward-only footgun for new authors, breaks no existing expression, low severity) and the recommended resume-path (RaindexV6 publishes its per-entrypoint context schema → dotrain LSP gates at author time, catching this issue's silent-alias case as an editor diagnostic, off-chain, no rainlang change). The silent-alias half is specifically what that direction is designed to catch.