[v3,GSOC] ref-filter: fix read invalid union member bug

Commit Message

ZheNing Hu May 8, 2021, 3:26 p.m. UTC

From: ZheNing Hu <[e-mail]>

used_atom.u is an union, and it has different members depending on
what atom the auxiliary data the union part of the "struct
used_atom" wants to record. At most only one of the members can be
valid at any one time. Since the code checks u.remote_ref without
even making sure if the atom is "push" or "push:" (which are only
two cases that u.remote_ref.push becomes valid), but u.remote_ref
shares the same storage for other members of the union, the check
was reading from an invalid member, which was the bug.

Modify the condition here to check whether the atom name
equals to "push" or starts with "push:", to avoid reading the
value of invalid member of the union.

Helped-by: Junio C Hamano <[e-mail]>
Signed-off-by: ZheNing Hu <[e-mail]>
---
    [GSOC] ref-filter: fix read invalid union member bug
    
    Change from last version:
    Modify the processing method of the condition: check whether the name of
    the atom equals to "push" or starts with "pushs", which can enhanced
    security, although it may bring string match overhead.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-949%2Fadlternative%2Fref-filter-enum-bug-fix-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-949/adlternative/ref-filter-enum-bug-fix-v3
Pull-Request: https://github.com/gitgitgadget/git/pull/949

