Aave is a very common loan protocol in the web3 space. This works by depositing your collateral to the system, which allows you to take out loans from any token in the eco-system. A user can withdraw or deposit assets. The method of keeping track of this is Atokens, which act similar to collateral tokens (cTokens) on other protocols.
Denial of services (DoS) are particularly nasty in the blockchain space because contracts are commonly built to be not-updatable. So, being able to lock assets in the contract would be awful. Forcing reverting or crashes is a common way to do this.
When the user owns at least an AToken with a LTV of 0 and this AToken is used as collateral, restrictions aer put onto the types of interactions that can be performed. Withdraw, transfer and a few others do not work. I don't understand why this is the case but that's how this functions.
When an AToken is received by a user without any balance on a transfer, it is automatically added as collateral. However, this conflicts with some of the checks mentioned above. We can transfer over a poisoned token that will cause reverts on most functions because of the account having value it shouldn't have.
It is possible to escape this with specific set of actions. However, if this is an EOA, then these actions would have to be done in sequence, giving a bot the opportunity to send over more funds to cause a crash. Neat!
To fix this, the token shouldn't be added as collateral right away if the received AToken has a LTV of 0. Compared to web2, there are so many ways to interact with a system to cause problems; from sending unexpected tokens to reentrancy, these bugs are wild. This concludes 3 bugs in Aave that required very obscure scenarios in order to exploit.