# Finding 4: MAX_ARG inputs accepted without bounds checking

​

**Severity:** Medium

**Title:** No upper bound validation on u64 parameters allows state corruption via overflow

​

## Description

Multiple instructions (`fund_create`, `contribute`, `set_deadline`) accept raw `u64` input parameters without enforcing upper limits or sanity checks. While Anchor prevents absolute primitive math panics via safe math operations under the hood, allowing extreme numbers like `u64::MAX` breaks the program's business constraints. It corrupts state states like target goals, campaign parameters, and deadlines.

​

## Impact

Campaign account variables can be manipulated into absurd values. For example, a campaign target goal can be set to an unreachable value, or `amount_raised` can scale incorrectly. This causes sequential accounting logic checks (such as withdraw or refund math evaluations) to break, creating systemic failures or denial-of-service conditions.

​

## Proof of Concept

This simulation trace shows how unbounded parameter entry corrupts accounting metrics:

​

1. A creator initializes a new fund with a goal argument set to `u64::MAX`.

2. A contributor deposits funds, but the calculated target tracking parameters become corrupted.

3. Subsequent logic queries evaluate corrupted state variables, rendering matching milestones unreachable.

​

```rust

fund_create(name="OverflowCampaign", goal=18446744073709551615)

​

```

​

## Recommended Mitigation

This mitigation applies boundary check validation rules to verify parameter sizes against secure protocol bounds before mutating state fields.

​

Introduce appropriate upper threshold assertions inside the instruction methods:

​

```rust

require!(amount > 0, ErrorCode::ZeroContribution);

require!(amount <= 1_000_000 * LAMPORTS_PER_SOL, ErrorCode::ContributionTooLarge);

​

require!(goal > 0, ErrorCode::ZeroGoal);

require!(goal <= 10_000_000 * LAMPORTS_PER_SOL, ErrorCode::GoalTooLarge);

```

​