# Risk of DoS when stoping large rental orders due to block gas limit

reNFT Create::validateOrder lacks a cap on offers, so a huge rental order can be created but Stop::stopRent exceeds the block gas limit, permanently locking escrowed NFTs.

- Payout: Contest reward
- Severity: medium
- Program: reNFT
- Credited: plasmablocks
- Disclosed: 2024-03-20
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-01-renft-findings/issues/538
- Library page: https://bugbountylibrary.com/r/c4%3A2024-01-renft%3AM-03
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:fuzzing vuln:dos

**Target:** Seaport zone policy Create::validateOrder / Stop::stopRent rental escrow
**Root cause:** Create::validateOrder enforces no maximum on the number of SpentItem offers in ZoneParameters, allowing arbitrarily large ERC-721/ERC-1155 rental orders whose stopRent loop exceeds the block gas limit.
**Steps:**
1. Deploy with 2000+ ERC-721/1155 tokens in AccountCreator setup.
2. createOrder with numOf721 and numof1155 bound to 1500+ offers.
3. finalizeOrder and createOrderFulfillment, then finalizeBaseOrderFulfillment to enter rental state.
4. vm.warp past expiration and call stop.stopRent(rentalOrderOne).
5. Measure gasForStopingRent and compare against GAS_LIMIT = 30,000,000; stopRent exceeds it while creation succeeded.
**How found:** Reasoned that validateOrder has no offer-count cap, then fuzzed gas of create vs stopRent to show stopRent is more expensive and can exceed the 30M block gas limit.
**Exploitation:** Attacker creates a rental order with thousands of ERC-721/1155 offers; creation fits in a block but stopRent iterates all items and exceeds the block gas limit, so the order can never be settled and escrowed tokens are stuck.
**Insight:** When a create path and a settle/stop path iterate the same unbounded array, compare their gas costs and check whether the settle path can exceed the block gas limit even though creation succeeded.