Range-diff vs v2:

 1:  0e1923c9d722 ! 1:  21cf7a44e168 [GSOC] ref-filter: fix read invalid union member bug
     @@ Commit message
      
          used_atom.u is an union, and it has different members depending on
          what atom the auxiliary data the union part of the "struct
     -    used_atom" wants to record.  At most only one of the members can be
     -    valid at any one time.  Since the code checks u.remote_ref without
     +    used_atom" wants to record. At most only one of the members can be
     +    valid at any one time. Since the code checks u.remote_ref without
          even making sure if the atom is "push" or "push:" (which are only
          two cases that u.remote_ref.push becomes valid), but u.remote_ref
          shares the same storage for other members of the union, the check
          was reading from an invalid member, which was the bug.
      
     -    Modify the condition here to first check whether the atom name
     -    starts with "push", and then check u.remote_ref, to avoid reading
     -    the value of invalid member of the union.
     +    Modify the condition here to check whether the atom name
     +    equals to "push" or starts with "push:", to avoid reading the
     +    value of invalid member of the union.
      
          Helped-by: Junio C Hamano <[e-mail]>
          Signed-off-by: ZheNing Hu <[e-mail]>
     @@ ref-filter.c: static int populate_value(struct ref_array_item *ref, struct strbu
       				v->s = xstrdup("");
       			continue;
      -		} else if (atom->u.remote_ref.push) {
     -+		} else if (starts_with(name, "push") && atom->u.remote_ref.push) {
     ++		} else if (!strcmp(atom->name, "push") || starts_with(atom->name, "push:")) {
       			const char *branch_name;
       			v->s = xstrdup("");
       			if (!skip_prefix(ref->refname, "refs/heads/",


 ref-filter.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


base-commit: 311531c9de557d25ac087c1637818bd2aad6eb3a

Comments

Junio C Hamano May 10, 2021, 7:21 a.m. UTC | #1

"ZheNing Hu via GitGitGadget" <[e-mail]> writes:

> From: ZheNing Hu <[e-mail]>
>
> used_atom.u is an union, and it has different members depending on
> what atom the auxiliary data the union part of the "struct
> used_atom" wants to record. At most only one of the members can be
> valid at any one time. Since the code checks u.remote_ref without
> even making sure if the atom is "push" or "push:" (which are only
> two cases that u.remote_ref.push becomes valid), but u.remote_ref
> shares the same storage for other members of the union, the check
> was reading from an invalid member, which was the bug.
>
> Modify the condition here to check whether the atom name
> equals to "push" or starts with "push:", to avoid reading the
> value of invalid member of the union.
>
> Helped-by: Junio C Hamano <[e-mail]>
> Signed-off-by: ZheNing Hu <[e-mail]>
> ---
>     [GSOC] ref-filter: fix read invalid union member bug
>     
>     Change from last version:
>     Modify the processing method of the condition: check whether the name of
>     the atom equals to "push" or starts with "pushs", which can enhanced
>     security, although it may bring string match overhead.

I do not think this would have much security implication either
way.  What it buys us is the future-proofing.

I think it is OK to make this change without the enum thing to have
it graduate early as a fix to the existing code.  The enum thing can
come on top.

Will queue.  Thanks.

Junio C Hamano May 10, 2021, 7:27 a.m. UTC | #2

"ZheNing Hu via GitGitGadget" <[e-mail]> writes:

> From: ZheNing Hu <[e-mail]>
>
> used_atom.u is an union, and it has different members depending on
> what atom the auxiliary data the union part of the "struct
> used_atom" wants to record. At most only one of the members can be
> valid at any one time. Since the code checks u.remote_ref without
> even making sure if the atom is "push" or "push:" (which are only
> two cases that u.remote_ref.push becomes valid), but u.remote_ref
> shares the same storage for other members of the union, the check
> was reading from an invalid member, which was the bug.
>
> Modify the condition here to check whether the atom name
> equals to "push" or starts with "push:", to avoid reading the
> value of invalid member of the union.
>
> Helped-by: Junio C Hamano <[e-mail]>
> Signed-off-by: ZheNing Hu <[e-mail]>
> ---

Just a final sanity check.  Is this a recent breakage or was the
code introduced at cc72385f (for-each-ref: let upstream/push
optionally report the remote name, 2017-10-05) broken from the
beginning?

I am wondering if it is easy to add a test to cover the codepath
that is affected by this change.

Thanks.

> diff --git a/ref-filter.c b/ref-filter.c
> index a0adb4551d87..213d3773ada3 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -1730,7 +1730,7 @@ static int populate_value(struct ref_array_item *ref, struct strbuf *err)
>  			else
>  				v->s = xstrdup("");
>  			continue;
> -		} else if (atom->u.remote_ref.push) {
> +		} else if (!strcmp(atom->name, "push") || starts_with(atom->name, "push:")) {
>  			const char *branch_name;
>  			v->s = xstrdup("");
>  			if (!skip_prefix(ref->refname, "refs/heads/",
>
> base-commit: 311531c9de557d25ac087c1637818bd2aad6eb3a

ZheNing Hu May 10, 2021, 12:35 p.m. UTC | #3

Junio C Hamano <[e-mail]> 于2021年5月10日周一 下午3:21写道：
>
> "ZheNing Hu via GitGitGadget" <[e-mail]> writes:
>
> > From: ZheNing Hu <[e-mail]>
> >
> > used_atom.u is an union, and it has different members depending on
> > what atom the auxiliary data the union part of the "struct
> > used_atom" wants to record. At most only one of the members can be
> > valid at any one time. Since the code checks u.remote_ref without
> > even making sure if the atom is "push" or "push:" (which are only
> > two cases that u.remote_ref.push becomes valid), but u.remote_ref
> > shares the same storage for other members of the union, the check
> > was reading from an invalid member, which was the bug.
> >
> > Modify the condition here to check whether the atom name
> > equals to "push" or starts with "push:", to avoid reading the
> > value of invalid member of the union.
> >
> > Helped-by: Junio C Hamano <[e-mail]>
> > Signed-off-by: ZheNing Hu <[e-mail]>
> > ---
> >     [GSOC] ref-filter: fix read invalid union member bug
> >
> >     Change from last version:
> >     Modify the processing method of the condition: check whether the name of
> >     the atom equals to "push" or starts with "pushs", which can enhanced
> >     security, although it may bring string match overhead.
>
> I do not think this would have much security implication either
> way.  What it buys us is the future-proofing.
>

Ah, truely.

> I think it is OK to make this change without the enum thing to have
> it graduate early as a fix to the existing code.  The enum thing can
> come on top.
>

Indeed. "enum atom_type" is for ref-filter performance optimization and get
some other benefits like quick index. So I put it in another topic.

> Will queue.  Thanks.

Thanks.
--
ZheNing Hu

ZheNing Hu May 10, 2021, 12:51 p.m. UTC | #4

> Just a final sanity check.  Is this a recent breakage or was the
> code introduced at cc72385f (for-each-ref: let upstream/push
> optionally report the remote name, 2017-10-05) broken from the
> beginning?
>

Well, The trigger condition is very special, but the bug was introduced
at that time. Let's see the "bug" example below.

> I am wondering if it is easy to add a test to cover the codepath
> that is affected by this change.
>
> Thanks.
>

Well, because this bug must require that the seventeenth bit of
`used_atom.u` is not 0, it took me a long time to find this bug.
in `used_atom.u`, only the member "color" and "contents" which
size is bigger than 17 bytes, but "%(contents:trailer:only)" only fill
the 16th byte of `used_atom.u`.

"Fortunately", I found it.

git for-each-ref --format='%(color:#aa22ac)'

I will add test for it!

Thanks!
--
ZheNing Hu

Patch

diff --git a/ref-filter.c b/ref-filter.c
index a0adb4551d87..213d3773ada3 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1730,7 +1730,7 @@  static int populate_value(struct ref_array_item *ref, struct strbuf *err)
 			else
 				v->s = xstrdup("");
 			continue;
-		} else if (atom->u.remote_ref.push) {
+		} else if (!strcmp(atom->name, "push") || starts_with(atom->name, "push:")) {
 			const char *branch_name;
 			v->s = xstrdup("");
 			if (!skip_prefix(ref->refname, "refs/heads/",