[PATCH] Allow emails with boundaries to work again

[PATCH] Allow emails with boundaries to work again

[Don Zickus]

Recent changes to is_multipart_boundary() caused git-mailinfo to segfault.
The reason was after handling the end of the boundary the code tried to look
for another boundary.  Because the boundary list was empty, dereferencing
the pointer to the top of the boundary caused the program to go boom.

The fix is to check to see if the list is empty and if so go on its merry
way instead of looking for another boundary.

I also fixed a couple of increments and decrements that didn't look correct
relating to content_top.

Signed-Off-by: Don Zickus <dzickus@redhat.com>
---
 builtin-mailinfo.c |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 6ae2bf3..0209e82 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -175,7 +175,7 @@ static void handle_content_type(struct strbuf *line)
 		 message_type = TYPE_OTHER;
 	if (slurp_attr(line->buf, "boundary=", boundary)) {
 		strbuf_insert(boundary, 0, "--", 2);
-		if (content_top++ >= &content[MAX_BOUNDARIES]) {
+		if (++content_top > &content[MAX_BOUNDARIES]) {
 			fprintf(stderr, "Too many boundaries to handle\n");
 			exit(1);
 		}
@@ -626,7 +626,7 @@ again:
 		/* technically won't happen as is_multipart_boundary()
 		   will fail first.  But just in case..
 		 */
-		if (content_top-- < content) {
+		if (--content_top < content) {
 			fprintf(stderr, "Detected mismatched boundaries, "
 					"can't recover\n");
 			exit(1);
@@ -635,9 +635,11 @@ again:
 		strbuf_release(&newline);
 
 		/* skip to the next boundary */
-		if (!find_boundary())
-			return 0;
-		goto again;
+		if (*content_top) {
+			if (!find_boundary())
+				return 0;
+			goto again;
+		}
 	}
 
 	/* set some defaults */
-- 
1.5.5.1

Re: [PATCH] Allow emails with boundaries to work again

[Junio C Hamano]

Don Zickus <dzickus@redhat.com> writes:

> Recent changes to is_multipart_boundary() caused git-mailinfo to segfault.
> The reason was after handling the end of the boundary the code tried to look
> for another boundary.  Because the boundary list was empty, dereferencing
> the pointer to the top of the boundary caused the program to go boom.

We keep fixing and breaking this thing, don't we?  Can we have a testcase
to protect this codepath?

Re: [PATCH] Allow emails with boundaries to work again

[Don Zickus]

On Wed, Aug 13, 2008 at 04:45:06PM -0700, Junio C Hamano wrote:
> Don Zickus <dzickus@redhat.com> writes:
> 
> > Recent changes to is_multipart_boundary() caused git-mailinfo to segfault.
> > The reason was after handling the end of the boundary the code tried to look
> > for another boundary.  Because the boundary list was empty, dereferencing
> > the pointer to the top of the boundary caused the program to go boom.
> 
> We keep fixing and breaking this thing, don't we?  Can we have a testcase
> to protect this codepath?

Heh.  Ok I will try to work on one for tomorrow.

Cheers,
Don

Re: [PATCH] Allow emails with boundaries to work again

[Junio C Hamano]

Don Zickus <dzickus@redhat.com> writes:

> Recent changes to is_multipart_boundary() caused git-mailinfo to segfault.
> The reason was after handling the end of the boundary the code tried to look
> for another boundary.  Because the boundary list was empty, dereferencing
> the pointer to the top of the boundary caused the program to go boom.
>
> The fix is to check to see if the list is empty and if so go on its merry
> way instead of looking for another boundary.

Hmm, at this point !*content_top means that we are at the outermost level
and we have just seen --boundary-- which is the terminating one, haven't
we?  Shouldn't we be simply returning?

Re: [PATCH] Allow emails with boundaries to work again

[Don Zickus]

On Wed, Aug 13, 2008 at 06:36:53PM -0700, Junio C Hamano wrote:
> Don Zickus <dzickus@redhat.com> writes:
> 
> > Recent changes to is_multipart_boundary() caused git-mailinfo to segfault.
> > The reason was after handling the end of the boundary the code tried to look
> > for another boundary.  Because the boundary list was empty, dereferencing
> > the pointer to the top of the boundary caused the program to go boom.
> >
> > The fix is to check to see if the list is empty and if so go on its merry
> > way instead of looking for another boundary.
> 
> Hmm, at this point !*content_top means that we are at the outermost level
> and we have just seen --boundary-- which is the terminating one, haven't
> we?  Shouldn't we be simply returning?

That's what I originally did, but then I realized the rest of the
handle_boundary() reads the next line of text, which is needed to continue
processing in handle_body().  :-)

Cheers,
Don