Limit XDR nesting depth when decoding contract spec/meta sections - #2668
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Limits XDR decoding depth for attacker-controlled contract metadata and specs, preventing stack exhaustion.
Changes:
- Adds a depth limit of 500 to relevant XDR decoders.
- Adds tests for deeply and normally nested specifications.
leighmcculloch
approved these changes
Aug 4, 2026
Galmanus
added a commit
to Galmanus/stellar-cli
that referenced
this pull request
Sep 1, 2026
…n recursive specs
`Spec::arg_value_name` threads a `depth` counter but never checks it. A
contract whose spec contains a recursive type — e.g.
`struct TreeNode { children: Vec<TreeNode> }`, which the SDK and the
network accept — sent the resolver into unbounded recursion, overflowing
the stack on every `contract invoke` against the contract, including
`-- --help`. Anyone can deploy such a contract, so this crashed the CLI
of anyone who tried to interact with it.
UDTs are the only types resolved by name, so any cycle must pass through
the `ScType::Udt` arm; cap the expansion depth there and render the
type's name past the cap. Returning `None` instead would erase the
whole value name, since `None` propagates through the `?` in every
caller. `example_udts` already bounds example rendering the same way.
Complements stellar#2668, which capped XDR decode depth for deeply-nested
specs; a cycle through UDT name references never nests deeply in the
encoded XDR, so it needs this separate guard.
Fixes stellar#2445
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Decode a contract's
contractenvmetav0,contractmetav0, andcontractspecv0sections with an explicit XDR depth limit (SPEC_XDR_DEPTH_LIMIT = 500) instead ofLimits::none().Why
These sections come from attacker-authored contract WASM, and
ScSpecTypeDefis a recursive XDR type. Decoding withLimits::none()(depthu32::MAX) lets a deeply-nested type definition recurse until it exhausts the stack and aborts the process. Capping the depth turns that crash into a cleanDepthLimitExceedederror. The value 500 matchessoroban-env-host'sDEFAULT_XDR_RW_LIMITS, so any spec the network would accept still decodes, while deeper input is rejected. Tests cover both a deeply-nested spec that must be rejected and a normally-nested spec that must still decode.Known limitations
N/A