# DoS: claimForAllWindows() May Be Made Unusable By An Attacker

Splitter.claimForAllWindows loops over an ever-growing currentWindow, so an attacker can inflate it via incrementWindow until claims exceed the block gas limit.

- Payout: Audit contest
- Severity: high
- Program: Joyn
- Found by: kirk-baird
- Disclosed: 2022-07-25
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-03-joyn-findings/issues/6
- Library page: https://bugbountylibrary.com/r/c4%3A2022-03-joyn%3AH-03
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:access-control vuln:dos

**Target:** Splitter royalty-claim contract (claimForAllWindows/incrementWindow)
**Root cause:** claimForAllWindows iterates over all windows 0..currentWindow, and currentWindow only ever increments (naturally or via attacker-triggered incrementWindow), so the loop cost eventually exceeds the block gas limit.
**Steps:**
1. Deploy a contract implementing IRoyaltyVault: supportsInterface(IID_IROYALTY) returns true and getSplitter() returns the Splitter address.
2. Send 1 wei of WETH to the Splitter so wethBalance >= royaltyAmount passes.
3. Repeatedly call `Splitter.incrementWindow(1)` from the impersonating contract to push balanceForWindow and bump currentWindow.
4. Once currentWindow is large enough, `claimForAllWindows()` reverts out-of-gas for all users.
**How found:** Code reading of claimForAllWindows' unbounded for-loop over currentWindow combined with noticing incrementWindow's authorization relies only on self-declared interface/getSplitter checks, making the counter attacker-inflatable.
**Exploitation:** Attacker impersonates a RoyaltyVault (interface + getSplitter checks are trivially satisfiable) and repeatedly calls incrementWindow with royaltyAmount=1 wei, growing currentWindow until the claim loop can no longer fit in a block, denying all royalty claims.
**Insight:** When a claim/settlement function loops over a monotonically increasing counter, check who can increment that counter and whether the increment path is authenticated by anything more than a self-declared interface; unbounded loops over attacker-growable state are a DoS.