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.

diff --git a/crypto/evp/encode.c b/crypto/evp/encode.c
index 14a4cb11f6c77bbee4e948dcbe83820091046d84..6ff9c1783cf60720ee60a29298746ec5e0427356 100644 (file)
--- 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))
                        {