# Attacker can block all votes to a specific pool by triggering an overflow error

Attacker bribes a pool with a self-minted max-supply token, inflating accDebtPerShare so any later vote on that pool reverts on overflow, blocking votes and stealing yield.

- Payout: Contest reward
- Severity: high
- Program: Magicsea
- Credited: santipu_
- Disclosed: 2024-07-15
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2024-06-magicsea-judging/issues/237
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-magicsea%3AH-7
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:business-logic vuln:dos vuln:governance

**Target:** BribeRewarder / Rewarder2 reward accounting in Voter voting flow
**Root cause:** getDebtPerShare divides (totalRewards << ACC_PRECISION_BITS) by totalSupply; with attacker-controlled max-supply token and 1 wei deposit, accDebtPerShare becomes astronomically large. Later getDebt multiplies deposit * accDebtPerShare and overflows, reverting every vote.
**Steps:**
1. Deploy custom ERC20 and mint `type(uint256).max` to a new BribeRewarder via `factory.createBribeRewarder(token, pool)`.
2. Call `rewarder.bribe(1, 1, type(uint256).max)` to distribute whole supply in one period to the target pool.
3. At period start, vote with 1 wei via `rewarder.deposit(1, 1, 1)` to initialize `accDebtPerShare` to a huge value.
4. Any legitimate voter calling `Voter::vote` triggers `_notifyBribes` -> `rewarder.deposit(periodId, tokenId, deltaAmount)`; `getDebt` computes `deposit * accDebtPerShare` and reverts with arithmetic overflow.
5. Repeat across pools/periods to block all votes; remaining unblocked pool captures most Masterchef rewards next epoch.
**How found:** Code review of Rewarder2 accounting: noticed getDebtPerShare can produce huge values when totalSupply is tiny and totalRewards huge, and that getDebt's unchecked multiplication would overflow; realized permissionless bribe creation with arbitrary token lets attacker control both inputs.
**Exploitation:** Attacker needs no capital beyond gas: permissionlessly creates a BribeRewarder with a self-minted token, seeds accDebtPerShare with a 1 wei vote, then all subsequent votes to that pool revert. By blocking votes to competing pools, the attacker's preferred pool receives disproportionate emissions in the next epoch via sync-farms.js, stealing yield from other users.
**Escalation:** Can be applied to all pools in all periods, permanently bricking voting until contracts are upgraded; converts DoS into yield theft by funneling emissions to attacker-favored pool.
**Insight:** In share-based reward accounting, look for permissionless creation of reward streams with attacker-controlled token supply: a 1 wei deposit plus max-supply rewards can poison accDebtPerShare and make every later deposit revert. Check multiplication in getDebt for overflow when accumulator is attacker-influenced.