When the owner of an offer calls PreMarkets::createOffer
, the offerId
is used to generate addresses for the maker, offer, and stock. However, the offerId
is incremented before updating the offerInfoMap
and stockInfoMap
, leading to the association of incorrect data with the offerId
.
In the PreMarkets::createOffer
function, the offerId
is used to generate addresses through the GenerateAddress
library. However, the offerId
is incremented before the offer and stock information is assigned to the respective maps (offerInfoMap
and stockInfoMap
). This results in the assignment of these data structures to the wrong offerId
, causing data inconsistencies:
The incorrect increment of offerId
results in the assignment of wrong information to offerInfoMap
and stockInfoMap
, leading to potential data inconsistencies. This could cause issues in identifying and managing offers and stocks correctly within the protocol, possibly resulting in faulty transactions, mismanagement of assets, and difficulty in tracking offer data.
Manual Code Review
To resolve this issue, increment the offerId
before generating the addresses and performing checks, ensuring that the correct offerId
is used for updating the offerInfoMap
and stockInfoMap
:
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.