git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "Juan F. Codagnone" <jcodagnone@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] mailinfo: avoid segfault when can't open files
Date: Tue, 23 Jan 2018 23:02:32 -0500	[thread overview]
Message-ID: <20180124040232.GB1330@sigill.intra.peff.net> (raw)
In-Reply-To: <20180124025417.32497-1-jcodagnone@gmail.com>

On Tue, Jan 23, 2018 at 11:54:17PM -0300, Juan F. Codagnone wrote:

> If <msg> or <patch> files can't be opened, clear_mailinfo crash as
> it follows NULL pointers.
> 
> Can be reproduced using `git mailinfo . .`

Thanks for finding this.

Looking at the offending code and your solution, it looks like:

  1. mailinfo() sometimes allocates mi->p_hdr_data and mi->s_hdr_data
     and sometimes not, depending on how far we get before seeing an
     error. The caller cannot know whether we did so or not based on
     seeing an error return, but most call clear_mailinfo() if it wants
     to avoid a leak.

  2. There are two callers of mailinfo(). git-am simply dies on an
     error, and so is unaffected. But git-mailinfo unconditionally calls
     clear_mailinfo() before returning, regardless of the return code.

  3. When we get to clear_mailinfo(), the arrays are either populated or
     are NULL. We know they're initialized to NULL because of
     setup_mailinfo(), which zeroes the whole struct.

So I think your fix does the right thing. I do think this is a pretty
awkward interface, and it would be less error-prone if either[1]:

  a. we bumped the allocation of these arrays up in mailinfo() so
     that they were simply always initialized. This fixes the bug in
     clear_mailinfo(), but also any other function which looks at the
     mailinfo struct (though I don't think there are any such cases).

  b. we had mailinfo() clean up after itself on error, so that it was
     always in a de-initialized state.

But given the lack of callers, it may not be worth the effort. So I'm OK
with this solution. It may be worth giving an abbreviated version of the
above explanation in the commit message. Perhaps:

  If <msg> or <patch> files can't be opened, then mailinfo() returns an
  error before it even initializes mi->p_hdr_data or mi->s_hdr_data.
  When cmd_mailinfo() then calls clear_mailinfo(), we dereference the
  NULL pointers trying to free their contents.

As for the patch itself, it looks correct but I saw two style nits:

> diff --git a/mailinfo.c b/mailinfo.c
> index a89db22ab..035abbbf5 100644
> --- a/mailinfo.c
> +++ b/mailinfo.c
> @@ -1167,11 +1167,13 @@ void clear_mailinfo(struct mailinfo *mi)
>  	strbuf_release(&mi->inbody_header_accum);
>  	free(mi->message_id);
>  
> -	for (i = 0; mi->p_hdr_data[i]; i++)
> -		strbuf_release(mi->p_hdr_data[i]);
> +	if(mi->p_hdr_data != NULL)
> +		for (i = 0; mi->p_hdr_data[i]; i++)
> +			strbuf_release(mi->p_hdr_data[i]);

We usually say "if (" with an extra space. And we generally just check
pointers for their truth value. So:

  if (mi->p_hdr_data) {
	for (i = 0; ...)

-Peff

[1] Actually, it seems a little funny that we use xcalloc() here at all,
    since the size is determined by a compile-time constant. Why not
    just put an array directly into the struct and let it get zeroed
    with the rest of the struct? That sidesteps the question of whether
    we need to clear() after an error return, but it would fix this bug. :)

  reply	other threads:[~2018-01-24  4:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-24  2:54 [PATCH] mailinfo: avoid segfault when can't open files Juan F. Codagnone
2018-01-24  4:02 ` Jeff King [this message]
2018-01-24 16:51   ` Juan F. Codagnone
2018-01-24 18:06     ` Jeff King
2018-01-24 16:56   ` [PATCH v1] " Juan F. Codagnone

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180124040232.GB1330@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=jcodagnone@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).