Most Linux distros offer an installation iso via torrent, large files with many blocks. If you can change just a small part of those files, you’ve got compromised machines before the install even begins.
(That is, we've got practical collision attacks emerging for SHA1, not pre-image attacks).
1. The user trusts the source of the .torrent file.
2. A malicious peer makes a preimage attack in some block in an executable file with contents containing some malicious executable payload.
3. The executable wasn't signed, or the targeted block must include executable headers.
4. Some peers get the malicious exe, some don't.
The (2) step is still hard — preimage attacks on SHA1 are still expensive.
And it is probably much easier to bypass SHA1/SHA256 entirely by just uploading a malicious torrent directly and hoping (1) still applies.
Even MD5, for which you can generate colliding blocks in seconds on an average PC, is still quite resistant to preimage attacks.
In other words, even after spending the resources to find a colliding block, you'd also need to create both files with the same hash, and can't simply collide existing torrents' files and replace them with malicious ones.
Since there's some control over the original hash value, executing step (4) is not exactly a preimage attack, it should be a bit easier.
So if you get your hash from whoever made the original binary, you can know that any binary with a matching hash is fine. But it could be a problem if someone creates a new pair of binaries and uploads the hash to TPB. You might see lots of good reviews from people who got the innocent version, but then the peers you connect to send you a malicious version with a matching hash.
So your scenario becomes an issue if you're downloading executable data that you deem :trusted: without any additional verification besides the hash itself. If that's the case, you have bigger worries than the hash.