git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH 4/4] remote: always allocate branch.push_tracking_ref

From
Jeff King <peff@peff.net>
Date
Jan 19, 2026, 05:23 UTC
Message-ID
<20260119052320.GD1991523@coredump.intra.peff.net>
In-Reply-To
<20260119051858.GA1991308@coredump.intra.peff.net>

In branch_get_push(), we usually allocate a new string for the @{push} ref, but will not do so in push.default=upstream mode, where we just pass back the result of branch_get_upstream() directly.

This led to a hacky memory management scheme in e291c75a95 (remote.c: add branch_get_push, 2015-05-21): we store the result in the push_tracking_ref field of a "struct branch", under the assumption that the branch struct will last until the end of the program. So even though the struct doesn't know if it has an allocated string or not, it doesn't matter because we hold on to it either way.

But that assumption was violated by f5ccb535cc (remote: fix leaking config strings, 2024-08-22), which added a function to free branch structs. Any struct which is fed to branch_release() is at risk of leaking its push_tracking_ref member.

I don't think this can actually be triggered in practice. We rarely actually free the branch structs, and we only fill in the push_tracking_ref string lazily when it is needed. So triggering the leak would require a code path that does both, and I couldn't find one.

Still, this is an ugly trap that may eventually spring on us. Since there is only one code path in branch_get_push() that doesn't allocate, let's just have it copy the string. And then we know that push_tracking_ref is always allocated, and we can free it in branch_release().

Signed-off-by: Jeff King <peff@peff.net>
---
 remote.c | 7 ++++---
 remote.h | 2 +-
 2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/remote.c b/remote.c
index e191b0ff6e..3e9d9b3e1f 100644
--- a/remote.c
+++ b/remote.c
@@ -272,6 +272,7 @@ static void branch_release(struct branch *branch)
 	free((char *)branch->refname);
 	free(branch->remote_name);
 	free(branch->pushremote_name);
+	free(branch->push_tracking_ref);
 	merge_clear(branch);
 }
 
@@ -1883,8 +1884,8 @@ static char *tracking_for_push_dest(struct remote *remote,
 	return ret;
 }
 
-static const char *branch_get_push_1(struct repository *repo,
-				     struct branch *branch, struct strbuf *err)
+static char *branch_get_push_1(struct repository *repo,
+			       struct branch *branch, struct strbuf *err)
 {
 	struct remote_state *remote_state = repo->remote_state;
 	struct remote *remote;
@@ -1924,7 +1925,7 @@ static const char *branch_get_push_1(struct repository *repo,
 		return tracking_for_push_dest(remote, branch->refname, err);
 
 	case PUSH_DEFAULT_UPSTREAM:
-		return branch_get_upstream(branch, err);
+		return xstrdup_or_null(branch_get_upstream(branch, err));
 
 	case PUSH_DEFAULT_UNSPECIFIED:
 	case PUSH_DEFAULT_SIMPLE:
diff --git a/remote.h b/remote.h
index 0ca399e183..fc052945ee 100644
--- a/remote.h
+++ b/remote.h
@@ -331,7 +331,7 @@ struct branch {
 
 	int merge_alloc;
 
-	const char *push_tracking_ref;
+	char *push_tracking_ref;
 };
 
 struct branch *branch_get(const char *name);
-- 
2.53.0.rc0.338.g08aa8a9473
Previous: Patrick SteinhardtNext: Patrick Steinhardt
Message 11 of 15 in “memory leaks in remote.c”
  1. 0/4 memory leaks in remote.cJeff King, Jan 19, 2026
  2. 1/4 remote: return non-const pointer from error_buf()Jeff King, Jan 19, 2026
  3. Patrick SteinhardtJan 19, 2026
  4. Junio C HamanoJan 20, 2026
  5. Jeff KingJan 20, 2026
  6. Junio C HamanoJan 20, 2026
  7. 2/4 remote: drop const return of tracking_for_push_dest()Jeff King, Jan 19, 2026
  8. Patrick SteinhardtJan 19, 2026
  9. 3/4 remote: fix leak in branch_get_push_1() with invalid "simple" configJeff King, Jan 19, 2026
  10. Patrick SteinhardtJan 19, 2026
  11. 4/4 remote: always allocate branch.push_tracking_refJeff King, Jan 19, 2026
  12. Patrick SteinhardtJan 19, 2026
  13. Triangular workflowHarald Nordgren, Jan 19, 2026
  14. Jeff KingJan 20, 2026
  15. Junio C HamanoJan 20, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.