summaryrefslogtreecommitdiff
path: root/src/lib/libc
diff options
context:
space:
mode:
authorderaadt <>2014-04-20 10:31:43 +0000
committerderaadt <>2014-04-20 10:31:43 +0000
commitba5ffe465c7b412a5c5361b3ef1897cccc0543a3 (patch)
treef70f0a2c839fe80bfe832a19ebee0988da0b5261 /src/lib/libc
parentccee83a0cbb25cd47e7c93283f5331f21e4fe078 (diff)
downloadopenbsd-ba5ffe465c7b412a5c5361b3ef1897cccc0543a3.tar.gz
openbsd-ba5ffe465c7b412a5c5361b3ef1897cccc0543a3.tar.bz2
openbsd-ba5ffe465c7b412a5c5361b3ef1897cccc0543a3.zip
Use calloc(a,b) instead of malloc(a*b) + memset(a*b). I don't know if
this instance is integer-overflowable, but we cannot keep hand-auditing every instance (or apathetically ignoring these issues) when the simple calloc idiom is better in the presence of a good calloc(). It is simply unfeasible to always enter correct range checks before the aggregate size calculation, just go find some 4000 lines of code, REPAIR THEM ALL, then come back and tell me I am wrong. This only works on systems where calloc() does the integer overflow check, but if your system doesn't do this, you need to ask your vendor WHY THEY ARE 10 YEARS BEHIND IN BEST PRACTICE? This is the kind of problem that needs to be solved at the right layer. malloc integer-overflow was implicated in the 2002 OpenSSH hole. OpenSSH and much other code is now written to use calloc(), for instance OpenSSH has 103 calls to it. We feel safer with our use of calloc(). It is a natural approach for us to use calloc(). How safe do you feel on systems which lack that range check in their calloc()? Good writeup from 2006: http://undeadly.org/cgi?action=article&sid=20060330071917
Diffstat (limited to 'src/lib/libc')
0 files changed, 0 insertions, 0 deletions