Rust Fund

AI First Flight #9
Beginner FriendlyRust
EXP
View results
Submission Details
Severity: medium
Valid

Deadline can be changed repeatedly because dealine_set flag is never set to true after deadline assignment

Normal behavior:
The set_deadline instruction should allow the creator to set the campaign deadline exactly once. After the deadline is set, it should be immutable — the dealine_set flag should prevent any further changes. This ensures contributors can rely on the deadline as a guaranteed timeframe for refund eligibility.

Specific issue:
The set_deadline instruction checks the dealine_set flag to prevent the deadline from being set more than once: if fund.dealine_set { return Err(DeadlineAlreadySet) }. However, after setting the deadline (fund.deadline = deadline), the instruction does NOT set fund.dealine_set = true. The guard flag is read but never written, so it remains false forever. The DeadlineAlreadySet error can never be triggered. The creator can call set_deadline any number of times, changing the deadline to any value — extending it forward to prevent refunds, or pulling it backward to a past timestamp.

ROOT CAUSE:

pub fn set_deadline(ctx: Context<FundSetDeadline>, deadline: u64) -> Result<()> {
let fund = &mut ctx.accounts.fund;
if fund.dealine_set {
return Err(ErrorCode::DeadlineAlreadySet.into());
}
// @> MISSING: fund.dealine_set = true; — flag never set!
fund.deadline = deadline;
Ok(())
}

RISK:

Likelihood:
HIGH — This occurs whenever a creator calls set_deadline more than once. Since the dealine_set flag is never set to true, every call to set_deadline will pass the guard check. The creator can change the deadline at will, at any time, any number of times. There are no conditions that must be met for the repeated calls to succeed.

Impact:
MEDIUM — Contributors cannot rely on the campaign deadline as a guaranteed timeframe. The creator can push the deadline forward to indefinitely prevent refund eligibility, keeping contributor funds locked. The creator can also pull the deadline backward to a past timestamp to make the campaign appear expired. This undermines the fundamental trust model of time-bounded crowdfunding but does not directly steal funds (the creator could already withdraw anytime via RF-01).

PROOF OF CONCEPT:

// RF-03: Deadline can be changed repeatedly (dealine_set never set to true)
// Save as: tests/rf03-poc.ts
it("set_deadline succeeds multiple times (should fail on 2nd call)", async () => {
await program.methods.fundCreate("DeadlineTest", "Test", goal)
.accounts({ fund: fundPDA, creator: creator.publicKey,
systemProgram: anchor.web3.SystemProgram.programId })
.rpc();
// 1st set_deadline: T1 = 7 days from now
const T1 = new anchor.BN(Math.floor(Date.now()/1000) + 7*24*3600);
await program.methods.setDeadline(T1)
.accounts({ fund: fundPDA, creator: creator.publicKey })
.rpc();
let fund = await program.account.fund.fetch(fundPDA);
assert(fund.deadline.toString() === T1.toString());
assert(fund.dealineSet === false, "dealine_set should be false (BUG)");
// 2nd set_deadline: T2 = 30 days from now (SHOULD FAIL but succeeds)
const T2 = new anchor.BN(Math.floor(Date.now()/1000) + 30*24*3600);
await program.methods.setDeadline(T2)
.accounts({ fund: fundPDA, creator: creator.publicKey })
.rpc();
fund = await program.account.fund.fetch(fundPDA);
assert(fund.deadline.toString() === T2.toString(), "Deadline changed!");
assert(fund.dealineSet === false, "dealine_set still false");
// 3rd set_deadline: T3 = past timestamp (also succeeds)
const T3 = new anchor.BN(Math.floor(Date.now()/1000) - 3600);
await program.methods.setDeadline(T3)
.accounts({ fund: fundPDA, creator: creator.publicKey })
.rpc();
fund = await program.account.fund.fetch(fundPDA);
assert(fund.deadline.toString() === T3.toString(), "Deadline set to past!");
});

RECOMMENDED MITIGATION:

if fund.dealine_set {
return Err(ErrorCode::DeadlineAlreadySet.into());
}
-
+ fund.dealine_set = true;
fund.deadline = deadline;
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 3 hours ago
Submission Judgement Published
Validated
Assigned finding tags:

[M-02] The set_deadline function does not set the dealine_set flag to true

