Subj : Re: binkd error
To   : Tony Langdon
From : Dan Cross
Date : Thu Jan 30 2020 03:55 pm

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)

.