Use of uninitialised value of size 8 in sha1_name.c

Use of uninitialised value of size 8 in sha1_name.c

[Christian Couder]

Hi Derrick,

These days when running:

./t5616-partial-clone.sh --valgrind

on master, I get a bunch of:

==21455== Use of uninitialised value of size 8
==21455==    at 0x2D2A73: get_hex_char_from_oid (sha1_name.c:492)
==21455==    by 0x2D2AFE: extend_abbrev_len (sha1_name.c:502)
==21455==    by 0x2D2C3D: find_abbrev_len_for_pack (sha1_name.c:551)
==21455==    by 0x2D2CFF: find_abbrev_len_packed (sha1_name.c:569)
==21455==    by 0x2D2E12: find_unique_abbrev_r (sha1_name.c:608)
==21455==    by 0x2DCB66: strbuf_add_unique_abbrev (strbuf.c:877)
==21455==    by 0x14F7CE: update_local_ref (fetch.c:700)
==21455==    by 0x1500CF: store_updated_refs (fetch.c:871)
==21455==    by 0x15035B: fetch_refs (fetch.c:932)
==21455==    by 0x150CF8: do_fetch (fetch.c:1146)
==21455==    by 0x1515AB: fetch_one (fetch.c:1370)
==21455==    by 0x151A1D: cmd_fetch (fetch.c:1457)
==21455==  Uninitialised value was created by a stack allocation
==21455==    at 0x2D2B2E: find_abbrev_len_for_pack (sha1_name.c:513)
==21455==

A quick git blame seems to point to 0e87b85683 (sha1_name: minimize
OID comparisons during disambiguation, 2017-10-12).

It is difficult to tell for sure though as t5616-partial-clone.sh was
added after that commit.

Best,
Christian.

Re: Use of uninitialised value of size 8 in sha1_name.c

[Jeff King]

On Mon, Feb 26, 2018 at 10:04:22AM +0100, Christian Couder wrote:

> ==21455== Use of uninitialised value of size 8
> ==21455==    at 0x2D2A73: get_hex_char_from_oid (sha1_name.c:492)
> ==21455==    by 0x2D2AFE: extend_abbrev_len (sha1_name.c:502)
> ==21455==    by 0x2D2C3D: find_abbrev_len_for_pack (sha1_name.c:551)
> ==21455==    by 0x2D2CFF: find_abbrev_len_packed (sha1_name.c:569)
> ==21455==    by 0x2D2E12: find_unique_abbrev_r (sha1_name.c:608)
> ==21455==    by 0x2DCB66: strbuf_add_unique_abbrev (strbuf.c:877)
> ==21455==    by 0x14F7CE: update_local_ref (fetch.c:700)
> ==21455==    by 0x1500CF: store_updated_refs (fetch.c:871)
> ==21455==    by 0x15035B: fetch_refs (fetch.c:932)
> ==21455==    by 0x150CF8: do_fetch (fetch.c:1146)
> ==21455==    by 0x1515AB: fetch_one (fetch.c:1370)
> ==21455==    by 0x151A1D: cmd_fetch (fetch.c:1457)
> ==21455==  Uninitialised value was created by a stack allocation
> ==21455==    at 0x2D2B2E: find_abbrev_len_for_pack (sha1_name.c:513)
> ==21455==
> 
> A quick git blame seems to point to 0e87b85683 (sha1_name: minimize
> OID comparisons during disambiguation, 2017-10-12).
> 
> It is difficult to tell for sure though as t5616-partial-clone.sh was
> added after that commit.

I think that commit is to blame, though the error isn't exactly where
that stack trace puts it. Try this:

diff --git a/sha1_name.c b/sha1_name.c
index 611c7d24dd..6f7f36436f 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -547,7 +547,10 @@ static void find_abbrev_len_for_pack(struct packed_git *p,
 	 */
 	mad->init_len = 0;
 	if (!match) {
-		nth_packed_object_oid(&oid, p, first);
+		warning("p->num_objects = %u, first = %u",
+			p->num_objects, first);
+		if (!nth_packed_object_oid(&oid, p, first))
+			die("oops!");
 		extend_abbrev_len(&oid, mad);
 	} else if (first < num - 1) {
 		nth_packed_object_oid(&oid, p, first + 1);

I get failures all over the test suite, like this:

  warning: p->num_objects = 4, first = 3
  warning: p->num_objects = 8, first = 6
  warning: p->num_objects = 10, first = 0
  warning: p->num_objects = 4, first = 0
  warning: p->num_objects = 8, first = 0
  warning: p->num_objects = 10, first = 10
  fatal: oops!

Any time the abbreviated hex would go after the last object in the pack,
then first==p->num_objects, and nth_packed_object_oid() will fail. That
leaves uninitialized data in "oid", which is what valgrind complains
about when we examine it in extend_abbrev_len().

Most of the time the code behaves correctly anyway, because the
uninitialized bytes are unlikely to match up with our hex and extend the
length. Probably we just need to detect that case and skip the call to
extend_abbrev_len() altogether.

-Peff

Re: Use of uninitialised value of size 8 in sha1_name.c

[Christian Couder]

On Mon, Feb 26, 2018 at 10:53 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Feb 26, 2018 at 10:04:22AM +0100, Christian Couder wrote:
>
>> ==21455== Use of uninitialised value of size 8
>> ==21455==    at 0x2D2A73: get_hex_char_from_oid (sha1_name.c:492)
>> ==21455==    by 0x2D2AFE: extend_abbrev_len (sha1_name.c:502)
>> ==21455==    by 0x2D2C3D: find_abbrev_len_for_pack (sha1_name.c:551)
>> ==21455==    by 0x2D2CFF: find_abbrev_len_packed (sha1_name.c:569)
>> ==21455==    by 0x2D2E12: find_unique_abbrev_r (sha1_name.c:608)
>> ==21455==    by 0x2DCB66: strbuf_add_unique_abbrev (strbuf.c:877)
>> ==21455==    by 0x14F7CE: update_local_ref (fetch.c:700)
>> ==21455==    by 0x1500CF: store_updated_refs (fetch.c:871)
>> ==21455==    by 0x15035B: fetch_refs (fetch.c:932)
>> ==21455==    by 0x150CF8: do_fetch (fetch.c:1146)
>> ==21455==    by 0x1515AB: fetch_one (fetch.c:1370)
>> ==21455==    by 0x151A1D: cmd_fetch (fetch.c:1457)
>> ==21455==  Uninitialised value was created by a stack allocation
>> ==21455==    at 0x2D2B2E: find_abbrev_len_for_pack (sha1_name.c:513)
>> ==21455==
>>
>> A quick git blame seems to point to 0e87b85683 (sha1_name: minimize
>> OID comparisons during disambiguation, 2017-10-12).
>>
>> It is difficult to tell for sure though as t5616-partial-clone.sh was
>> added after that commit.
>
> I think that commit is to blame, though the error isn't exactly where
> that stack trace puts it. Try this:
>
> diff --git a/sha1_name.c b/sha1_name.c
> index 611c7d24dd..6f7f36436f 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -547,7 +547,10 @@ static void find_abbrev_len_for_pack(struct packed_git *p,
>          */
>         mad->init_len = 0;
>         if (!match) {
> -               nth_packed_object_oid(&oid, p, first);
> +               warning("p->num_objects = %u, first = %u",
> +                       p->num_objects, first);
> +               if (!nth_packed_object_oid(&oid, p, first))
> +                       die("oops!");
>                 extend_abbrev_len(&oid, mad);
>         } else if (first < num - 1) {
>                 nth_packed_object_oid(&oid, p, first + 1);
>
> I get failures all over the test suite, like this:
>
>   warning: p->num_objects = 4, first = 3
>   warning: p->num_objects = 8, first = 6
>   warning: p->num_objects = 10, first = 0
>   warning: p->num_objects = 4, first = 0
>   warning: p->num_objects = 8, first = 0
>   warning: p->num_objects = 10, first = 10
>   fatal: oops!

Yeah, I tried to t5601-clone.sh with --valgrind and I also get one
error (the same "Uninitialised value" error actually).

> Any time the abbreviated hex would go after the last object in the pack,
> then first==p->num_objects, and nth_packed_object_oid() will fail. That
> leaves uninitialized data in "oid", which is what valgrind complains
> about when we examine it in extend_abbrev_len().
>
> Most of the time the code behaves correctly anyway, because the
> uninitialized bytes are unlikely to match up with our hex and extend the
> length. Probably we just need to detect that case and skip the call to
> extend_abbrev_len() altogether.

Yeah, something like:

diff --git a/sha1_name.c b/sha1_name.c
index 611c7d24dd..a041d8d24f 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -547,15 +547,15 @@ static void find_abbrev_len_for_pack(struct packed_git *p,
         */
        mad->init_len = 0;
        if (!match) {
-               nth_packed_object_oid(&oid, p, first);
-               extend_abbrev_len(&oid, mad);
+               if (nth_packed_object_oid(&oid, p, first))
+                       extend_abbrev_len(&oid, mad);
        } else if (first < num - 1) {
-               nth_packed_object_oid(&oid, p, first + 1);
-               extend_abbrev_len(&oid, mad);
+               if (nth_packed_object_oid(&oid, p, first + 1))
+                       extend_abbrev_len(&oid, mad);
        }
        if (first > 0) {
-               nth_packed_object_oid(&oid, p, first - 1);
-               extend_abbrev_len(&oid, mad);
+               if (nth_packed_object_oid(&oid, p, first - 1))
+                       extend_abbrev_len(&oid, mad);
        }
        mad->init_len = mad->cur_len;
 }

seems to prevent valgrind from complaining when running t5616-partial-clone.sh.

Re: Use of uninitialised value of size 8 in sha1_name.c

[Derrick Stolee]

On 2/26/2018 5:23 AM, Christian Couder wrote:
> On Mon, Feb 26, 2018 at 10:53 AM, Jeff King <peff@peff.net> wrote:
>> On Mon, Feb 26, 2018 at 10:04:22AM +0100, Christian Couder wrote:
>>
>>> ==21455== Use of uninitialised value of size 8
>>> ==21455==    at 0x2D2A73: get_hex_char_from_oid (sha1_name.c:492)
>>> ==21455==    by 0x2D2AFE: extend_abbrev_len (sha1_name.c:502)
>>> ==21455==    by 0x2D2C3D: find_abbrev_len_for_pack (sha1_name.c:551)
>>> ==21455==    by 0x2D2CFF: find_abbrev_len_packed (sha1_name.c:569)
>>> ==21455==    by 0x2D2E12: find_unique_abbrev_r (sha1_name.c:608)
>>> ==21455==    by 0x2DCB66: strbuf_add_unique_abbrev (strbuf.c:877)
>>> ==21455==    by 0x14F7CE: update_local_ref (fetch.c:700)
>>> ==21455==    by 0x1500CF: store_updated_refs (fetch.c:871)
>>> ==21455==    by 0x15035B: fetch_refs (fetch.c:932)
>>> ==21455==    by 0x150CF8: do_fetch (fetch.c:1146)
>>> ==21455==    by 0x1515AB: fetch_one (fetch.c:1370)
>>> ==21455==    by 0x151A1D: cmd_fetch (fetch.c:1457)
>>> ==21455==  Uninitialised value was created by a stack allocation
>>> ==21455==    at 0x2D2B2E: find_abbrev_len_for_pack (sha1_name.c:513)
>>> ==21455==
>>>
>>> A quick git blame seems to point to 0e87b85683 (sha1_name: minimize
>>> OID comparisons during disambiguation, 2017-10-12).
>>>
>>> It is difficult to tell for sure though as t5616-partial-clone.sh was
>>> added after that commit.
>> I think that commit is to blame, though the error isn't exactly where
>> that stack trace puts it. Try this:
>>
>> diff --git a/sha1_name.c b/sha1_name.c
>> index 611c7d24dd..6f7f36436f 100644
>> --- a/sha1_name.c
>> +++ b/sha1_name.c
>> @@ -547,7 +547,10 @@ static void find_abbrev_len_for_pack(struct packed_git *p,
>>           */
>>          mad->init_len = 0;
>>          if (!match) {
>> -               nth_packed_object_oid(&oid, p, first);
>> +               warning("p->num_objects = %u, first = %u",
>> +                       p->num_objects, first);
>> +               if (!nth_packed_object_oid(&oid, p, first))
>> +                       die("oops!");
>>                  extend_abbrev_len(&oid, mad);
>>          } else if (first < num - 1) {
>>                  nth_packed_object_oid(&oid, p, first + 1);
>>
>> I get failures all over the test suite, like this:
>>
>>    warning: p->num_objects = 4, first = 3
>>    warning: p->num_objects = 8, first = 6
>>    warning: p->num_objects = 10, first = 0
>>    warning: p->num_objects = 4, first = 0
>>    warning: p->num_objects = 8, first = 0
>>    warning: p->num_objects = 10, first = 10
>>    fatal: oops!
> Yeah, I tried to t5601-clone.sh with --valgrind and I also get one
> error (the same "Uninitialised value" error actually).

Thanks for finding this. Sorry for the bug.

>> Any time the abbreviated hex would go after the last object in the pack,
>> then first==p->num_objects, and nth_packed_object_oid() will fail. That
>> leaves uninitialized data in "oid", which is what valgrind complains
>> about when we examine it in extend_abbrev_len().
>>
>> Most of the time the code behaves correctly anyway, because the
>> uninitialized bytes are unlikely to match up with our hex and extend the
>> length. Probably we just need to detect that case and skip the call to
>> extend_abbrev_len() altogether.
> Yeah, something like:
>
> diff --git a/sha1_name.c b/sha1_name.c
> index 611c7d24dd..a041d8d24f 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -547,15 +547,15 @@ static void find_abbrev_len_for_pack(struct packed_git *p,
>           */
>          mad->init_len = 0;
>          if (!match) {
> -               nth_packed_object_oid(&oid, p, first);
> -               extend_abbrev_len(&oid, mad);
> +               if (nth_packed_object_oid(&oid, p, first))
> +                       extend_abbrev_len(&oid, mad);
>          } else if (first < num - 1) {
> -               nth_packed_object_oid(&oid, p, first + 1);
> -               extend_abbrev_len(&oid, mad);
> +               if (nth_packed_object_oid(&oid, p, first + 1))
> +                       extend_abbrev_len(&oid, mad);
>          }
>          if (first > 0) {
> -               nth_packed_object_oid(&oid, p, first - 1);
> -               extend_abbrev_len(&oid, mad);
> +               if (nth_packed_object_oid(&oid, p, first - 1))
> +                       extend_abbrev_len(&oid, mad);
>          }
>          mad->init_len = mad->cur_len;
>   }
>
> seems to prevent valgrind from complaining when running t5616-partial-clone.sh.

This seems like the safest fix, but also we could use our values of 
"match", "first" and "num" to safely call nth_packed_object_oid(). 
However, since nth_packed_object_oid() checks the bounds, don't 
duplicate work and just use the return value.

I would reformat your patch slightly, but that's just preference:

diff --git a/sha1_name.c b/sha1_name.c
index 611c7d2..97b632c 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -546,17 +546,14 @@ static void find_abbrev_len_for_pack(struct 
packed_git *p,
          * nearby for the abbreviation length.
          */
         mad->init_len = 0;
-       if (!match) {
-               nth_packed_object_oid(&oid, p, first);
+       if (!match && nth_packed_object_oid(&oid, p, first))
                 extend_abbrev_len(&oid, mad);
-       } else if (first < num - 1) {
-               nth_packed_object_oid(&oid, p, first + 1);
+       else if (first < num - 1 &&
+                nth_packed_object_oid(&oid, p, first + 1))
                 extend_abbrev_len(&oid, mad);
-       }
-       if (first > 0) {
-               nth_packed_object_oid(&oid, p, first - 1);
+       if (first > 0 && nth_packed_object_oid(&oid, p, first - 1))
                 extend_abbrev_len(&oid, mad);
-       }
+
         mad->init_len = mad->cur_len;
  }

Christian: do you want to submit the patch, or should I put one together?

Thanks,
-Stolee

Re: Use of uninitialised value of size 8 in sha1_name.c

[Christian Couder]

On Mon, Feb 26, 2018 at 3:06 PM, Derrick Stolee <stolee@gmail.com> wrote:
>
> Christian: do you want to submit the patch, or should I put one together?

I'd rather have you put one together.

Thanks,
Christian.

[PATCH] sha1_name: fix uninitialized memory errors

[Derrick Stolee]

During abbreviation checks, we navigate to the position within a
pack-index that an OID would be inserted and check surrounding OIDs
for the maximum matching prefix. This position may be beyond the
last position, because the given OID is lexicographically larger
than every OID in the pack. Then nth_packed_object_oid() does not
initialize "oid".

Use the return value of nth_packed_object_oid() to prevent these
errors.

Reported-by: Christian Couder <christian.couder@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
---
 sha1_name.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/sha1_name.c b/sha1_name.c
index 611c7d2..44dd595 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -546,17 +546,12 @@ static void find_abbrev_len_for_pack(struct packed_git *p,
 	 * nearby for the abbreviation length.
 	 */
 	mad->init_len = 0;
-	if (!match) {
-		nth_packed_object_oid(&oid, p, first);
+	if (!match && nth_packed_object_oid(&oid, p, first))
 		extend_abbrev_len(&oid, mad);
-	} else if (first < num - 1) {
-		nth_packed_object_oid(&oid, p, first + 1);
+	else if (first < num - 1 && nth_packed_object_oid(&oid, p, first + 1))
 		extend_abbrev_len(&oid, mad);
-	}
-	if (first > 0) {
-		nth_packed_object_oid(&oid, p, first - 1);
+	if (first > 0 && nth_packed_object_oid(&oid, p, first - 1))
 		extend_abbrev_len(&oid, mad);
-	}
 	mad->init_len = mad->cur_len;
 }
 
-- 
2.7.4

Re: [PATCH] sha1_name: fix uninitialized memory errors

[Jeff King]

On Mon, Feb 26, 2018 at 09:56:47AM -0500, Derrick Stolee wrote:

> diff --git a/sha1_name.c b/sha1_name.c
> index 611c7d2..44dd595 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -546,17 +546,12 @@ static void find_abbrev_len_for_pack(struct packed_git *p,
>  	 * nearby for the abbreviation length.
>  	 */
>  	mad->init_len = 0;
> -	if (!match) {
> -		nth_packed_object_oid(&oid, p, first);
> +	if (!match && nth_packed_object_oid(&oid, p, first))
>  		extend_abbrev_len(&oid, mad);
> -	} else if (first < num - 1) {
> -		nth_packed_object_oid(&oid, p, first + 1);
> +	else if (first < num - 1 && nth_packed_object_oid(&oid, p, first + 1))
>  		extend_abbrev_len(&oid, mad);
> -	}

I think including the nth_packed_object_oid() in the main if-else chain
works out, but it's kind of tricky.

In the code before, we'd hit the "first < num - 1" conditional only when
we didn't match something. But now we also hit it if we _did_ match
something, but nth_packed_object_oid() didn't work.

But this works out the same if we assume any match must also succeed at
nth_packed_object_oid(). Which in turn implies that checking the result
of nth_packed_object_oid() in the "else if" is redundant (though we
already clamp it to "num - 1", so we'd expect it to always succeed
anyway).

So I think this behaves well, but I wonder if the two-level conditionals
like:

  if (!match) {
	if (nth_packed_object_oid(&oid, p, first))
		extend_abbrev_len(&oid, mad);
  } else if ...

are easier to reason about.

-Peff

[PATCH v2] sha1_name: fix uninitialized memory errors

[Derrick Stolee]

Peff made an excellent point about the nested if statements. This
goes back to Christian's original recommendation.

-- >8 --

During abbreviation checks, we navigate to the position within a
pack-index that an OID would be inserted and check surrounding OIDs
for the maximum matching prefix. This position may be beyond the
last position, because the given OID is lexicographically larger
than every OID in the pack. Then nth_packed_object_oid() does not
initialize "oid".

Use the return value of nth_packed_object_oid() to prevent these
errors.

Reported-by: Christian Couder <christian.couder@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
---
 sha1_name.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/sha1_name.c b/sha1_name.c
index 611c7d24dd..a041d8d24f 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -547,15 +547,15 @@ static void find_abbrev_len_for_pack(struct packed_git *p,
 	 */
 	mad->init_len = 0;
 	if (!match) {
-		nth_packed_object_oid(&oid, p, first);
-		extend_abbrev_len(&oid, mad);
+		if (nth_packed_object_oid(&oid, p, first))
+			extend_abbrev_len(&oid, mad);
 	} else if (first < num - 1) {
-		nth_packed_object_oid(&oid, p, first + 1);
-		extend_abbrev_len(&oid, mad);
+		if (nth_packed_object_oid(&oid, p, first + 1))
+			extend_abbrev_len(&oid, mad);
 	}
 	if (first > 0) {
-		nth_packed_object_oid(&oid, p, first - 1);
-		extend_abbrev_len(&oid, mad);
+		if (nth_packed_object_oid(&oid, p, first - 1))
+			extend_abbrev_len(&oid, mad);
 	}
 	mad->init_len = mad->cur_len;
 }
-- 
2.16.2.265.g3d5930c0b9.dirty

Re: [PATCH v2] sha1_name: fix uninitialized memory errors

[Jeff King]

On Tue, Feb 27, 2018 at 06:47:04AM -0500, Derrick Stolee wrote:

> Peff made an excellent point about the nested if statements. This
> goes back to Christian's original recommendation.
> 
> -- >8 --
> 
> During abbreviation checks, we navigate to the position within a
> pack-index that an OID would be inserted and check surrounding OIDs
> for the maximum matching prefix. This position may be beyond the
> last position, because the given OID is lexicographically larger
> than every OID in the pack. Then nth_packed_object_oid() does not
> initialize "oid".
> 
> Use the return value of nth_packed_object_oid() to prevent these
> errors.
> 
> Reported-by: Christian Couder <christian.couder@gmail.com>
> Signed-off-by: Derrick Stolee <dstolee@microsoft.com>

Thanks, this looks good to me.

Semi-related, I wondered also at the weird asymmetry in the if-else,
which is:

  if ...
  else if ...
  if ...

but the comment directly above says: "we consider a maximum of three
objects nearby". I think it's actually two, because you can only trigger
one of the first two conditionals.

Is that right?

Let's imagine we're looking for object 1234abcd.  If we didn't find a
match, then we might have:

  1234abcc 
  1234abce <-- first points here

in which case we need to check both first-1 and first. And we do.

If we do have a match, then we might see:

  1234abcc
  1234abcd <-- first points here
  1234abce

and we must check first-1 and first+1, but _not_ first.

So I think the code is right, but the comment is wrong.

-Peff

Re: [PATCH v2] sha1_name: fix uninitialized memory errors

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Thanks, this looks good to me.
>
> Semi-related, I wondered also at the weird asymmetry in the if-else,
> ...
> So I think the code is right, but the comment is wrong.



-- >8 --
From: Derrick Stolee <dstolee@microsoft.com>
Date: Tue, 27 Feb 2018 06:47:04 -0500
Subject: [PATCH] sha1_name: fix uninitialized memory errors

During abbreviation checks, we navigate to the position within a
pack-index that an OID would be inserted and check surrounding OIDs
for the maximum matching prefix. This position may be beyond the
last position, because the given OID is lexicographically larger
than every OID in the pack. Then nth_packed_object_oid() does not
initialize "oid".

Use the return value of nth_packed_object_oid() to prevent these
errors.

Also the comment about checking near-by objects miscounts the
neighbours.  If we have a hit at "first", we check "first-1" and
"first+1" to make sure we have sufficiently long abbreviation not to
match either.  If we do not have a hit, "first" is the smallest
among the objects that are larger than what we want to name, so we
check that and "first-1" to make sure we have sufficiently long
abbreviation not to match either.  In either case, we only check up
to two near-by objects.

Reported-by: Christian Couder <christian.couder@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 sha1_name.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/sha1_name.c b/sha1_name.c
index 05a635911b..f1c3d37a6d 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -542,20 +542,20 @@ static void find_abbrev_len_for_pack(struct packed_git *p,
 	/*
 	 * first is now the position in the packfile where we would insert
 	 * mad->hash if it does not exist (or the position of mad->hash if
-	 * it does exist). Hence, we consider a maximum of three objects
+	 * it does exist). Hence, we consider a maximum of two objects
 	 * nearby for the abbreviation length.
 	 */
 	mad->init_len = 0;
 	if (!match) {
-		nth_packed_object_oid(&oid, p, first);
-		extend_abbrev_len(&oid, mad);
+		if (nth_packed_object_oid(&oid, p, first))
+			extend_abbrev_len(&oid, mad);
 	} else if (first < num - 1) {
-		nth_packed_object_oid(&oid, p, first + 1);
-		extend_abbrev_len(&oid, mad);
+		if (nth_packed_object_oid(&oid, p, first + 1))
+			extend_abbrev_len(&oid, mad);
 	}
 	if (first > 0) {
-		nth_packed_object_oid(&oid, p, first - 1);
-		extend_abbrev_len(&oid, mad);
+		if (nth_packed_object_oid(&oid, p, first - 1))
+			extend_abbrev_len(&oid, mad);
 	}
 	mad->init_len = mad->cur_len;
 }
-- 
2.16.2-325-g2fc74f41c5

Re: [PATCH v2] sha1_name: fix uninitialized memory errors

[Jeff King]

On Tue, Feb 27, 2018 at 02:30:39PM -0800, Junio C Hamano wrote:

> -- >8 --
> From: Derrick Stolee <dstolee@microsoft.com>
> Date: Tue, 27 Feb 2018 06:47:04 -0500
> Subject: [PATCH] sha1_name: fix uninitialized memory errors
> 
> During abbreviation checks, we navigate to the position within a
> pack-index that an OID would be inserted and check surrounding OIDs
> for the maximum matching prefix. This position may be beyond the
> last position, because the given OID is lexicographically larger
> than every OID in the pack. Then nth_packed_object_oid() does not
> initialize "oid".
> 
> Use the return value of nth_packed_object_oid() to prevent these
> errors.
> 
> Also the comment about checking near-by objects miscounts the
> neighbours.  If we have a hit at "first", we check "first-1" and
> "first+1" to make sure we have sufficiently long abbreviation not to
> match either.  If we do not have a hit, "first" is the smallest
> among the objects that are larger than what we want to name, so we
> check that and "first-1" to make sure we have sufficiently long
> abbreviation not to match either.  In either case, we only check up
> to two near-by objects.

Yep, this looks good to me. Thanks for wrapping it up.

-Peff

Re: [PATCH v2] sha1_name: fix uninitialized memory errors

[Junio C Hamano]

Derrick Stolee <dstolee@microsoft.com> writes:

> diff --git a/sha1_name.c b/sha1_name.c
> index 611c7d24dd..a041d8d24f 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -547,15 +547,15 @@ static void find_abbrev_len_for_pack(struct packed_git *p,
>  	 */
>  	mad->init_len = 0;
>  	if (!match) {
> -		nth_packed_object_oid(&oid, p, first);
> -		extend_abbrev_len(&oid, mad);
> +		if (nth_packed_object_oid(&oid, p, first))
> +			extend_abbrev_len(&oid, mad);
>  	} else if (first < num - 1) {
> -		nth_packed_object_oid(&oid, p, first + 1);
> -		extend_abbrev_len(&oid, mad);
> +		if (nth_packed_object_oid(&oid, p, first + 1))
> +			extend_abbrev_len(&oid, mad);
>  	}
>  	if (first > 0) {
> -		nth_packed_object_oid(&oid, p, first - 1);
> -		extend_abbrev_len(&oid, mad);
> +		if (nth_packed_object_oid(&oid, p, first - 1))
> +			extend_abbrev_len(&oid, mad);
>  	}
>  	mad->init_len = mad->cur_len;
>  }

I do not think they are wrong, but aren't the latter two somewhat
redundant?  "num" is p->num_objects, and we call (first+1)th element
only after we see (first < num - 1), i.e. first+1 < num, and the
access to (first-1)th is done only when first > 0.  The first one,
i.e. when first points at where we _would_ find it if it existed,
can access "first" that could be p->num_objects, so the change there
makes sense, though.

Re: [PATCH v2] sha1_name: fix uninitialized memory errors

[Derrick Stolee]

On 2/28/2018 3:50 PM, Junio C Hamano wrote:
> Derrick Stolee <dstolee@microsoft.com> writes:
>
>> diff --git a/sha1_name.c b/sha1_name.c
>> index 611c7d24dd..a041d8d24f 100644
>> --- a/sha1_name.c
>> +++ b/sha1_name.c
>> @@ -547,15 +547,15 @@ static void find_abbrev_len_for_pack(struct packed_git *p,
>>   	 */
>>   	mad->init_len = 0;
>>   	if (!match) {
>> -		nth_packed_object_oid(&oid, p, first);
>> -		extend_abbrev_len(&oid, mad);
>> +		if (nth_packed_object_oid(&oid, p, first))
>> +			extend_abbrev_len(&oid, mad);
>>   	} else if (first < num - 1) {
>> -		nth_packed_object_oid(&oid, p, first + 1);
>> -		extend_abbrev_len(&oid, mad);
>> +		if (nth_packed_object_oid(&oid, p, first + 1))
>> +			extend_abbrev_len(&oid, mad);
>>   	}
>>   	if (first > 0) {
>> -		nth_packed_object_oid(&oid, p, first - 1);
>> -		extend_abbrev_len(&oid, mad);
>> +		if (nth_packed_object_oid(&oid, p, first - 1))
>> +			extend_abbrev_len(&oid, mad);
>>   	}
>>   	mad->init_len = mad->cur_len;
>>   }
> I do not think they are wrong, but aren't the latter two somewhat
> redundant?  "num" is p->num_objects, and we call (first+1)th element
> only after we see (first < num - 1), i.e. first+1 < num, and the
> access to (first-1)th is done only when first > 0.  The first one,
> i.e. when first points at where we _would_ find it if it existed,
> can access "first" that could be p->num_objects, so the change there
> makes sense, though.
>

Yes. But I'd rather keep the blocks consistent and use the return value 
of nth_packed_object_oid() when possible.

Thanks,
-Stolee

Re: [PATCH v2] sha1_name: fix uninitialized memory errors

[Junio C Hamano]

Derrick Stolee <stolee@gmail.com> writes:

>> I do not think they are wrong, but aren't the latter two somewhat
>> redundant?  "num" is p->num_objects, and we call (first+1)th element
>> only after we see (first < num - 1), i.e. first+1 < num, and the
>> access to (first-1)th is done only when first > 0.  The first one,
>> i.e. when first points at where we _would_ find it if it existed,
>> can access "first" that could be p->num_objects, so the change there
>> makes sense, though.
>
> Yes. But I'd rather keep the blocks consistent and use the return
> value of nth_packed_object_oid() when possible.

Sure, I do not think anybody minds; I just wanted a sanity check.

Thansk.