The `set_deadline()` function in the `rustfund` program contains a vulnerability that allows campaign creators to manipulate deadlines indefinitely. While the function correctly checks if `fund.dealine_set` is true before allowing the deadline to be changed, it never sets this flag to true after setting the deadline. ```rust pub fn set_deadline(ctx: Context<FundSetDeadline>, deadline: u64) -> Result<()> { let fund = &mut ctx.accounts.fund; if fund.dealine_set { return Err(ErrorCode::DeadlineAlreadySet.into()); } fund.deadline = deadline; Ok(()) } ``` The function is missing a crucial line to update the flag: `fund.dealine_set = true;` This oversight bypasses a key safeguard intended to prevent creators from manipulating deadlines after they've been set. According to the project documentation, this flag is meant to enforce deadline immutability, which is an essential part of the platform's trust model. ### Impact 1. **Refund evasion**: Creators can prevent users from obtaining refunds by continually extending the deadline whenever it approaches. This directly undermines the project's advertised "Refund Mechanism" which promises that "Contributors can get refunds if deadlines are reached and goals aren't met." 2. **Fund locking**: Contributors' funds can be effectively locked indefinitely, as the refund function is contingent upon the deadline being reached: ```rust if ctx.accounts.fund.deadline != 0 && ctx.accounts.fund.deadline > Clock::get().unwrap().unix_timestamp.try_into().unwrap() { return Err(ErrorCode::DeadlineNotReached.into()); } ``` ### Proof of Concept (PoC) The following test demonstrates how a creator can set the deadline multiple times, effectively bypassing the intended deadline immutability: ```javascript import * as anchor from "@coral-xyz/anchor"; import { Program } from "@coral-xyz/anchor"; import { Rustfund } from "../target/types/rustfund"; import { assert } from "chai"; describe("VULN-02: set_deadline vulnerability", () => { // Configures the provider to use the local cluster const provider = anchor.AnchorProvider.env(); anchor.setProvider(provider); const program = anchor.workspace.Rustfund as Program<Rustfund>; // Test variables const fundName = "TestFund"; const description = "Testing deadline vulnerability"; const goal = new anchor.BN(1000000); let fundPda: anchor.web3.PublicKey; it("Allows you to modify the deadline several times", async () => { // Derivation of PDA address for financing account [fundPda] = await anchor.web3.PublicKey.findProgramAddress( [Buffer.from(fundName), provider.wallet.publicKey.toBuffer()], program.programId ); // Fund creation await program.rpc.fundCreate(fundName, description, goal, { accounts: { fund: fundPda, creator: provider.wallet.publicKey, systemProgram: anchor.web3.SystemProgram.programId, }, }); // First deadline assignment const deadline1 = new anchor.BN(Math.floor(Date.now() / 1000) + 3600); // 1 hour in the future await program.rpc.setDeadline(deadline1, { accounts: { fund: fundPda, creator: provider.wallet.publicKey, }, }); // Second deadline assignment (which should not be possible if the flag is set to true) const deadline2 = new anchor.BN(Math.floor(Date.now() / 1000) + 7200); // 2 hours into the future await program.rpc.setDeadline(deadline2, { accounts: { fund: fundPda, creator: provider.wallet.publicKey, }, }); // Check that the deadline has been updated to the second value const fundAccount = await program.account.fund.fetch(fundPda); assert.ok( fundAccount.deadline.eq(deadline2), "The deadline may have been modified several times, but vulnerability presents" ); }); }); ``` Save the above test as, for example, tests/02.ts in your project's test directory and run the test : ```Solidity anchor test ``` ### Concrete Impact Example To illustrate the real-world impact of this vulnerability, consider this scenario: - A creator launches a campaign to fund a project with a goal of 100 SOL - The creator sets an initial deadline of 30 days - Contributors collectively deposit 80 SOL (below the goal) - As the deadline approaches, the creator realizes they won't reach the goal - Instead of allowing refunds as promised, the creator extends the deadline by another 30 days - This pattern can repeat indefinitely, effectively locking contributor funds - Even if contributors try to request refunds, they'll be rejected with "DeadlineNotReached" errors ### Recommendation The fix for this vulnerability is straightforward. The `set_deadline()` function should be modified to set the `dealine_set` flag to true after setting the deadline: ```rust pub fn set_deadline(ctx: Context<FundSetDeadline>, deadline: u64) -> Result<()> { let fund = &mut ctx.accounts.fund; if fund.dealine_set { return Err(ErrorCode::DeadlineAlreadySet.into()); } fund.deadline = deadline; fund.dealine_set = true; // Add this line to fix the vulnerability Ok(()) } ```

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!