threads / patch / 48605

patch, 5 partsrefspec.c: use rhs in parse_refspec instead of potentially uninitialized item->dst

Subject: [PATCH 5/5] refspec.c: use rhs in parse_refspec instead of potentially uninitialized item->dst

## tl;dr

4 messages between May 30, 2018 and Jun 1, 2018. Diffs are folded; open one to read it.

replies: 3people: 2as markdown or json

Stefan Beller· May 30, 2018, 17:04 UTC · lore

'item->dst' has not been assigned if '!rhs' is true. As the caller is allowed to pass in uninitialized memory (we don't assume 'item' was zeroed out before calling), this fixes an access to uninitialized memory.

Signed-off-by: Stefan Beller <sbeller@google.com>
---
applies on bw/refspec-api
 refspec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to refspec.c +1 −1
diff --git a/refspec.c b/refspec.c
index c59a4ccf1e5..ea169dec0d3 100644
--- a/refspec.c
+++ b/refspec.c
@@ -108,7 +108,7 @@ static int parse_refspec(struct refspec_item *item, const char *refspec, int fet
 		 * - empty is not allowed.
 		 * - otherwise it must be a valid looking ref.
 		 */
-		if (!item->dst) {
+		if (!rhs) {
 			if (check_refname_format(item->src, flags))
 				return 0;
 		} else if (!*item->dst) {

-- 
2.17.0.582.gccdcbd54c44.dirty
Junio C Hamano· Jun 1, 2018, 02:01 UTC · re: Stefan Beller · lore

Re: [PATCH 5/5] refspec.c: use rhs in parse_refspec instead of potentially uninitialized item->dst

Stefan Beller <sbeller@google.com> writes:
> 'item->dst' has not been assigned if '!rhs' is true. As the caller is allowed to pass in uninitialized
> memory (we don't assume 'item' was zeroed out before calling), this fixes an access to
> uninitialized memory.
Did I miss the other 4 patches that this might depend on it?
Show 13 quoted lines
> diff --git a/refspec.c b/refspec.c
> index c59a4ccf1e5..ea169dec0d3 100644
> --- a/refspec.c
> +++ b/refspec.c
> @@ -108,7 +108,7 @@ static int parse_refspec(struct refspec_item *item, const char *refspec, int fet
>  		 * - empty is not allowed.
>  		 * - otherwise it must be a valid looking ref.
>  		 */
> -		if (!item->dst) {
> +		if (!rhs) {
>  			if (check_refname_format(item->src, flags))
>  				return 0;
>  		} else if (!*item->dst) {

Perhaps a better fisx is to explicitly assign NULL to item->dst when we see there is no right-hand-side.

Aside from the "uninitialized" issue, the original if/else cascade around here makes a lot more sense than the updated version. If we do not leave item->dst uninitialized, the control (and the readers' understanding) can flow without having to carry the invariant "item->dst is set ONLY when rhs != NULL" throughout this codepath, in order to understand that this if/else cascade is asking: is pointer NULL? then do one thing, otherwise is pointee NUL? then do another thing, otherwise we have a non-empty string so do something on it.

Junio C Hamano· Jun 1, 2018, 02:46 UTC · re: Junio C Hamano · lore

Re: [PATCH 5/5] refspec.c: use rhs in parse_refspec instead of potentially uninitialized item->dst

Junio C Hamano <gitster@pobox.com> writes:
> Perhaps a better fisx is to explicitly assign NULL to item->dst when
> we see there is no right-hand-side.
-- >8 --
Subject: [PATCH] refspec-api: avoid uninitialized field in refspec item

When parse_refspec() function was created at 3eec3700 ("refspec: factor out parsing a single refspec", 2018-05-16) to take a caller supplied piece of memory to fill parsed refspec_item, it forgot that a refspec without colon must set item->dst to NULL to let the users of refspec know that the result of the fetch does not get stored in an ref on our side.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * The original before that change filled a callee prepared piece of
   memory that was obtained from xcalloc(), and did not need to
   explicitly assign NULL to the field after noticing that there is
   no colon in the refspec, so it is understandable how this
   misconvesion happened.
 refspec.c | 2 ++
 1 file changed, 2 insertions(+)
Show changes to refspec.c +2 −0
diff --git a/refspec.c b/refspec.c
index 97e76e8b1d..6e45365a23 100644
--- a/refspec.c
+++ b/refspec.c
@@ -48,6 +48,8 @@ static int parse_refspec(struct refspec_item *item, const char *refspec, int fet
 		size_t rlen = strlen(++rhs);
 		is_glob = (1 <= rlen && strchr(rhs, '*'));
 		item->dst = xstrndup(rhs, rlen);
+	} else {
+		item->dst = NULL;
 	}
 
 	llen = (rhs ? (rhs - lhs - 1) : strlen(lhs));

-- 
2.18.0-rc0
Stefan Beller· Jun 1, 2018, 19:38 UTC · re: Junio C Hamano · lore

Re: [PATCH 5/5] refspec.c: use rhs in parse_refspec instead of potentially uninitialized item->dst

On Thu, May 31, 2018 at 7:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 16 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Perhaps a better fisx is to explicitly assign NULL to item->dst when
>> we see there is no right-hand-side.
>
> -- >8 --
> Subject: [PATCH] refspec-api: avoid uninitialized field in refspec item
>
> When parse_refspec() function was created at 3eec3700 ("refspec:
> factor out parsing a single refspec", 2018-05-16) to take a caller
> supplied piece of memory to fill parsed refspec_item, it forgot that
> a refspec without colon must set item->dst to NULL to let the users
> of refspec know that the result of the fetch does not get stored in
> an ref on our side.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This looks correct. Thanks for writing the patch.
> Did I miss the other 4 patches that this might depend on it?

No. I was sloppy and developed a couple of patches on top of pu and then tried to put them onto their respective branches. and then I forgot to correct the patch counts after figuring out the right branch to apply this to.

Thanks, Stefan

← back to recent threads