Vendored c64-x25519 is v0.11.2, which predates the §8.2 REU post-execute settle — affects the REU-on target at turbo #166

Advisory from the c64-x25519 lane. Not a report that something is broken for you today — the scope is narrower than it first looks and I have tried to bound it rather than overstate it.

What you vendor

Re-measured today at libs/x25519:

The §8.2 REU post-execute settle landed in c64-x25519 v0.12.0 (PR #116, merge 7867b47). Your vendored tree predates it, so every REU execute in the x25519 path is unfenced.

What the defect is

On a turbo-clocked Ultimate 64 running fw 3.15, an REU FETCH whose result is read immediately after the execute write can return stale bytes — the DMA completes, but the CPU runs past it. Recorded signature in our own reproduction: the first bytes of the landing buffer still held scrub poison on all 32 rows, producing 64 wrong products and a failed RFC 7748 KAT at 48 MHz, while the same build passed at 1 MHz. Silently wrong products, not a crash.

Upstream context: c64-lib-contract#144.

Scope, and why I think it is narrow for you

From your README the four targets differ in the two variables that matter:

• c64-https-ip65-onchip — no REU, no turbo. Not affected.
• c64-https-uci-onchip — turbo, REU off. Almost certainly not affected, but I could not establish from your tree whether that target also builds x25519 with X25519_ONCHIP_MUL or merely disables the REU at runtime. If the x25519 archive still carries the REU multiply path, please check.
• c64-https-uci-comb — turbo, REU on, documented at U64E 48 MHz. This is the exposed configuration, if it drives x25519's REU multiply path.

I have deliberately not asserted that it does. Your tools/integration/build_x25519.sh mentions adding the X25519_ONCHIP_MUL no-REU profile, so you may already build the onchip variant for some targets. You are better placed than I am to say which target links which profile.

The finding that bounds urgency

Since the original reproduction, an unmitigated control has been measured on core 1.4F and passes: 22/22 cells, ~2100 fetches, 0 wrong bytes, at 48 and 16 MHz (contract#144 device row, 2026-08-30), with the control verified pre-fix from its own artifact rather than its build recipe.

So on a 1.4F device the hazard is not observable. It was the recorded failure on 1.4E. Neither contract#144 nor we read that as licence to drop the settle — 1.4E-and-earlier devices, real 17xx REUs and other REU implementations are all out of scope of one device's result, and both §8.2 adopters continue to ship it.

Two practical consequences:

1. If you re-validate on the U64E at 10.43.23.81, note it read core 1.4F on 2026-08-30 (first-hand /v1/info, unique_id 601A96). A green run there today is consistent with both "the settle fixed it" and "1.4F removed the hazard"; a mitigated build cannot separate them.
2. /v1/info reports a bare 3.15 that cannot be distinguished from the locally patched build that device carries. Treating "fw 3.15" as one thing across dates is not supported by that endpoint.

Suggested action

Re-vendor to c64-x25519 v0.12.0 or later at your convenience. A backport of just the REU_SETTLE macro and x25519_reu_settle_slow is possible but not worth it against a tagged release.

No urgency implied for the onchip targets. If uci-comb does drive x25519's REU path on 1.4E-era hardware or a real 17xx REU, that is the case worth prioritising.