Skip to content

Add explicit length check on user-supplied Symbol #1564

Description

@Baskarayelu

Summary

Reject anything > 9 chars before it reaches Symbol::new.

Background

This is a defence-in-depth fix. Even though we have no public report of exploitation, the gap below is the kind of thing a careful auditor would flag and that we want closed before any external review. The change should be implemented as part of the security baseline rather than as a reaction to an incident.

Acceptance criteria

  • The change matches the summary above.
  • A negative test exercises the new check.
  • The PR description names the threat being mitigated.
  • Lint, type-check, and tests all pass locally.
  • PR description references this issue with Closes #<this-issue>.

Implementation hints

  • Threat-model the change before you write it: what does an attacker get if this check is missing? Document that in the PR description.
  • Surface a typed error (Soroban #[contracterror] / Zod / TS discriminated union) instead of panicking or returning a generic 500.
  • Add a negative test that fails today before your fix and passes after. The diff must include both.
  • If the change is on a hot path, measure the cost (env.cost_estimate() for Soroban, a microbenchmark for TS) and put the number in the PR description.

Repo-specific notes

  • This is a Soroban contract crate. Run cargo build --target wasm32-unknown-unknown --release to verify the change still builds for WASM.
  • Run cargo test -p <package> for the affected crate, and cargo clippy --workspace --all-targets -- -D warnings before pushing.
  • Keep #![no_std] discipline: do not introduce std:: calls; use soroban_sdk primitives.

Out of scope

  • Unrelated refactors in adjacent files.
  • Stylistic-only changes (formatting, renaming) that are not required by the fix.
  • Anything beyond the acceptance criteria above; surface follow-ups as separate issues.

How to claim and submit

  1. Comment on this issue saying you'd like to take it on; wait for a maintainer to assign you (avoids duplicated effort).
  2. Open a PR that references this issue (Closes #<this-issue>).
  3. Make sure CI is green and request review from a CODEOWNERS maintainer.
  4. PRs that close this issue and pass review may qualify for a reward — see the MAYBE REWARDED label and the GrantFox OSS campaign page.

Category: security  ·  Campaign: GrantFox OSS · Official Campaign · Maybe Rewarded

Metadata

Metadata

Assignees

Labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions