[dshakes]

Closes the vuln gate, which is currently red on master.

Why one PR and not two

wasmtime 45.0.3 is affected by RUSTSEC-2026-0222 (Stores can mix up type indices between engines). Every patched line the advisory allows — 46.0.2+ and 47.0.3+ — pulls cranelift crates that require Rust 1.94. So the dependency fix does not compile without the toolchain move; neither half stands alone.

Changes

• Toolchain 1.93 → 1.94.1 everywhere it is pinned: rust-toolchain.toml, two CI workflow pins (sdlc-lint, runtime-exec-e2e), and four service Dockerfiles. Confirmed rust:1.94-slim exists before relying on it — a missing tag would have broken every container build while local builds stayed green.
• wasmtime 45.0.2 → 46.0.2 (+ wasmtime-wasi, release-synced). Chose the 46 line over 47: smaller step that clears the advisory, and it needed no source changes.
• One new lint. 1.94 tightens clippy::result_large_err, which fires on the exec server's interceptor closure over tonic's 176-byte Status. Both halves of that signature are tonic's — Interceptor requires exactly FnMut(Request<()>) -> Result<Request<()>, Status> — so the error cannot be boxed without failing to implement the trait. Allowed with that reason, matching the identical allow already on validate_first_frame in the same file.

Verification (Rust 1.94.1, all five Rust services)

check	result
clippy --all-targets -D warnings	clean
rustfmt --check	clean
cargo audit	clean — 0221 and 0222 both gone
tests	gateway 31 · model-router 38 · surface-gateway 63 · harness 155 · runtime-manager 350

Note on #208

This branches off fix/rustsec-2026-0221, so it includes the event-listener 5.4.2 bump — otherwise vuln could not go green here (it would still fail on the other advisory). Merging this makes #208 redundant; close it, or merge it first and this rebases cleanly.

[github-actions]

🔎 Codex cross-audit (agent:audit)

Blocking: none found.

Findings:

• Low: rust-toolchain.toml now says services/*/Dockerfile use rust:1.94-slim, but services/harness/Dockerfile still builds with rust:1.85-alpine. This is not an immediate regression from the current hunk, but it leaves harness builds on a different compiler than CI/dev after this PR’s toolchain bump.

Verification limits: I could not run Cargo/rustc checks because the sandbox is read-only and rustup/rustc need temp/target writes. I did run git diff --check origin/master...HEAD, which passed.

[github-actions]

🔷 Gemini cross-audit (agent:audit-gemini)

🚨 BLOCKING REGRESSION

1. Compilation Failure in services/runtime-manager/src/backends/wasm.rs

The PR upgrades wasmtime and wasmtime-wasi from version 45.0.2 to 46.0.2 in services/runtime-manager/Cargo.toml, but does not update the code to handle a major breaking change in wasmtime-wasi v46.0.

In Wasmtime v46.0.0, the temporary p2 module hierarchy was removed since WASIp2 features became stabilized at the root level of the crate. As a result:

• The issue: The import of MemoryOutputPipe in services/runtime-manager/src/backends/wasm.rs (line 74) will cause a compilation error:

  use wasmtime_wasi::p2::pipe::MemoryOutputPipe; // unresolved import `wasmtime_wasi::p2`

• The fix: Update the import statement in wasm.rs to point to the new top-level structure:

  use wasmtime_wasi::pipe::MemoryOutputPipe;

• Additionally, the documentation comment at line 52 should be updated to refer to wasmtime_wasi::pipe::MemoryOutputPipe instead of wasmtime_wasi::p2::pipe::MemoryOutputPipe.

---

🔍 LINTING & WORKFLOW COVERAGE

2. Clippy result_large_err Check

The addition of #[allow(clippy::result_large_err)] in services/harness/src/exec.rs (line 589) is correct and necessary.
Under Rust 1.94, the size threshold for this lint was tightened, and tonic::Status (176 bytes) now triggers it inside any interceptor closure matching FnMut(Request<()>) -> Result<Request<()>, Status>.

• Coverage Verification: We scanned all other Rust-based services (gateway, model-router, and surface-gateway) to verify if they used tonic interceptors. No other files define inline GRPC client or server interceptors returning Result<..., Status>, meaning this is the only location that requires the suppression attribute.

3. Musl Target & Harness Dockerfile Consistency

• Observation: services/harness/Dockerfile was not modified and continues to build with rust:1.85-alpine.
• Concurrence: This is correct and safe. The harness is a statically-linked PID 1 musl-static binary that runs inside the guest microVMs. It is decoupled from the host runtime-manager's Rust toolchain, and pinning it to an alpine-builder version prevents compatibility drifts in the microVM rootfs environment.

[github-actions]

🔷 Gemini cross-audit (agent:audit-gemini)

Audit Findings for pr-diff.patch

---

🚨 BLOCKING: Compilation Failure

• Issue: Upgrading wasmtime/wasmtime-wasi to 46.0.2 in services/runtime-manager/Cargo.toml without updating services/runtime-manager/src/backends/wasm.rs will fail to compile.
• Details: In wasmtime-wasi v46, the p2 (preview2) submodule was fully promoted to the root of the crate. Therefore, use wasmtime_wasi::p2::pipe::MemoryOutputPipe; on line 77 of wasm.rs is no longer valid.
• Fix: Update the import to use wasmtime_wasi::pipe::MemoryOutputPipe; and update corresponding comments (lines 35–40).

---

⚠️ HIGH: Missed Edge Case (Global Engine Epoch Ticking / Concurrency Bug)

• Issue: Severe race condition resulting in premature/immediate timeouts under concurrent WebAssembly workloads.
• Details: In services/runtime-manager/src/backends/wasm.rs, WasmBackend uses a single shared Engine instance. Every invocation of schedule() or schedule_and_stream() spawns a dedicated background task that sleeps 1s and calls engine_for_ticker.increment_epoch(). Under concurrent load (e.g., 20 concurrent workloads), 20 background tasks will concurrently increment the global engine's epoch. The global epoch will tick 20x faster, causing a 300s deadline (store.set_epoch_deadline(300)) to expire in just 15 seconds.
• Fix: Instead of per-instance epoch ticking, run a single global ticker loop within WasmBackend that increments the global Engine epoch exactly once per second.

---

✅ CORRECTNESS: Bearer Token Clippy Suppression

• Details: The addition of #[allow(clippy::result_large_err)] to the with_interceptor closure inside services/harness/src/exec.rs is correct and necessary. Rust 1.94 has tighter clippy checking for closure return types, flagging the 176-byte tonic::Status which is mandatory for the gRPC interceptor trait signature and cannot be boxed.

[github-actions]

🔎 Codex cross-audit (agent:audit)

Blocking: none found.

I did not find additional correctness or security regressions in git diff origin/master...HEAD. The PR delta is limited to Rust toolchain/image version bumps, Wasmtime/WASI dependency bump for runtime-manager, and a targeted Clippy allow on the harness tonic interceptor.

Verification notes:

• cargo metadata --locked --offline --no-deps succeeded for services/runtime-manager.
• Full cargo check/tests could not run because the environment is read-only and rustup/cargo need to write toolchain/target files.
• Residual risk is the Wasmtime 45 -> 46 sandbox-path upgrade; CI should run cargo test/clippy for runtime-manager before merge.