Git development
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH 5/5] xdiff: NUL-terminate buffers read by read_mmfile()
Date: Wed, 30 Sep 2026 17:32:55 +0200	[thread overview]
Message-ID: <ar0rp1cSIKuCMZyQ@pks.im> (raw)
In-Reply-To: <20260929065504.GE1697497@coredump.intra.peff.net>

On Tue, Sep 29, 2026 at 02:55:04AM -0400, Jeff King wrote:
> Since an mmfile_t is a ptr/len pair, our read_mmfile() allocates exactly
> the number of bytes we claim to store. But in many other places in Git,
> we add an extra NUL "just in case", which can help avoid read overruns
> due to off-by-ones or the use of string functions.
> 
> I don't know of any path that would benefit from this, but I noticed it
> while converting ll_ext_merge() to use read_mmfile(), since its original
> code did add a NUL byte (even though I cannot find any case where it
> would have mattered). Let's teach read_mmfile() to add this defensive
> NUL; it probably doesn't help anything, but nor should it hurt.
> 
> Note that the matching read_mmblob() doesn't need the same treatment.
> Its buffers already have a NUL from the object-reading code (which uses
> the same defensive trick).
> 
> As a bonus, we can get rid of the hack in read_mmfile() to handle empty
> files by allocating a single byte.
> 
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This one is obviously optional, which is why I put it last.

Hm, I'm somewhat indifferent here. It always feels a bit weird to be
this defensive because "programming errors", as the next question then
is "but what about all the other errors where we're not defensive?" But
the xdiff code is complex enough with a bunch of pointer arithmetics, so
maybe it's not even that bad of an idea.

That being said, I feel like a better course of action could be to use a
fuzzer for this code, because as far as I'm aware we have none yet, and
that would potentially shake out a bunch of bugs. But that still doesn't
really help us to catch platform-specific bugs due to different integer
sizes.

The counterargument is that before your 3/5 we used to use xmallocz, so
you're essentially just reinstating the previous safety guards.

> diff --git a/xdiff-interface.c b/xdiff-interface.c
> index bc340d5a8a..b3e9f1952b 100644
> --- a/xdiff-interface.c
> +++ b/xdiff-interface.c
> @@ -166,7 +166,7 @@ int read_mmfile(mmfile_t *ptr, const char *filename)
>  	if (!(f = fopen(filename, "rb")))
>  		return error_errno("Could not open %s", filename);
>  	sz = xsize_t(st.st_size);
> -	ptr->ptr = xmalloc(sz ? sz : 1);
> +	ptr->ptr = xmallocz(sz);

I was staring at this code a while before I noticed the added `z` at the
end of this function.

Patrick

  reply	other threads:[~2026-09-30 15:33 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-29  6:49 [PATCH 0/5] use size_t for xdiff mmfile_t Jeff King
2026-09-29  6:51 ` [PATCH 1/5] xdiff: clean up read_mmfile() allocations on error Jeff King
2026-09-29 18:37   ` Junio C Hamano
2026-09-29  6:52 ` [PATCH 2/5] xdiff: replace mmbuffer_t with mmfile_t Jeff King
2026-09-29 11:08   ` D. Ben Knoble
2026-09-29 18:39   ` Junio C Hamano
2026-09-30 15:32   ` Patrick Steinhardt
2026-09-30 22:46     ` Jeff King
2026-10-01 15:40       ` Junio C Hamano
2026-09-29  6:54 ` [PATCH 3/5] xdiff: use size_t for buffer sizes Jeff King
2026-09-29  6:54 ` [PATCH 4/5] merge-ll: use read_mmfile() to read external merge results Jeff King
2026-09-29 19:22   ` Junio C Hamano
2026-09-29 20:11     ` Jeff King
2026-09-29 20:41       ` Jeff King
2026-09-29 20:43         ` [PATCH 6/5] merge-ll: handle external driver status before reading result Jeff King
2026-09-29 20:44         ` [PATCH 7/5] merge-ll: report an error when reading external merge results fails Jeff King
2026-09-29 21:19           ` Junio C Hamano
2026-09-29 21:49             ` Jeff King
2026-09-30 18:01               ` Junio C Hamano
2026-09-30 22:41                 ` Jeff King
2026-10-01 15:37                   ` Junio C Hamano
2026-09-30 15:33   ` [PATCH 4/5] merge-ll: use read_mmfile() to read external merge results Patrick Steinhardt
2026-09-30 22:50     ` Jeff King
2026-09-29  6:55 ` [PATCH 5/5] xdiff: NUL-terminate buffers read by read_mmfile() Jeff King
2026-09-30 15:32   ` Patrick Steinhardt [this message]
2026-09-30 19:59     ` Junio C Hamano
2026-09-30 22:49     ` Jeff King
2026-09-30 23:43 ` [PATCH v2 0/7] use size_t for xdiff mmfile_t Jeff King
2026-09-30 23:44   ` [PATCH v2 1/7] xdiff: clean up read_mmfile() allocations on error Jeff King
2026-09-30 23:44   ` [PATCH v2 2/7] xdiff: replace mmbuffer_t with mmfile_t Jeff King
2026-09-30 23:44   ` [PATCH v2 3/7] xdiff: use size_t for buffer sizes Jeff King
2026-09-30 23:44   ` [PATCH v2 4/7] xdiff: NUL-terminate buffers read by read_mmfile() Jeff King
2026-10-01 13:15     ` Patrick Steinhardt
2026-09-30 23:44   ` [PATCH v2 5/7] merge-ll: use read_mmfile() to read external merge results Jeff King
2026-10-01 13:15     ` Patrick Steinhardt
2026-09-30 23:44   ` [PATCH v2 6/7] merge-ll: handle external driver status before reading result Jeff King
2026-09-30 23:44   ` [PATCH v2 7/7] merge-ll: report an error when reading external merge results fails Jeff King

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=ar0rp1cSIKuCMZyQ@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    /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