summaryrefslogtreecommitdiffstats
path: root/crypto/err
diff options
context:
space:
mode:
authorMatt Caswell <matt@openssl.org>2016-10-12 16:43:03 +0100
committerMatt Caswell <matt@openssl.org>2016-10-15 11:34:23 +0100
commit02a02319ea6cde904e4bfa3a05fe128fd9b6675c (patch)
tree08c02d0bfba8910ced5a1c712263d2ba5c242a06 /crypto/err
parent6d69dc56de8f0535be9ccabea7a8d4e61c04c2f1 (diff)
Ensure we handle len == 0 in ERR_err_string_n
If len == 0 in a call to ERR_error_string_n() then we can read beyond the end of the buffer. Really applications should not be calling this function with len == 0, but we shouldn't be letting it through either! Thanks to Agostino Sarubbo for reporting this issue. Agostino's blog on this issue is available here: https://blogs.gentoo.org/ago/2016/10/14/openssl-libcrypto-stack-based-buffer-overflow-in-err_error_string_n-err-c/ Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit e5c1361580d8de79682958b04a5f0d262e680f8b)
Diffstat (limited to 'crypto/err')
-rw-r--r--crypto/err/err.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/crypto/err/err.c b/crypto/err/err.c
index e77d963b6b..52dc9a5ddd 100644
--- a/crypto/err/err.c
+++ b/crypto/err/err.c
@@ -868,6 +868,9 @@ void ERR_error_string_n(unsigned long e, char *buf, size_t len)
const char *ls, *fs, *rs;
unsigned long l, f, r;
+ if (len == 0)
+ return;
+
l = ERR_GET_LIB(e);
f = ERR_GET_FUNC(e);
r = ERR_GET_REASON(e);