Filecoin is a decentralized p2p network allowing users to store and retrieve files on the Internet. Users (data owners) pay to store their files with storage providers (computers that store files). Filecoin does this using a blockchain to record all of the information but using IPF under the hood.
A deal is a contract between the user who owns the data and the data provider agreeing to store the information for them. In Proposal.StartEpoch, the function checks to ensure that a proposed deal hasn't already elasped a certain time frame. This is to ensure there's enough time to perform the operation.
In AddPiece(), the code is ran by the miner every 5 minutes until 6 hours has been reached.
The deal's start epoch (group of blocks) is checked against the current epoch + a sealing buffer (480 epochs). For a deal to be created, accepted and closed takes time. An attacker can create a deal in which the start epoch is closed to the current epoch, which will pass verification. However, after the deal is published but before it's added, the epoch will grow larger than the specified start epoch.
This is exploiting the weird boundary on times between various actions. One item doesn't use the StartEpochSealingBuffer into consideration while the other one does. By doing this, AddedPiece() will always fail! This loses gas for the Service Provider. Additionally, this could lead to a denial of service if the collaterals reach their limits.
Race condition vulnerabilities are commonly hard to find/understand but can show a fundamental weakness in the software design. Concurrency is nearly impossible to get 100% correct. Good write up but I do wish there was a little more background since I had no idea what Filecoin was prior to reading this.