Double-free bug on huge bandwidth file in some platforms
Here is a very situational double-free bug reported in hackerone from bug hunter paldium. It's a low-severity item since bandwidth files are considered trusted input, and anyone who controls a bandwidth file can cause worse disasters than double-frees. Also it only applies on very specific platforms that none of our dirauths use.
Details: The function compat_getdelim_ is used for tor_getline if tor is compiled on a system that lacks getline and getdelim. These systems should be very rare, considering that getdelim is POSIX. If this system is further a 32 bit architecture, it is possible to trigger a double free with huge files. If bufsiz has been already increased to 2 GB, the next chunk would be 4 GB in size, which wraps around to 0 due to 32 bit limitations. A realloc(*buf, 0) could be imagined as "free(*buf); return malloc(0);" which therefore could return NULL. The code in question considers that an error, but will keep the value of *buf pointing to already freed memory. The caller of tor_getline() would free the pointer again, therefore leading to a double free. This code can only be triggered in dirserv_read_measured_bandwidths with a huge measured bandwith list file on a system that actually allows to reach 2 GB of space through realloc. It is not possible to trigger this on Linux with glibc or other major *BSD systems even on unit tests, because these systems cannot reach so much memory due to memory fragmentation. This patch is effectively based on the penetration test report of cure53 for curl available at https://cure53.de/pentest-report_curl.pdf and explained under section "CRL-01-007 Double-free in aprintf() via unsafe size_t multiplication (Medium)". ## Impact Successfully triggering a double free can corrupt the heap which might allow more sophisticated attacks within the tor application.