Having a 100% RF is a legitimate configuration for a reserve, so the fix should be on the logic not properly handling that case, instead of only adding extra validation to not allow a set of 100%.
To be researched deeper, but highly probable that the change should be done around the condition of ReserveLogic not contemplating the 100% RF scenario.
Other initial aspects to consider:
Gas implications of the fix should be checked.
New tests should be added for the 100% RF case.
The fix should be applied on both the v2 version deployed on Polygon/Avalanche and the one on Aave v2 Ethereum. Initially, in what concerns this part of the logic, they should be exactly the same.
Context
The problem/consequences are explained HERE.
How
Having a 100% RF is a legitimate configuration for a reserve, so the fix should be on the logic not properly handling that case, instead of only adding extra validation to not allow a set of 100%.
To be researched deeper, but highly probable that the change should be done around the condition of ReserveLogic not contemplating the 100% RF scenario.
Other initial aspects to consider:
Gas implications of the fix should be checked.
New tests should be added for the 100% RF case.
The fix should be applied on both the v2 version deployed on Polygon/Avalanche and the one on Aave v2 Ethereum. Initially, in what concerns this part of the logic, they should be exactly the same.
[ ] Aave v2 Ethereum https://github.com/aave/protocol-v2/pull/317
[ ] Aave v2 Polygon https://github.com/aave/protocol-v2/pull/316
[ ] Aave v2 Avalanche https://github.com/aave/protocol-v2/pull/318