BriVault
First Flight #52
Beginner FriendlySolidity
100 EXP
View results
Previous Next
Submission Details
Impact: medium
Likelihood: high
Invalid

Invalid / Unchecked Event Dates Cause Arithmetic Overflow and Lifecycle Corruption

chobby

Constructor fails to validate event start and end dates, allowing invalid or past timestamps that trigger arithmetic overflow or inconsistent event lifecycles.

Description

  • The BriVault constructor accepts _eventStartDate and _eventEndDate without validating that the start date is in the future and strictly less than the end date.

    When an invalid combination such as _eventStartDate >= _eventEndDate or _eventStartDate < block.timestamp is provided, internal arithmetic (likely _eventEndDate - _eventStartDate) can underflow, causing a panic (0x11) during deployment.

    Even when it doesn’t revert, such initialization leads to a broken vault lifecycle — events may start in the past, making it possible to immediately call functions like setWinner() or making deposits permanently fail.

// Root cause in the codebase with @> marks to highlight the relevant section

Risk

Likelihood:

  • Reason 1 // Describe WHEN this will occur (avoid using "if" statements)

  • Reason 2

Impact:

  • Deployment Failure: Constructor panics due to unchecked arithmetic.

  • Lifecycle Corruption: Vault may be initialized in an invalid state (e.g., started before deployment).


  • DoS: Deposits or participation actions may revert if the event is considered ended.


  • Logic Abuse: Deployer could immediately finalize an event or trigger setWinner() without fair participation.

Proof of Concept


Execution output:

[FAIL: panic: arithmetic underflow or overflow (0x11)]
test_constructor_allows_invalid_dates() (gas: 3519394)


This panic demonstrates that unsafe arithmetic occurs during initialization when invalid dates are provided.

function test_constructor_allows_invalid_dates() public {
// case 1: start >= end
vm.prank(owner);
BriVault v1 = new BriVault(
IERC20(address(mockToken)),
100,
block.timestamp + 100, // start
owner,
1 ether,
block.timestamp + 50 // end (invalid: end < start)
);
// v1 deployed where start > end. This should not be allowed.
assert(address(v1) != address(0));
​
// case 2: start in the past
vm.prank(owner);
BriVault v2 = new BriVault(
IERC20(address(mockToken)),
100,
block.timestamp - 10, // start in the past
owner,
1 ether,
block.timestamp + 50
);
// v2 already "started" at deploy — allows early lifecycle actions
assert(address(v2) != address(0));
}

Recommended Mitigation

Add validation checks in the constructor

This ensures the vault lifecycle is consistent and prevents arithmetic underflow.

require(_eventStartDate > block.timestamp, "Invalid: start must be in future");
require(_eventEndDate > _eventStartDate, "Invalid: end must be after start");
​
Updates

Appeal created

bube Lead Judge 19 days ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Missing Constructor Validation

This is owner action and the owner is assumed to be trusted and to provide correct input arguments.

Support

FAQs

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

Give us feedback!