# BlueBerryBank#getPositionValue causes DOS if reward token is added that doens't have an oracle

BlueBerryBank.getPositionValue reverts when a newly added Aura/Convex reward token lacks an oracle, temporarily blocking liquidations and risking bad debt.

- Payout: Contest reward
- Severity: medium
- Program: Blueberry
- Credited: 0x52
- Disclosed: 2023-04-07
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-04-blueberry-judging/issues/115
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-04-blueberry%3AM-7
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:dos vuln:liquidation vuln:oracle-manipulation

**Target:** BlueBerryBank.getPositionValue / IERC20Wrapper.pendingRewards
**Root cause:** getPositionValue iterates the live pendingRewards token list and calls oracle.getTokenValue on each; a reward token with no oracle makes the call revert, and getPositionValue is on the liquidation path.
**Steps:**
1. Aura/Convex pool adds a new reward token with no oracle configured in Blueberry.
2. IERC20Wrapper.pendingRewards returns that token in the tokens array.
3. getPositionValue loops tokens and calls `oracle.getTokenValue(tokens[i], rewards[i])`, which reverts for the unpriced token.
4. Any action calling getPositionValue (repay, liquidate) reverts until an oracle is added.
**How found:** Code reading of getPositionValue: noticed pendingRewards pulls a fresh, externally-controlled token list and each entry is priced via oracle without handling missing oracles.
**Exploitation:** Not attacker-triggered; occurs passively when a pool adds an unpriced reward token, blocking liquidations during volatility and allowing bad debt to accumulate.
**Insight:** When a valuation loop iterates an externally-updatable token list (pendingRewards, reward arrays), treat any unpriceable entry as zero rather than reverting, since these loops sit on liquidation/repay paths where a revert is a liveness bug.