summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRichard Levitte <levitte@openssl.org>2000-08-11 08:36:25 +0000
committerRichard Levitte <levitte@openssl.org>2000-08-11 08:36:25 +0000
commit35140f335461c6d03d08247e29a93794e4f96f86 (patch)
treebd4d5dc8efbfd91a20a82add66287608b424e880
parent15c2e1260bb735575f93bfbf051908f51e21e6b3 (diff)
Abdelilah Essiari <aes@george.lbl.gov> reports that for very small
records, EVP_EncodeUpdate() may misbehave. This happens when there's a record boundary between the two ending b64 equal signs, which makes EVP_EncodeUpdate think there has been more than one EOF, and therefore add an extra NUL at the end of the output buffer. This fix corrects that problem.
-rw-r--r--crypto/evp/encode.c10
1 files changed, 10 insertions, 0 deletions
diff --git a/crypto/evp/encode.c b/crypto/evp/encode.c
index 14a4cb11f6..6ff9c1783c 100644
--- a/crypto/evp/encode.c
+++ b/crypto/evp/encode.c
@@ -292,7 +292,17 @@ int EVP_DecodeUpdate(EVP_ENCODE_CTX *ctx, unsigned char *out, int *outl,
/* If we are at the end of input and it looks like a
* line, process it. */
if (((i+1) == inl) && (((n&3) == 0) || eof))
+ {
v=B64_EOF;
+ /* In case things were given us in really small
+ records (so two '=' were given in separate
+ updates), eof may contain the incorrect number
+ of ending bytes to skip, so let's redo the count */
+ eof = 0;
+ if (d[n-1] == '=') eof++;
+ if (d[n-2] == '=') eof++;
+ /* There will never be more than two '=' */
+ }
if ((v == B64_EOF) || (n >= 64))
{