StockInfo can be maliciously rewritten
While creating an Offer a state variable offerIdis used:
As you can see here it increment right before saving it in the OfferInfo and StockInfo structs. Remember it.
In createTake() the same variable is used:
Here you can see that offerId is incremented after the value is stored in the struct. Now consider the scenario:
Initially offerId is equal to 0;
User 1 creates an offer and it stores structs with the offerId equal to 1;
User 2 creates a Taker, it stores the value to StockInfo equal to 1;
Right after offerId is incremented again and now it equalt to 2.
This situation can cause problems when working with StockInfo slots in other protocol functions.
Users will interact with a damaged StockInfo structs.
Manual review
Consider incrementing offerId in the end of createOffer():
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.
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.