All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Subject: [PATCH 2/3] walker_fetch(): avoid raw array length computation
Date: Thu, 30 Jan 2020 04:52:32 -0500	[thread overview]
Message-ID: <20200130095232.GB840531@coredump.intra.peff.net> (raw)
In-Reply-To: <20200130095155.GA839988@coredump.intra.peff.net>

We compute the length of an array of object_id's with a raw
multiplication. In theory this could trigger an integer overflow which
would cause an under-allocation (and eventually an out of bounds write).

I doubt this can be triggered in practice, since you'd need to feed it
an enormous number of target objects, which would typically come from
the ref advertisement and be using proportional memory. And even on
64-bit systems, where "int" is much smaller than "size_t", that should
hold: even though "targets" is an int, the multiplication will be done
as a size_t because of the use of sizeof().

But we can easily fix it by using ALLOC_ARRAY(), which uses st_mult()
under the hood.

Signed-off-by: Jeff King <peff@peff.net>
---
 walker.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/walker.c b/walker.c
index 06cd2bd569..bb010f7a2b 100644
--- a/walker.c
+++ b/walker.c
@@ -261,12 +261,14 @@ int walker_fetch(struct walker *walker, int targets, char **target,
 	struct strbuf refname = STRBUF_INIT;
 	struct strbuf err = STRBUF_INIT;
 	struct ref_transaction *transaction = NULL;
-	struct object_id *oids = xmalloc(targets * sizeof(struct object_id));
+	struct object_id *oids;
 	char *msg = NULL;
 	int i, ret = -1;
 
 	save_commit_buffer = 0;
 
+	ALLOC_ARRAY(oids, targets);
+
 	if (write_ref) {
 		transaction = ref_transaction_begin(&err);
 		if (!transaction) {
-- 
2.25.0.515.gaba5347bc6


  parent reply	other threads:[~2020-01-30  9:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-30  9:51 [PATCH 0/3] some minor memory allocation cleanups Jeff King
2020-01-30  9:52 ` [PATCH 1/3] normalize_path_copy(): document "dst" size expectations Jeff King
2020-01-30 20:12   ` Taylor Blau
2020-01-31  8:45     ` Jeff King
2020-01-30  9:52 ` Jeff King [this message]
2020-01-30  9:53 ` [PATCH 3/3] traverse_trees(): use stack array for name entries Jeff King
2020-01-30 14:57   ` Elijah Newren
2020-01-31  9:29     ` Jeff King
2020-01-31 18:52       ` Elijah Newren
2020-02-01 11:39         ` [PATCH] tree-walk.c: break circular dependency with unpack-trees Jeff King
2020-02-01 15:32           ` Elijah Newren
2020-01-30 14:59 ` [PATCH 0/3] some minor memory allocation cleanups Elijah Newren
2020-01-30 23:03 ` Taylor Blau

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=20200130095232.GB840531@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.