git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tarmigan <tarmigan+git@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>,
	"Shawn O. Pearce" <spearce@spearce.org>,
	git@vger.kernel.org
Subject: Re: [PATCH 1/2] http-backend: Fix access beyond end of string.
Date: Mon, 16 Nov 2009 20:46:38 -0800	[thread overview]
Message-ID: <905315640911162046q219c07d9w425f6bde0e1ba870@mail.gmail.com> (raw)
In-Reply-To: <7viqdb0zhs.fsf@alter.siamese.dyndns.org>

On Sun, Nov 15, 2009 at 10:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> On Sun, Nov 15, 2009 at 05:36:54PM -0800, Shawn O. Pearce wrote:
>> ...
>>> Shouldn't this instead be:
>>>
>>> diff --git a/http-backend.c b/http-backend.c
>>> index 9021266..16ec635 100644
>>> --- a/http-backend.c
>>> +++ b/http-backend.c
>>> @@ -626,7 +626,7 @@ int main(int argc, char **argv)
>>>                      }
>>>
>>>                      cmd = c;
>>> -                    cmd_arg = xmalloc(n);
>>> +                    cmd_arg = xmalloc(n + 1);
>>>                      strncpy(cmd_arg, dir + out[0].rm_so + 1, n);
>>>                      cmd_arg[n] = '\0';
>>>                      dir[out[0].rm_so] = 0;
>>>
>>> The cmd_arg string was simply allocated too small.  Your fix is
>>> terminating the string one character too short which would cause
>>> get_loose_object and get_pack_file to break.
>>
>> Actually, from my reading, I think his fix is right, because you trim
>> the first character during the strncpy (using "out[0].rm_so + 1").
>
> Your regexps all start with leading "/", and rm_so+1 points at the
> character after the slash; the intention being that you would copy
> the rest of the matched sequence without the leading "/".
>
> So allocating n = rm_eo - rm_so is Ok.  It counts the space for
> terminating NUL.  But copying "up to n bytes" using strncpy(), only to NUL
> terminate immediately later, is dubious.  You would want to copy only n-1
> bytes.  I.e.
>
>        n = out[0].rm_eo - out[0].rm_so; /* allocation */
>        ... validate and fail invalid method ...
>        cmd_arg = xmalloc(n);
>        memcpy(cmd_arg, dir + out[0].rm_so + 1, n-1);
>        cmd_arg[n-1] = '\0';
>

I think the strncpy( , ,n) would not harm anything because we won't
overflow dir because it's NUL terminated in getdir(), and the '\0'
shouldn't match the regex. But I agree that strncpy( , , n-1) is
better and memcpy( , , n-1) is better still.

Better eyes than mine have now looked at this and see different things
each time.  I wonder if some parts could be made a little less subtle
(perhaps along with the dir[out[0].rm_so] = 0;)?

Thanks,
Tarmigan

  reply	other threads:[~2009-11-17  4:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-14 21:10 [PATCH 1/2] http-backend: Fix access beyond end of string Tarmigan Casebolt
2009-11-14 21:10 ` [PATCH 2/2] http-backend: Let gcc check the format of more printf-type functions Tarmigan Casebolt
2009-11-16  1:39   ` Shawn O. Pearce
2009-11-16  1:36 ` [PATCH 1/2] http-backend: Fix access beyond end of string Shawn O. Pearce
2009-11-16  4:55   ` Jeff King
2009-11-16  6:12     ` Junio C Hamano
2009-11-17  4:46       ` Tarmigan [this message]
2009-11-23 17:20       ` Brian Gernhardt

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

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

  git send-email \
    --in-reply-to=905315640911162046q219c07d9w425f6bde0e1ba870@mail.gmail.com \
    --to=tarmigan+git@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=spearce@spearce.org \
    /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.
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 NNTP newsgroup(s).