Skip to content

mitigate potential DoS vector by limiting pending piece uploads

Previously there was no explicit limit on the number of piece requests a peer could have outstanding. Each such request can potentially consume memory up to the piece size of the torrent. Worse, since there is no check for redundant requests, it was trivial for a peer to cause us to consume unbounded amounts of memory by sending a long run of requests for oversized pieces. (N.B.: Other implementations disconnect peers for requesting more than 128 KiB at a time, but KTorrent allows any requested size up to the piece size.)

This commit implements limits on the number of piece block uploads a peer may have pending at any one time and on the total byte count of those uploads. The limits are 512 uploads and 8 MiB of piece data. Any requests received in excess of those limits are rejected. Note that popular BitTorrent client implementations do not queue more than a handful of piece requests at any one time, so these new limits are expected to be proactively defensive only. That said, the author has repeatedly observed KTorrent consuming over half a gigabyte of RAM in queued PIECE messages waiting to be transmitted. The new limits are intended to alleviate this pain.

Without patch (peak ~590 MiB in ~2 days)

heaptrack_ktorrent_before

With patch (peak ~88 MiB in ~21 days)

heaptrack_ktorrent_after

Merge request reports