state.rs: Harden C enum casting

[drozdziak1]

This change makes it impossible to construct PriceStatus, PriceType and CorpAction enums from raw bytes that don't represent one of the valid values. All casting calls are replaced with their checked variants. Additionally, we explicitly define the first value of each enum and use the concrete int type corresponding with the oracle C code (u32 <=> uint32_t).

Motivation

in pyth-agent we've seen reports of extremely large allocation attempts which would mysteriously crash the service. It turned out that the most recent Ignored PriceStatus field was not part of the SDK version used in agent, but the bytemuck cast would still happily assign the value. Rust would then trust this field and presumably misinterpret some out-of-bounds data as a size to allocate. Although bumping the dependency fixed the problem, with this change we will get a proper error when casting an invalid enum value, making outdated SDK dependencies easier to spot.

Testing

• True positive unit test verifying a valid PriceStatus raw value
• True negative unit test confirming error for invalid PriceStatus raw values

[guibescos]

Unrelated : what is the point of all these cast_slice and try_cast_slice seems redundant.

[jayantk]

lgtm. Are we sure that pyth-agent and such don't crash if they can't deserialize an account (i.e., when this load function fails)? I think there's a potential failure mode here where we do a program upgrade that extends the serialization format, and then all of the data providers crash.

[drozdziak1]

I think they may crash if some of the checked methods panic (the non-try_ variants). I want to refine this a bit more to confirm that:

• nested CheckedBitPattern members are verified
• the code never panics

As for format changes, I think it's a matter of sane versioning. I think we failed to indicate that there's a new price status (e.g. by bumping format version) and that's why we've seen the agent problem with the memory allocation. This change helps us make this more obvious in the enum case because Rust seems too confident about enum validity when transmuting from bytes. We probably should pay more attention to versioning the on-chain format, but this additional check is nice to have and prevent undefined behavior.