The vulnerability lies in the Distribution.sol:manageUsersInPrivatePool
function, where a race condition can occur if a user's deposited amount is equal to the amount specified in the function call, Then the user is unable to deposit into the private pool due to a conflict in the state of their deposited amount.
When a user's deposited amount is exactly equal to the amount specified in the Distribution.sol:manageUsersInPrivatePool
function call, a race condition arises.
If another transaction, such as a Distribution.sol:_stake
or Distribution.sol:_withdraw
, modifies the user's deposited amount between the time the Distribution.sol:manageUsersInPrivatePool
function is called and the loop iterates over the users, the function may behave unexpectedly.
Specifically, if the deposited amount changes to be less than the specified amount due to another transaction, the function may incorrectly attempt to withdraw funds from the user's account, potentially resulting in a loss of funds or DoS for the user.
when this situation arises, there can be scenario when user wants to deposit but they end up withdrawing there funds and vice versa.
Manual code review
Use mutex locks or other synchronization mechanisms to prevent concurrent access to shared resources.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.