From: Liu Yubao <yubao.liu@gmail.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Junio C Hamano <gitster@pobox.com>, git list <git@vger.kernel.org>
Subject: Re: [PATCH 1/5] avoid parse_sha1_header() accessing memory out of bound
Date: Wed, 03 Dec 2008 11:49:50 +0800 [thread overview]
Message-ID: <493601DE.3050107@gmail.com> (raw)
In-Reply-To: <20081202154257.GK23984@spearce.org>
Shawn O. Pearce wrote:
> Liu Yubao <yubao.liu@gmail.com> wrote:
>> diff --git a/sha1_file.c b/sha1_file.c
>> index 6c0e251..efe6967 100644
>> --- a/sha1_file.c
>> +++ b/sha1_file.c
>> @@ -1254,10 +1255,10 @@ static int parse_sha1_header(const char *hdr, unsigned long *sizep)
>> /*
>> * The type can be at most ten bytes (including the
>> * terminating '\0' that we add), and is followed by
>> - * a space.
>> + * a space, at least one byte for size, and a '\0'.
>> */
>> i = 0;
>> - for (;;) {
>> + while (hdr < hdr_end - 2) {
>> char c = *hdr++;
>> if (c == ' ')
>> break;
>> @@ -1265,6 +1266,8 @@ static int parse_sha1_header(const char *hdr, unsigned long *sizep)
>> if (i >= sizeof(type))
>> return -1;
>
> That first hunk I am citing is unnecessary, because of the lines
> right above. All of the callers of this function pass in a buffer
> that is at least 32 bytes in size; this loop aborts if it does not
> find a ' ' within the first 10 bytes of the buffer. We'll never
> access memory outside of the buffer during this loop.
>
> So IMHO your first three hunks here aren't necessary.
>
Seems you missed the cover letter sent as patch 0/5, all patches are explained
in the cover letter, sorry I sent them as separate topics by mistake.
This bound check is mainly for uncompressed loose object, a loose object
that just are uncompressed:
uncompressed loose object = inflate(loose object)
loose object = deflate(typename + <space> + size + '\0' + data)
I'm doing a defensive programming, for uncompressed loose object the mmapped
memory is passed to parse_sha1_header without being checked by inflateInit() first,
so there may be a SIGSEGV crash for a corrupted uncompressed loose object.
>> @@ -1275,7 +1278,7 @@ static int parse_sha1_header(const char *hdr, unsigned long *sizep)
>> if (size > 9)
>> return -1;
>> if (size) {
>> - for (;;) {
>> + while (hdr < hdr_end - 1) {
>> unsigned long c = *hdr - '0';
>> if (c > 9)
>> break;
>
> OK, there's no promise here that we don't roll off the buffer.
>
> This can be fixed in the caller, ensuring we always have the '\0'
> at some point in the initial header buffer we were asked to parse:
>
Isn't it easier to solve this problem in one place and maintain it? Maybe someday
someone forgets parse_sha1_header requires a null terminated buffer, and a corrupted
uncompressed loose object even doesn't have to be null terminated (if there will be
this kind of loose object).
next prev parent reply other threads:[~2008-12-03 3:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-01 8:00 two questions about the format of loose object Liu Yubao
2008-12-01 8:25 ` Junio C Hamano
2008-12-01 9:28 ` Liu Yubao
2008-12-01 11:32 ` Jakub Narebski
2008-12-02 2:19 ` Liu Yubao
2008-12-01 15:21 ` Shawn O. Pearce
2008-12-02 2:43 ` Liu Yubao
2008-12-02 1:48 ` [PATCH 0/5] support reading and writing uncompressed " Liu Yubao
2008-12-02 1:51 ` [PATCH 1/5] avoid parse_sha1_header() accessing memory out of bound Liu Yubao
2008-12-02 15:42 ` Shawn O. Pearce
2008-12-03 3:49 ` Liu Yubao [this message]
2008-12-02 1:53 ` [PATCH 2/5] don't die immediately when convert an invalid type name Liu Yubao
2008-12-02 1:55 ` [PATCH 3/5] optimize parse_sha1_header() a little by detecting object type Liu Yubao
2008-12-02 15:53 ` Shawn O. Pearce
2008-12-03 4:06 ` Liu Yubao
2008-12-02 1:56 ` [PATCH 4/5] support reading uncompressed loose object Liu Yubao
2008-12-02 15:58 ` Shawn O. Pearce
2008-12-03 4:09 ` Liu Yubao
2008-12-02 2:03 ` [PATCH 5/5] support writing " Liu Yubao
2008-12-02 16:07 ` Shawn O. Pearce
2008-12-03 4:22 ` Liu Yubao
2008-12-02 3:11 ` [PATCH 0/5] support reading and " Liu Yubao
2008-12-01 12:16 ` two questions about the format of " Nick Andrew
2008-12-02 2:26 ` Liu Yubao
2008-12-01 15:32 ` Shawn O. Pearce
2008-12-02 3:05 ` Liu Yubao
2008-12-04 0:54 ` Nicolas Pitre
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=493601DE.3050107@gmail.com \
--to=yubao.liu@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.