The offerId
global variable is used in both the CreateOffer
and createTaker
functions to generate unique addresses and assign IDs to offerInfoMap
and stockInfoMap
. However, due to the incorrect sequencing of operations, both an offer and its corresponding taker may end up sharing the same offerId
, leading to duplicate IDs and potential conflicts within the system.
The offerId
variable is used to generate unique addresses for makerAddr
, offerAddr
, and stockAddr
in the CreateOffer
function. After generating these addresses, the offerId
is incremented by 1 and stored as the ID in offerInfoMap[offerAddr].id and stockInfoMap[stockAddr].id.
However, in the createTaker
function, the offerId
is used before being incremented, which results in the same offerId
being assigned to both the stock associated with the offer and the stock associated with the taker
This creates a scenario where the stockInfoMap for both the offer and the taker have the same ID, which can lead to conflicts and mismanagement within the protocol.
Same id to different stocks.
Manual Code Review
The offerId
should be incremented before or after it is assigned in both the createOffer
and createTaker
functions.
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.