Skip to content
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion contracts/events/src/event_ops.rs
Original file line number Diff line number Diff line change
Expand Up @@ -734,7 +734,7 @@ pub fn select_winners(
.ok_or(Error::InvalidDistribution)? as i128;
let amount = base_escrow.saturating_mul(percent) / 100_i128;

let anchor_idx = existing_count + (idx as u32);
let anchor_idx = existing_count.saturating_add(idx as u32);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Info Severity severity

Arithmetic and Financial Logic: silent index collision risk in winner selection loop

existing_count.saturating_add(idx as u32) can clamp anchor_idx to u32::MAX instead of failing if existing_count + idx overflows. Because anchor_idx is persisted in PrizeAward and likely used later to locate the corresponding Winner, saturation could cause multiple awards to share the same anchor_idx, leading to incorrect lookups (wrong recipient/amount) or permanent inability to claim if the index no longer matches the appended winner row.

For persisted indices/anchors, prefer fail-closed arithmetic: use checked_add and return an explicit error (or enforce existing_count <= u32::MAX - winners.len()) so state cannot be written with a clamped/colliding anchor_idx.


Fix with MCP
Almanax found a vulnerability. Can you take a look and fix it?
Finding ID: 14fe1965-603a-4858-8cd4-84c8baba6cfd
Actions
  • Reply /almanax ask <question> to ask a follow-up question.
  • Reply /almanax dismiss [<reason>] and it won't appear again in future scans.
  • Reply /almanax resolve [<reason>] to mark the finding as resolved.
  • Reply /almanax severity <level> [<reason>] to override the severity.

storage::append_winner(
env,
event_id,
Expand Down