Rust Fund

Description:

The contribute function updates the running total of funds raised using plain, unchecked addition:

Rust's default release-mode behavior does not panic on integer overflow (overflow-checks are a debug-build-only default). If fund.amount_raised were ever pushed past u64::MAX, the value would silently wrap around to a small number rather than erroring out or saturating.

Root Cause:

Use of the += operator instead of checked_add (or saturating_add) on a u64 accumulator that is not otherwise bounded.

Impact:

w. Reaching an overflow would require fund.amount_raised to accumulate to roughly u64::MAX lamports (~18.4 billion SOL), which is several orders of magnitude beyond Solana's total circulating supply (~600M SOL). Additionally, amount in each call is not an arbitrary attacker-controlled number decoupled from real value — it is enforced by an actual system_program::transfer CPI, meaning the contributor must actually possess and transfer that many lamports for the call to succeed at all. There is no way to inflate amount_raised without transferring real, correspondingly large sums of SOL.

Given these constraints, this is not considered practically exploitable under current Solana economics. It is flagged as a low-severity, defense-in-depth issue: unchecked arithmetic is a general anti-pattern in Solana/Anchor programs, and using checked_add costs nothing while removing any reliance on assumptions about token/lamport supply limits that could change over the life of the program (e.g. if ported to a context with a different accounting unit, or if amount_raised is ever computed/combined differently in a future upgrade).

Recommended Mitigation:

Replace the unchecked addition with a checked variant and propagate a proper error on overflow: