Root + Impact

Description

• Arithmetic on u64 accounting fields should use checked operations so that an overflow returns a clean program error rather than panicking, which is how withdraw and refund already handle their lamport math.

  contribute updates the running total with a plain +=, the only unchecked arithmetic site in the program.

Risk

Likelihood:

• When contributions accumulate, the addition runs without overflow checking, unlike the checked_sub / checked_add used in withdraw and refund.

• A real overflow requires totals beyond the entire SOL supply, so it does not occur in practice; this is a consistency and robustness gap rather than a reachable exploit.

Impact:

• A theoretical u64 overflow would panic and abort the instruction instead of returning a typed error. The impact is limited to code-quality and defense-in-depth because lamport totals are bounded by the SOL supply.

Proof of Concept

Static observation of the += on the amount_raised update in contribute. The overflow itself is not reachable with realistic balances, so there is no runtime exploit; the finding is the inconsistent, panic-prone arithmetic.

Recommended Mitigation

Use checked_add, which matches the arithmetic style of the rest of the program and returns a typed error instead of panicking, eliminating the only unchecked arithmetic in the codebase. This is the same change already included in the H-2 fix.

Recommended Mitigation

Use checked_add, which matches the arithmetic style of the rest of the program and returns a typed error instead of panicking, eliminating the only unchecked arithmetic in the codebase. This is the same change already included in the H-2 fix.