issues
search
sherlock-audit
/
2023-09-perennial-judging
0
stars
0
forks
source link
issues
Newest
Newest
Most commented
Recently updated
Oldest
Least commented
Least recently updated
[Post-Contest] Incorrect boolean logic in Order.liquidityCheckApplicable()
#62
kbrizzle
closed
11 months ago
2
[Post-Contest] `MultiInvoker._executeOrder` uses current position unadjusted which can lead to incorrect order executions during invalid oracle versions
#61
panprog
closed
11 months ago
2
[Post-Contest] `MultiInvoker._liquidate` doesn't adjust current position leading to liquidation revert if invalid oracle version happens
#60
panprog
closed
11 months ago
2
[Perennial Self Review] Incorrect price used during liquidation calculation
#59
arjun-io
opened
11 months ago
3
JP_Courses - PAccumulator6::accumulate() - struct PAccumulator6's storage variables not updated in accumulate() function.
#58
sherlock-admin
closed
11 months ago
2
Topmark - Return of Wrong Oracle version due to Error in validating Timestamp
#57
sherlock-admin2
closed
11 months ago
1
feelereth - The convertToShares and convertToAssets functions are vulnerable to manipulation of the total shares and assets values.
#56
sherlock-admin
closed
11 months ago
1
panprog - Invalid oracle version can cause the vault to open too large and risky position and get liquidated due to using unadjusted global current position
#55
sherlock-admin2
opened
11 months ago
2
feelereth - The _closablePosition calculation is vulnerable to manipulation of pending positions by an attacker.
#54
sherlock-admin
closed
11 months ago
1
feelereth - _socialize() function is vulnerable to being gamed by attackers
#53
sherlock-admin2
closed
11 months ago
1
feelereth - The _socialize() function can penalize users who did not cause losses in the vault
#52
sherlock-admin
closed
11 months ago
1
feelereth - Assets that are locked in the vault are still included in the totalAssets calculation, which can make the conversions between assets and shares inaccurate
#51
sherlock-admin2
closed
11 months ago
1
feelereth - It assumes totalAssets and totalShares cannot be 0. This could happen if the contract is just initialized.
#50
sherlock-admin
closed
11 months ago
1
feelereth - It concludes the ratio between assets and shares is constant. But if assets or shares change between checkpoints, the conversion ratio would be stale
#49
sherlock-admin2
closed
11 months ago
1
feelereth - The market collateral could include "trapped" collateral that can't actually be withdrawn.
#48
sherlock-admin
closed
11 months ago
1
feelereth - Collateral values from different markets are denominated in the same units, which can lead to issues summing them.
#47
sherlock-admin2
closed
11 months ago
1
feelereth - Vulnerability where an attacker could manipulate the _mappings storage to make it appear that the next global checkpoint is ready when it actually is not.
#46
sherlock-admin
closed
11 months ago
1
panprog - MultiInvoker liquidation action will revert due to incorrect closable amount calculation for invalid oracle versions
#45
sherlock-admin2
opened
11 months ago
3
panprog - MultiInvoker liquidation action will revert most of the time due to incorrect closable amount initialization
#44
sherlock-admin
opened
11 months ago
4
feelereth - Updating positions before transferring fees means fees could be lost if transfer reverts.
#43
sherlock-admin2
closed
11 months ago
1
feelereth - If batcher is address(0), it should revert instead of relying on the reserve as a fallback. Relying on an untrusted reserve could be dangerous.
#42
sherlock-admin
closed
11 months ago
1
feelereth - The _wrap() function in MultiInvoker.sol allows specifying a different receiver address than the original depositor. This could lead to potential confusion about where the wrapped DSU ends up.
#41
sherlock-admin2
closed
11 months ago
1
feelereth - Doesn't validate account is actually undercollateralized before liquidating. Price could fluctuate between checks.
#40
sherlock-admin
closed
11 months ago
1
tvdung94 - closableAmount could go below zero, causing revert when loading pending positions
#39
sherlock-admin2
closed
11 months ago
1
feelereth - Basing fees on the current pending position magnitude instead of the amount being closed can lead to incorrect fee calculations
#38
sherlock-admin
closed
11 months ago
1
feelereth - The current liquidation logic in _liquidate subtracts the full closable amount uniformly from each position side (long, short, maker). This means it could liquidate more from one side than necessary if only one side is insolvent.
#37
sherlock-admin2
closed
11 months ago
1
tvdung94 - Oracle fee might be stuck in oracle factory contract
#36
sherlock-admin
closed
11 months ago
2
feelereth - The provided code has an issue where it assumes the entire position is liquidatable, when only a portion may be closable.
#35
sherlock-admin2
closed
11 months ago
1
feelereth - The current implementation could potentially put the user in a failed state if the vault update reverts after assets have already been pulled from the user
#34
sherlock-admin
closed
11 months ago
1
feelereth - Invalid assumption that the amount of assets claimed from the vault will equal the change in the msg.sender's DSU balance. This can lead to issues
#33
sherlock-admin2
closed
11 months ago
1
feelereth - Vulnerability with the collateral transfers happening outside of the market.update() call in the _update() function
#32
sherlock-admin
closed
11 months ago
1
tvdung94 - Using Vault#claimReward() might accidentally transfer all of vault's current asset to vault factory's owner.
#31
sherlock-admin2
closed
11 months ago
1
feelereth - If collateral > 0, it pulls from msg.sender into this contract, then deposits to market. On withdraw, it goes directly to msg.sender. This asymmetry can lead to confusion.
#30
sherlock-admin
closed
11 months ago
1
panprog - `Vault.update(anyUser,0,0,0)` can be called for free to increase `checkpoint.count` and pay smaller keeper fee than necessary
#29
sherlock-admin2
opened
11 months ago
5
twcctop - Protocol fee can still be locked
#28
sherlock-admin
closed
11 months ago
1
bin2chen - commitRequested() front-run malicious invalid oralce
#27
sherlock-admin2
opened
11 months ago
1
bin2chen - adjust() may underflow resulting in can't settle
#26
sherlock-admin
closed
11 months ago
1
0xVinylDavyl - Contract does not implement proper access control mechanisms for the validateAndStore function, there are no checks to restrict access to authorized users.
#25
sherlock-admin2
closed
11 months ago
1
0xVinylDavyl - bitwise left shift operations on slot0, slot1, and slot2 without explicit checks for arithmetic overflow. If the values in these slots exceed the expected bit length, it leads to unintended behavior
#24
sherlock-admin
closed
11 months ago
1
0xVinylDavyl - The code essential Risk Parameter lacks proper documentation in the form of inline comments and explanations
#23
sherlock-admin2
closed
11 months ago
1
0xVinylDavyl - Unpredictable behavior from no range Checks for Wrapped UFixed6 Values, If a UFixed6 value representing a percentage exceeds 100%, it leads to incorrect calculations, fees, or other critical parameters
#22
sherlock-admin
closed
11 months ago
1
Daniel_MetaTrust - Potential Lock Ether Forever
#21
sherlock-admin2
closed
11 months ago
1
0xVinylDavyl - With uint256 and int256 data types, Integer overflow and underflow occur when the result of an arithmetic operation exceeds the maximum or minimum representable value for a given data type.
#20
sherlock-admin
closed
11 months ago
1
0xVinylDavyl - Unexpected behavior from the _validateAndGetPrice function's failure to validate the oracleVersion and updateData inputs
#19
sherlock-admin2
closed
11 months ago
1
0xVinylDavyl - The contract calls pyth.parsePriceFeedUpdates with a value based on IPythStaticFee(address(pyth)).singleUpdateFeeInWei() * idList.length. If this value exceeds the block gas limit, the transaction will fail.
#18
sherlock-admin
closed
11 months ago
1
0xVinylDavyl - From the arithmetic operations in the _recordPrice function, specifically the variable expo6Decimal. If the value of expo6Decimal becomes extremely large or small, it could result in an integer overflow or underflow when performing operations on it.
#17
sherlock-admin2
closed
11 months ago
1
0xVinylDavyl - Potential Reentrancy Vulnerability concerned in the contract's fund function, which interacts with an external contract (market.claimFee()) without implementing a reentrancy guard. Potentially exposing the contract to reentrancy attacks
#16
sherlock-admin
closed
11 months ago
1
0xVinylDavyl - The absence of event emission in error cases can significantly impede the maintenance, debugging and monitoring process.
#15
sherlock-admin2
closed
11 months ago
1
0xVinylDavyl - The contract uses a constant gas buffer (`GAS_BUFFER`) set to 100,000, which may not be sufficient for complex operations, potentially leading to transaction failures or inconsistent states.
#14
sherlock-admin
closed
11 months ago
1
0xVinylDavyl - The code utilizes low-level calls in the `_commitPrice` function, In the context of this function, the contract's behavior depends on the success of this low-level call, which introduces potential risks.
#13
sherlock-admin2
closed
11 months ago
1
Next