The createOffer
function in the PreMarkets contracts is registering wrong ID data in the offerInfoMap
and the stockInfoMap
this would mess up the data in the struct by always registering a different ID of which was used to calculate the address of these structs, and will duplicate the ID registered in different offerInfoMap
and the stockInfoMap
structs.
When a user creates an offer to sell/buy points the createOffer
function is called, this function uses the variable offerId
to count the number of orders that have been created in the market and differentiate the orders by creating unique addresses for the offerInfoMap
, stockInfoMap
and the makerInfoMap
structs based on the offerId
variable.
then, it validates these addresses don't exist already
and later, these addresses are used to register all the data these structs need for the system to work as expected, as you can see below, one other data needed is the ID for the offerInfoMap
and the stockInfoMap
structs, which should register the offerId
value used to calculate the addresses, but this offerId
variable is being increased in the previous step, so the offerId
value register at this point is wrong because it will point to an existing offerId
at the moment.
I created a basic test and added some console logs to the CreateOffer, CreatTaker and listOffer
functions to show that the ID registered in this function is wrong, duplicated, and some IDs are skipped.
This is the result of the test:
The offerInfoMap
and the stockInfoMap
structs are saving the wrong ID, this will duplicate IDs in different orders and skip some IDs.
Manual Review
Update the offerId
variable after it is assigned in the creation of the offerInfoMap
and the stockInfoMap
structs, like. you do in the createTaker
function.
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.