Dria

Summary

The issue lies in the lack of checking round during a purchase.

Vulnerability Details

Assume asset A is listed to Bob at round 1. Now at round 3, bob can purchase the same asset by using the following steps:

1. Bob calls the oraclePurchaseRequestfunction, and the oracle responds with the asset listed at round 1

   function oraclePurchaseRequest(bytes calldata _input, bytes calldata _models) external onlyAuthorized {

   // check that we are in the Buy phase, and return round

   (uint256 round,) = _checkRoundPhase(Phase.Buy);

   ​

   oraclePurchaseRequests[round] =

   swan.coordinator().request(SwanBuyerPurchaseOracleProtocol, _input, _models, swan.getOracleParameters());

   }Impact

2. Now bob calls the purchasefunction to purchase the asset. Note the roundis not checked anywher to ensure that an old asset is not being bought(Only the phase is being checked):

   function purchase() external onlyAuthorized {

   // check that we are in the Buy phase, and return round

   (uint256 round,) = \_checkRoundPhase(Phase.Buy);

   ​

   // check if the task is already processed

   uint256 taskId = oraclePurchaseRequests[round];

   if (isOracleRequestProcessed[taskId]) {

   revert TaskAlreadyProcessed();

   }

   ​

   // read oracle result using the latest task id for this round

   bytes memory output = oracleResult(taskId);

   address[] memory assets = abi.decode(output, (address[]));

   ​

   // rest of the code

Note that using this method, Bob could frontrun the relisting of an asset, thus blocking the seller from relisting.

Tools Used

Manual

Recommendations

Make sure that the asset is listed in the same round as the buyer currently is in.