Re: Git Bug Report: out of memory using git tag
- From
Philippe Blain <levraiphilippeblain@gmail.com>
- Date
- Nov 2, 2022, 00:41 UTC
- Message-ID
- <38d50c30-c6a3-5989-6e01-47c5467d9d6b@gmail.com>
- In-Reply-To
- <Y2EPgICMsmzKvCC8@coredump.intra.peff.net>
Hi,
Le 2022-11-01 à 08:22, Jeff King a écrit :
Show 36 quoted lines
> On Fri, Oct 28, 2022 at 03:29:33PM -0700, Martin Englund wrote:
>
>> What did you do before the bug happened? (Steps to reproduce your issue)
>> I created a signed tag (git tag -s) using a ssh-agent key and then ran
>> git tag -l --format '%(contents:body)' v0.6.1
>>
>> What did you expect to happen? (Expected behavior)
>> I get the output
>>
>> What happened instead? (Actual behavior)
>> fatal: Out of memory, malloc failed (tried to allocate
>> 18446744073709551266 bytes)
>
> Thanks for the report. This looks like pointer or size_t arithmetic that
> has gone negative. Here's a minimal reproduction:
>
> {
> echo subject
> echo "-----BEGIN PGP SIGNATURE-----"
> } | git tag -F - foo
> git tag -l --format='%(contents:body)' foo
>
> The issue isn't unique to pgp signatures; the problem is in the parsing
> done by ref-filter's find_subpos(), so any signature type exhibits the
> problem. At the end of that function we do:
>
> *nonsiglen = sigstart - buf;
>
> but "buf" has moved beyond "sigstart". Presumably because it uses
> strstr() to look for end-of-line in buf. Since there isn't one before
> the signature begins, we go to the end of the signature.
>
> The bug bisects to 9f75ce3d8f (ref-filter: handle CRLF at end-of-line
> more gracefully, 2020-10-29). Before then, I think our loop was careful
> about moving past the start of the signature. Author cc'd.
> Thanks for letting me know, and for the simple reproducer, that's very useful. I'll try to find time to fix that this week, but can't promise anything.
Phil.