Incorrect offerId
set in info mappings leads DoS or overwriting other users offers
The protocol offers the ability for users to create bid-ask trades. When a user creates a new offer 3 mappings are used to store data about the offer and the stock. The mappings have an address as a key. This address is generated for a string and a uint256 offerId
which is stored in the PreMarkets
contract and incremented every time a new offer is made.
If we take a look at the PreMarkets::createOffer
function it uses offerId
to generate the maker offer and stock addresses. Then it is incremented and finally the objects are saved in the mappings with the newly incremented offerId
which is a problem.
It is a problem because if we take a look at listOffer
it uses the stockInfo.id to generate na new offer address and checks if it is in use by checking the offer info authority against address(0)
. Finally it creates a new offer with the same id. This condition would revert every single time, when there is an offer created after the current one.
Add the following test to PreMarkets.t.sol
and run with forge test -vvv --mt test_wrong_id_set
DoS
Manual Review
Increment the offer id after the info mappings are created
Note that after fixing this bug listOffer
would also have to be fixed because the offer authority would be the original offer authority. Hence you could just modify listOffer
by
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.