git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Rubén Justo" <rjusto@gmail.com>
Cc: git@vger.kernel.org, Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH v5] branch: support for shortcuts like @{-1}, completed
Date: Sun, 09 Oct 2022 12:11:53 -0700	[thread overview]
Message-ID: <xmqqa6647qx2.fsf@gitster.g> (raw)
In-Reply-To: de200fa0-379d-c1ce-8446-9e4292d0b66a@gmail.com

Rubén Justo <rjusto@gmail.com> writes:

> @@ -791,19 +791,23 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
>  	} else if (edit_description) {
>  		const char *branch_name;
>  		struct strbuf branch_ref = STRBUF_INIT;
> +		struct strbuf buf = STRBUF_INIT;
>  
>  		if (!argc) {
>  			if (filter.detached)
>  				die(_("Cannot give description to detached HEAD"));
>  			branch_name = head;
> -		} else if (argc == 1)
> -			branch_name = argv[0];
> +		} else if (argc == 1) {
> +			strbuf_branchname(&buf, argv[0], INTERPRET_BRANCH_LOCAL);
> +			branch_name = buf.buf;
> +		}
>  		else
>  			die(_("cannot edit description of more than one branch"));

Here branch_name could be pointing at buf.buf (or head).

>  		strbuf_addf(&branch_ref, "refs/heads/%s", branch_name);
>  		if (!ref_exists(branch_ref.buf)) {
>  			strbuf_release(&branch_ref);
> +			strbuf_release(&buf);

But the contents of the buf becomes invalid at this point.

>  			if (!argc)
>  				return error(_("No commit on branch '%s' yet."),

In the post context of this hunk, we see that the '%s' above is
filled with branch_name, accessing the potentially invalid contents.

I'll put a squashable band-aid on top of the topic for now.

--- >8 ---

 * cmd_foo() should not return an negative value.

 * branch_name used in the calls to error() could point at buf.buf
   that holds the expansion of @{-1}, but buf was released way too
   early, leading to a use-after-free.

 * Style: if/else if/else cascade whose one arm has multiple
   statements and requires {braces} around it should have {braces}
   around all of its arms.

 * each arm in the top-level if/else if/else cascade for "git
   branch" subcommands were more or less independent, and there
   wasn't anything common that they need to execute after exiting
   the cascade.  Unconditionally returning from the arm for the
   edit-description subcommand seems to make the logic flow easier
   to read.

 builtin/branch.c | 31 +++++++++++++------------------
 1 file changed, 13 insertions(+), 18 deletions(-)

diff --git a/builtin/branch.c b/builtin/branch.c
index 197603241d..17853225fa 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -792,6 +792,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 		const char *branch_name;
 		struct strbuf branch_ref = STRBUF_INIT;
 		struct strbuf buf = STRBUF_INIT;
+		int ret = 1; /* assume failure */
 
 		if (!argc) {
 			if (filter.detached)
@@ -800,29 +801,23 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 		} else if (argc == 1) {
 			strbuf_branchname(&buf, argv[0], INTERPRET_BRANCH_LOCAL);
 			branch_name = buf.buf;
-		}
-		else
+		} else {
 			die(_("cannot edit description of more than one branch"));
+		}
 
 		strbuf_addf(&branch_ref, "refs/heads/%s", branch_name);
-		if (!ref_exists(branch_ref.buf)) {
-			strbuf_release(&branch_ref);
-			strbuf_release(&buf);
-
-			if (!argc)
-				return error(_("No commit on branch '%s' yet."),
-					     branch_name);
-			else
-				return error(_("No branch named '%s'."),
-					     branch_name);
-		}
-		strbuf_release(&branch_ref);
+		if (!ref_exists(branch_ref.buf))
+			error(!argc
+			      ? _("No commit on branch '%s' yet.")
+			      : _("No branch named '%s'."),
+			      branch_name);
+		else if (!edit_branch_description(branch_name))
+			ret = 0; /* happy */
 
-		if (edit_branch_description(branch_name)) {
-			strbuf_release(&buf);
-			return 1;
-		}
+		strbuf_release(&branch_ref);
 		strbuf_release(&buf);
+
+		return ret;
 	} else if (copy) {
 		if (!argc)
 			die(_("branch name required"));
-- 
2.38.0-167-g3030fd6006


  parent reply	other threads:[~2022-10-09 19:11 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-05 14:34 [PATCH 0/2] branch: support for at-refs like @{-1} in --edit-description, --set-upstream-to and --unset-upstream Rubén Justo via GitGitGadget
2022-09-05 14:34 ` [PATCH 1/2] branch: refactor edit_description command switch case Rubén Justo via GitGitGadget
2022-09-05 14:34 ` [PATCH 2/2] branch: support for at-refs like @{-1} Rubén Justo via GitGitGadget
2022-09-07  9:45 ` [PATCH v2 0/2] branch: support for shortcuts like @{-1}, completed Rubén Justo
2022-09-07  9:52   ` [PATCH v2 1/2] branch: refactor "edit_description" code path Rubén Justo
2022-09-07 20:25     ` Junio C Hamano
2022-09-07 21:24       ` Rubén Justo
2022-09-08  4:32         ` Rubén Justo
2022-09-07  9:53   ` [PATCH v2 2/2] branch: support for shortcuts like @{-1} completed Rubén Justo
2022-09-08  4:47   ` [PATCH v3 0/2] branch: support for shortcuts like @{-1}, completed Rubén Justo
2022-09-08  4:51     ` [PATCH v3 1/2] branch: refactor "edit_description" code path Rubén Justo
2022-09-08 20:57       ` [PATCH] branch: error codes for "edit_description" Rubén Justo
2022-09-08 21:45         ` Junio C Hamano
2022-09-08  4:53     ` [PATCH v3 2/2] branch: support for shortcuts like @{-1} completed Rubén Justo
2022-10-08  1:00     ` [PATCH v4] branch: support for shortcuts like @{-1}, completed Rubén Justo
2022-10-08  3:17       ` Eric Sunshine
2022-10-08  4:23         ` Junio C Hamano
2022-10-08  7:07         ` Rubén Justo
2022-10-08  7:23           ` Eric Sunshine
2022-10-08  9:12             ` Rubén Justo
2022-10-08 17:10               ` Eric Sunshine
2022-10-08 17:46                 ` Junio C Hamano
2022-10-08 20:48                   ` Rubén Justo
2022-10-08 23:28                 ` Rubén Justo
2022-10-09  6:46                   ` Eric Sunshine
2022-10-09 19:33                     ` Junio C Hamano
2022-10-09 22:27                       ` Rubén Justo
2022-10-08  4:17       ` Junio C Hamano
2022-10-08  9:04         ` Rubén Justo
2022-10-08 22:32       ` [PATCH v5] " Rubén Justo
2022-10-09  5:37         ` Junio C Hamano
2022-10-09 19:11         ` Junio C Hamano [this message]
2022-10-09 21:26           ` Rubén Justo
2022-10-10  0:38             ` Junio C Hamano
2022-10-10  6:05               ` Rubén Justo
2022-10-10 16:55                 ` Junio C Hamano
2022-10-10 18:08                   ` Rubén Justo
2022-10-10 23:24         ` [PATCH v6] " Rubén Justo

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=xmqqa6647qx2.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=rjusto@gmail.com \
    --cc=sunshine@sunshineco.com \
    /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).