Re: What's cooking in git.git (Jan 2019, #01; Mon, 7)

From: "Martin Ågren" <martin.agren@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: What's cooking in git.git (Jan 2019, #01; Mon, 7)
Date: Thu, 10 Jan 2019 20:03:54 +0100	[thread overview]
Message-ID: <CAN0heSowybpM6BULwkjXVWSegGd0cM3LLfmXqGjj5qh3Ev9ArA@mail.gmail.com> (raw)
In-Reply-To: <20190110010238.GK423984@genre.crustytoothpaste.net>

On Thu, 10 Jan 2019 at 02:03, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> On Wed, Jan 09, 2019 at 10:06:08PM +0100, Martin Ågren wrote:
> > i.e., we copy sizeof(struct object_id) (=32) bytes. Which is 12 more
> > than what is known to be safe. For this particular input data, we read
> > outside allocated memory.
>
> Anything pointing to a struct object_id has to support at least
> GIT_MAX_RAWSZ bytes, and that code doesn't, because it's a tree buffer.
>
> I ran into this later on in my SHA-256 work and have a series that fixes
> the tree-walk code, but it's a bit involved and requires copying the
> struct object_id out of the buffer.
>
> I thought we were going to be triggering this case only with some new
> code I was introducing, but apparently somebody else got there first.

> As for my series, I'll need to run the testsuite on it, but I'll try to
> get it out tonight or at the latest tomorrow if people want to use that
> instead.

Cool. I should have known that you had something in the pipeline. Thanks
for working on this.