TID: Mystic BBS 1.12 A43   
   MSGID: 3:770/100 0b39533b   
   REPLY: 1485.fido-binkd@3:633/410 229768e2   
   TZUTC: 1300   
   On 30 Jan 2020 at 11:07a, Tony Langdon pondered and said...   
       
    TL>  DC> I've sent a pull request to fix it upstream.   
    TL>  DC> https://github.com/pgul/binkd/pull/16   
    TL>    
    TL> Hopefully I can get hold of the fixed source.  I've had to take a number   
    TL> of measures like restricting callouts to the affected node to IPv4 only,   
    TL> and also hardcoding the IPv4 IP in the node entry, because DNS lookups   
    TL> were also problematic for the affected node..   
      
   With luck, the upstream maintainer will address the pull request quickly,   
   either by applying my patches or coming up with another fix.  If you need   
   this quickly, however, you could clone my fork   
   (https://github.com/fat-dragon/binkd.git) and build from source.   
      
    TL> A second link running over ZeroTier started showing similar issues   
    TL> recently, but switching that link to connect directly across the open   
    TL> Internet was enough to get that link working.   
    TL>    
    TL> It's odd that it only affects some links.     
      
   The code path with the use-after-free was dependent on the source of   
   the information.  If you used the default port, the pointer in question   
   would end up pointing to memory that wasn't free()'d; if you used a   
   non-standard port in your configuration file (e.g., `agency.bbs.bz:24556`),   
   you'd tickle the bug; hence why it doesn't show up everyhwere.   
      
    TL> My system is a fairly busy Pi that's running 2 BBSs, which may explain   
    TL> why malloc() is being a bit aggressive. :)   
      
   A memory-intensive workload will likely put pressure on the operating   
   system's virtual memory subsystem (note, VM in the general sense, not   
   specific to e.g. swap space), but is unlikely to significantly affect   
   malloc().  While some malloc() implementations do go to pains to work   
   with the VM system to return memory to the OS under pressure, this is   
   necessarily on a page boundary and it's likely other short strings had   
   been allocated on that same page (at least, this was what I observed   
   on my system).   
      
   Rather the aggressiveness I mentioned with respect to free()'d memory   
   has to do with the malloc() implementation writing garbage into the   
   free()'d region of memory, precisely to detect these sorts of   
   use-after-free issues.   
      
   --- Mystic BBS v1.12 A43 2019/03/03 (Windows/32)   
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)   
   SEEN-BY: 1/123 57/0 90/1 103/705 153/250 154/10 203/0 220/70 221/0   
   SEEN-BY: 227/114 229/101 200 426 1014 240/5832 249/307 317 267/800   
   SEEN-BY: 280/464 5003 5555 288/100 292/854 310/31 317/3 340/1000 342/200   
   SEEN-BY: 396/45 423/120 712/848 770/0 1 100 340 772/0 1 210 500 2452/250   
   PATH: 770/100 1 280/464 229/426