Harden dropbear memory allocator
Loganaden Velvindron
loganaden at gmail.com
Sun Apr 12 20:52:44 AWST 2015
On Sun, Apr 12, 2015 at 12:34 PM, Matt Johnston <matt at ucc.asn.au> wrote:
> Hi Logan,
>
> Thanks for looking at that - certainly something to be wary
> of. I've actually removed netio.c's malloc altogether a
> couple of weeks ago though had neglected to push it until
> now https://secure.ucc.asn.au/hg/dropbear/rev/cc6116cc0b5c
> (my github mirror isn't updated, the machine that does that is
> offline, should be back next week).
You're welcome !
>
> I think netio.c was OK because *ret_iov_count was limited to
> IOV_MAX which is 1024 or less on most platforms.
I was thinking about importing the m_reallocarray() wrapper into
dropbear. I think that it would be a useful API to have inside
dropbear for future use as well.
It has the advantage of a low overhead compared to calloc() as it
doesn't zero, and you have the integer overflow protection for free.
For example, in scpmisc.c,
There's also:
args->list = xrealloc(args->list, nalloc * sizeof(char *));
In OpenBSD, we have replaced those calls in OpenBSD by reallocarray(),
and there are around 800 instances: it ships in libressl, openssh,
opensmtpd, and many other userland software, such as nsd and unbound,
which have also imported a similar API into their memory wrappers.
//Logan
C-x-C-c
More information about the Dropbear
mailing list