In the DeliveryPlace.settleAskMaker function, it does not check the offer is makerInfo.originOffer and it refunds the collateral for settled points.
Thus, in Turbo mode, settling listed ask offer which is not makerInfo.originOffer also refunds collateral.
In Turbo mode, listing ask offer does not require collateral.
As a result, not provided collateral are refunded and this causes the protocol's loss of funds.
In the DeliveryPlace.settleAskMaker function, collateral for settled points are refunded from L301.
In Turbo mode, collaterals are provided only for makerInfo.originOffer, not for listed offer whith is not makerInfo.originOffer.
Let's assume that makerInfo.offerSettleType is Turbo and user tries to settle the listed ask offer.
If offer.authority tries to settle the offer, the DeliveryPlace.settleAskMaker function refunds the collateral which is not provided by authority.
This causes the protocol's loss of funds.
Manual Review
It is recommended to change the code as following:
Valid high severity, this allows resellers listing offers via `listOffer/relistOffer` to game the system. Based on the inherent design of Turbo mode not requiring takers making ask offers for the original maker offer to deposit collateral, the wrong refund of collateral to takers even when they did not deposit collateral due to turbo mode during settleAskMaker allows possible draining of pools.
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.