Detailed description of the impact of this finding.
The auctionDemo.auctionInfoData map holds important info on auctions, and hold this info per tokenId. Needless to say, for many auctions that may become popular and/or long running, the auctionInfoStru[] array for a given _tokenid can get very large.
mapping (uint256 => auctionInfoStru[]) public auctionInfoData;
There are several methods in this contract involve core logic that loops through the whole auctionInfoStru[] array for a tokenId. If this array is sufficiently large enough, then the transaction that called any of the methods that directly invoke or indirectly rely on this looping logic can easily run out of gas and thus fail. In order to retry again and have the transaction success, it might require a huge amount of gas which can be very expensive.
The following function directly invoke or indirectly rely on looping through auctionInfoData[_tokenid], where _tokenid is any given token being auctioned, which could very easily have potentially large length, enough so for a tx to run out of gas:
This is essentially all the major functions of the NextGen auction functionality.
Some more details on the issues:
Solidity
Pull model over push model -> Require Winners seeking their rightful prize and losers seeking refund to manually refund themselves; this can easily be implemented with a map lookup instead of large for loops.
DoS
The text was updated successfully, but these errors were encountered:
All reactions