fix(starknet-classes): reject crafted out-of-range type ids instead of panicking - #10224
Conversation
…f panicking `from_contract_class` inspected entry-point signatures via `TypeResolver` before building the program registry, so a crafted class whose entry-point signature referenced an out-of-range type id indexed `program.type_declarations` out of bounds and panicked. Build `ProgramRegistryInfo` first — it already validates all type references, turning the crafted id into a graceful `ProgramRegistryError::MissingType` instead of a panic. Both files (source + test) are the only changes in the tree. Security-sensitive (DoS via declare) → keep local, no public PR, coordinate the release.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
PR SummaryLow Risk Overview Crafted or malformed Sierra where an entry point references an undeclared A regression test mutates an external entry point’s last parameter type to an id past Reviewed by Cursor Bugbot for commit ed7efb1. Bugbot is set up for automated code reviews on this repo. Configure here. |
eytan-starkware
left a comment
There was a problem hiding this comment.
@eytan-starkware reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on orizi).

Summary
ProgramRegistryInfo::newis now called earlier inCasmContractClass::from_contract_class, before entry point signature validation, so that an out-of-range type ID in a function signature is caught and reported as aProgramRegistryErrorrather than causing a panic or misleading error later. A new test (test_entry_point_out_of_range_type_id_rejected) verifies that a contract with an entry point referencing an undeclared type ID is rejected with the correctCompilationError::ProgramRegistryError(ProgramRegistryError::MissingType(...))error.Type of change
Please check one:
Why is this change needed?
When an entry point's function signature referenced a type ID that was not declared in the program's type declarations, the error was not caught at the registry construction stage. By moving
ProgramRegistryInfo::newearlier in the compilation pipeline, the missing type is detected immediately and surfaced as a properProgramRegistryError::MissingTyperather than propagating into later stages where it could cause a panic or an opaque failure.What was the behavior or documentation before?
ProgramRegistryInfo::newwas called after entry point signature validation. An out-of-range type ID in a function signature could reach later compilation stages without a clear, structured error.What is the behavior or documentation after?
ProgramRegistryInfo::newis called before entry point signature validation. An out-of-range type ID in a function signature is immediately rejected withStarknetSierraCompilationError::CompilationError(CompilationError::ProgramRegistryError(ProgramRegistryError::MissingType(...))).Related issue or discussion (if any)
N/A
Additional context
The new test mutates a known-good contract class by replacing the last parameter type of an external entry point with a
ConcreteTypeIdone past the end of the declared types list, confirming the error path end-to-end.