Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice:

• Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range.
• Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice:

• Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty.
• Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range:

• Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range.
• Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs:

• Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0).
• Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

• Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
• Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

• https://github.com/stellar/rs-soroban-sdk/pull/1703
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice:

• Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range.
• Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice:

• Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty.
• Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range:

• Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range.
• Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs:

• Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0).
• Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

• Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
• Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

• https://github.com/stellar/rs-soroban-sdk/pull/1703
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice:

• Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range.
• Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice:

• Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty.
• Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range:

• Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range.
• Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs:

• Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0).
• Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

• Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
• Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

• https://github.com/stellar/rs-soroban-sdk/pull/1703
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice:

• Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range.
• Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice:

• Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty.
• Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range:

• Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range.
• Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs:

• Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0).
• Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

• Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
• Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

• https://github.com/stellar/rs-soroban-sdk/pull/1703
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice:

• Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range.
• Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice:

• Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty.
• Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range:

• Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range.
• Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs:

• Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0).
• Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

• Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
• Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

• https://github.com/stellar/rs-soroban-sdk/pull/1703
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice:

• Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range.
• Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice:

• Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty.
• Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range:

• Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range.
• Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs:

• Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0).
• Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

• Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
• Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

• https://github.com/stellar/rs-soroban-sdk/pull/1703
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice:

• Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range.
• Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice:

• Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty.
• Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range:

• Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range.
• Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs:

• Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0).
• Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

• Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
• Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

• https://github.com/stellar/rs-soroban-sdk/pull/1703
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice:

• Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range.
• Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice:

• Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty.
• Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range:

• Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range.
• Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs:

• Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0).
• Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

• Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
• Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

• https://github.com/stellar/rs-soroban-sdk/pull/1703
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice:

• Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range.
• Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice:

• Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty.
• Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range:

• Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range.
• Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs:

• Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0).
• Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

• Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
• Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

• https://github.com/stellar/rs-soroban-sdk/pull/1703
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice:

• Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range.
• Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice:

• Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty.
• Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range:

• Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range.
• Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs:

• Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0).
• Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

• Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
• Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

• https://github.com/stellar/rs-soroban-sdk/pull/1703
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice:

• Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range.
• Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice:

• Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty.
• Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range:

• Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range.
• Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs:

• Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0).
• Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

• Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
• Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

• https://github.com/stellar/rs-soroban-sdk/pull/1703
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice:

• Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range.
• Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice:

• Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty.
• Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range:

• Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range.
• Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs:

• Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0).
• Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

• Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
• Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

• https://github.com/stellar/rs-soroban-sdk/pull/1703
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9

Security Advisory: Incorrect Equality for Fr Scalar Field Types (BN254, BLS12-381)

Summary

Missing modular reduction in Fr causes incorrect equality comparisons for BN254 and BLS12-381 types in soroban-sdk.

Impact

The Fr (scalar field) types for BN254 and BLS12-381 in soroban-sdk compared values using their raw U256 representation without first reducing modulo the field modulus r. This caused mathematically equal field elements to compare as not-equal when one or both values were unreduced (i.e., >= r).

The vulnerability requires an attacker to supply crafted Fr values through contract inputs, and compare them directly without going through host-side arithmetic operations.

Smart contracts that rely on Fr equality checks for security-critical logic could produce incorrect results. The impact depends on how the affected contract uses Fr equality comparisons, but can result in incorrect authorization decisions or validation bypasses in contracts that perform equality checks on user-supplied scalar values.

Details

Fr types for both curves are wrappers around U256. The PartialEq implementation compared the raw U256 values directly. However, the constructors (from_u256, from_bytes, From<U256>) accepted arbitrary U256 values without reducing them modulo r. This meant two Fr values representing the same field element (e.g., 1 and r + 1) could have different internal representations and compare as not-equal.

This issue was compounded by an asymmetry: all host-side arithmetic operations (fr_add, fr_sub, fr_mul, fr_pow, fr_inv) always return canonically reduced results in [0, r), while user-constructed Fr values could hold unreduced representations. Comparing a user-supplied Fr against a host-computed Fr would therefore produce incorrect results even when the underlying field elements were identical.

Example

let r = /* BN254 scalar field modulus */;
let a = Fr::from_u256(r + 1); // unreduced, stores r+1
let b = Fr::from_u256(1);     // reduced, stores 1

// a and b represent the same field element (1), but compared as NOT equal
assert_eq!(a, b); // FAILED before the fix

Patches

All Fr construction paths now reduce the input modulo r, ensuring a canonical representation in [0, r). This guarantees that equal field elements always have identical internal representations, making the existing PartialEq comparison correct.

Additionally, Fp and Fp2 base field types for both curves now validate that values are strictly less than the field modulus on construction, rejecting out-of-range inputs.

Workarounds

If upgrading is not immediately possible:

• Manually reduce the underlying U256 via rem_euclid by the field modulus r before constructing Fr, or round-trip through host Fr arithmetic (e.g., fr_add(val, zero)) which always returns reduced results. Note: BN254 does not expose dedicated Fr host functions, so rem_euclid is the only option there.

Recommendations

• Upgrade to the patched version of soroban-sdk.
• Review any deployed contracts that accept Fr values as input, and compare those values using ==, !=, or assert_eq!. These contracts may be vulnerable if an attacker can supply unreduced scalar values to bypass equality checks.

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice:

• Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range.
• Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice:

• Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty.
• Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range:

• Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range.
• Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs:

• Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0).
• Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

• Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
• Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

• https://github.com/stellar/rs-soroban-sdk/pull/1703
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
• https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9