# _pendingltv[asset] will be set to 0 if 2 consecutive calls to setreservefreeze(asset, true)are executed

Repeated setReserveFreeze(asset,true) overwrites _pendingLtv with 0, so unfreezing restores LTV to 0 and blocks collateral use.

- Payout: Contest reward
- Severity: medium
- Program: Aave
- Credited: r0bert
- Disclosed: 2024-06-02
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_aave_may2024.pdf#3.1.1
- Library page: https://bugbountylibrary.com/r/cantina%3Aaave_may2024%3A3.1.1
- Tags: domain:web3 impact:dos kind:contest platform:cantina sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** PoolConfigurator.setReserveFreeze in Aave V3.1
**Root cause:** setReserveFreeze(true) unconditionally writes currentConfig.getLtv() into _pendingLtv; on a second freeze the config LTV is already 0, overwriting the saved value.
**Steps:**
1. Call `setReserveFreeze(USDC, true)` as risk admin: `_pendingLtv[USDC]=7700`, config LTV set to 0.
2. Call `setReserveFreeze(USDC, true)` again as emergency admin: `_pendingLtv[USDC]=currentConfig.getLtv()=0`.
3. Call `setReserveFreeze(USDC, false)`: LTV restored from `_pendingLtv[USDC]` = 0 instead of 7700.
**How found:** Code review of the modified setReserveFreeze in the 3.1 update, noticing the unconditional _pendingLtv assignment on freeze and reasoning about idempotent repeated calls by different admin roles.
**Exploitation:** No attacker action; two admins independently freezing the same asset triggers the overwrite, leaving LTV permanently 0 after unfreeze until manually corrected.
**Insight:** When a state-saving pattern writes a value that the same function then zeroes, test idempotent re-invocation by any of the multiple authorized roles; the second call reads the already-mutated config.