# MasterChef.updatePool() Fails To Update Reward Variables If block.number >= endBlock

MasterChef.updatePool returns early when block.number >= endBlock without accruing rewards for blocks up to endBlock, so stale pools permanently lose owed Concur yield.

- Payout: Audit contest
- Severity: medium
- Program: Concur Finance
- Found by: leastwood
- Disclosed: 2022-05-24
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-02-concur-findings/issues/107
- Library page: https://bugbountylibrary.com/r/c4%3A2022-02-concur%3AM-20
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:reward-distribution

**Target:** MasterChef staking/reward contract (updatePool)
**Root cause:** The `block.number >= endBlock` branch sets lastRewardBlock = block.number and returns before computing accConcurPerShare, so blocks between lastRewardBlock and endBlock are never accrued.
**Steps:**
1. Deploy MasterChef with a pool and endBlock in the future.
2. Deposit into the pool and let several blocks pass without calling updatePool.
3. Advance block.number past endBlock.
4. Call `updatePool(pid)`; the `block.number >= endBlock` branch returns early, leaving accConcurPerShare unchanged.
5. Compare to a pool that called updatePool just before endBlock; the stale pool receives fewer rewards for the same deposit period.
**How found:** Code reading of updatePool's early-return branches; noticed the endBlock branch skips the accConcurPerShare accrual that the normal path performs.
**Exploitation:** Not an attack; a passive LP that fails to poke updatePool before endBlock forfeits rewards for blocks between its last update and endBlock, while active pools accrue them.
**Insight:** In MasterChef-style reward contracts, audit every early-return branch in updatePool: any branch that sets lastRewardBlock without first accruing accConcurPerShare silently discards the elapsed-block rewards for that pool.