The PreMarktes
contract implements a marketplace system where users can create offers and take existing offers. Two key functions, createOffer()
and createTaker()
, are responsible for these operations. Both functions utilize a shared offerId
variable to generate unique addresses for offers, makers, and stocks.
The core issue lies in the incrementation of offerId
in both functions.
In createOffer()
, offerId
is used to generate addresses for the maker, offer, and stock, and then incremented. Similarly, in createTaker()
, offerId
is used to generate a stock address and then incremented again. This dual incrementation creates a race condition where the same offerId
could be used to generate addresses in both functions, potentially leading to address collisions.
The GenerateAddress
library uses offerId
to deterministically generate addresses:
If these generated addresses collide with existing entries in makerInfoMap
, offerInfoMap
, or stockInfoMap
, the transaction will revert with errors such as MakerAlreadyExist
, OfferAlreadyExist
, or StockAlreadyExist
.
This issue allows malicious actors to manipulate the timing of their transactions to cause intentional address collisions, effectively denying service to legitimate users.
The impact of this vulnerability is severe. It can lead to a denial of service for legitimate users trying to create offers or take existing ones. Malicious actors can exploit this issue to disrupt the normal functioning of the marketplace, potentially causing financial losses and eroding user trust in the platform.
User A calls createOffer
:
offerId
is used to generate addresses for the maker, offer, and stock.
offerId
is incremented.
User B calls createTaker
:
The same offerId
is used to generate a stock address.
offerId
is incremented again.
If the generated addresses collide with existing entries in makerInfoMap
, offerInfoMap
, or stockInfoMap
, the transaction will revert with errors such as MakerAlreadyExist
, OfferAlreadyExist
, or StockAlreadyExist
.
Manual review
To fix this issue, ensure that offerId
is incremented only in createOffer
. Remove the incrementation of offerId
in createTaker
to prevent address collisions and logical errors.
I believe this is valid low severity, although there is inconsistency here when using the correct `offerId` for assigning offerIds and generating the unique addresses as seen [here](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/PreMarkets.sol#L67-L69), this is purely an accounting error for offerIds. If we generate the offerId using current `offerId - 1`, the appropriate listing/taker orders can still be created against those offers.
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.