Sitelet https://github.com/starkware-libs/cairo/pull/10224
Skip to content

fix(starknet-classes): reject crafted out-of-range type ids instead of panicking - #10224

Merged
orizi merged 1 commit into
mainfrom
orizi/07-20-fix_starknet-classes_reject_crafted_out-of-range_type_ids_instead_of_panicking
Jul 20, 2026
Merged

orizi merged 1 commit into
mainfrom
orizi/07-20-fix_starknet-classes_reject_crafted_out-of-range_type_ids_instead_of_panicking

Conversation

@orizi

@orizi orizi commented Jul 20, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

ProgramRegistryInfo::new is now called earlier in CasmContractClass::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 a ProgramRegistryError rather 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 correct CompilationError::ProgramRegistryError(ProgramRegistryError::MissingType(...)) error.


Type of change

Please check one:

  • Bug fix (fixes incorrect behavior)
  • New feature
  • Performance improvement
  • Documentation change with concrete technical impact
  • Style, wording, formatting, or typo-only change

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::new earlier in the compilation pipeline, the missing type is detected immediately and surfaced as a proper ProgramRegistryError::MissingType rather than propagating into later stages where it could cause a panic or an opaque failure.


What was the behavior or documentation before?

ProgramRegistryInfo::new was 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::new is called before entry point signature validation. An out-of-range type ID in a function signature is immediately rejected with StarknetSierraCompilationError::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 ConcreteTypeId one past the end of the declared types list, confirming the error path end-to-end.

…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.
@reviewable-StarkWare

Copy link
Copy Markdown

This change is Reviewable

orizi commented Jul 20, 2026

Copy link
Copy Markdown
Collaborator Author

This stack of pull requests is managed by Graphite. Learn more about stacking.

@orizi
orizi requested a review from eytan-starkware July 20, 2026 14:17
@orizi
orizi marked this pull request as ready for review July 20, 2026 14:18
@cursor

cursor Bot commented Jul 20, 2026 •

Copy link
Copy Markdown

PR Summary

Low Risk
Small ordering change in the Starknet compilation pipeline with clearer error handling; behavior for valid contracts is unchanged.

Overview
Starknet contract CASM compilation now builds ProgramRegistryInfo immediately after duplicate entry-point checks and before TypeResolver-based entry-point signature validation.

Crafted or malformed Sierra where an entry point references an undeclared ConcreteTypeId used to hit unchecked indexing in TypeResolver during validation; that path now returns StarknetSierraCompilationError::CompilationError(ProgramRegistryError::MissingType(...)) instead.

A regression test mutates an external entry point’s last parameter type to an id past type_declarations and asserts that exact error.

Reviewed by Cursor Bugbot for commit ed7efb1. Bugbot is set up for automated code reviews on this repo. Configure here.

@eytan-starkware eytan-starkware left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

@eytan-starkware reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on orizi).

@orizi
orizi added this pull request to the merge queue Jul 20, 2026
Merged via the queue into main with commit cb4af62 Jul 20, 2026
55 checks passed
pull Bot pushed a commit to AKJUS/cairo that referenced this pull request Jul 21, 2026
@orizi
orizi deleted the orizi/07-20-fix_starknet-classes_reject_crafted_out-of-range_type_ids_instead_of_panicking branch July 21, 2026 14:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants