* Bug report - ssh signing causes git tag -l malloc failed @ 2022-05-02 19:51 Brad Beam 2022-05-02 20:24 ` Junio C Hamano 0 siblings, 1 reply; 3+ messages in thread From: Brad Beam @ 2022-05-02 19:51 UTC (permalink / raw) To: git What did you do before the bug happened? (Steps to reproduce your issue) When using ssh signing `git tag -l --format='%(contents:body)' <tag>` returns `fatal: Out of memory, malloc failed (tried to allocate 18446744073709551323 bytes)` What did you expect to happen? (Expected behavior) The tag to be returned without crashing What happened instead? (Actual behavior) git crashed with the above error (`fatal: Out of memory, malloc failed (tried to allocate 18446744073709551323 bytes)`) What's different between what you expected and what actually happened? Anything else you want to add: ``` [14:23:54] (0):~/src/github.com/my/repo % git tag -sam v0.0.9 v0.0.9 [14:24:03] (0):~/src/github.com/my/repo % git -c log.showSignature=false tag -l --format='%(contents:body)' v0.0.9 fatal: Out of memory, malloc failed (tried to allocate 18446744073709551323 bytes) [14:24:27] (0):~/src/github.com/my/repo % git tag -sm v0.0.9-no-annotate v0.0.9-no-annotate [14:27:19] (0):~/src/github.com/my/repo % git -c log.showSignature=false tag -l --format='%(contents:body)' v0.0.9-no-annotate fatal: Out of memory, malloc failed (tried to allocate 18446744073709551323 bytes) [14:27:26] (128):~/src/github.com/my/repo % git tag -m v0.0.9-no-annotate-no-ssh v0.0.9-no-annotate-no-ssh [14:28:10] (0):~/src/github.com/my/repo % git -c log.showSignature=false tag -l --format='%(contents:body)' v0.0.9-no-annotate-no-ssh ``` Please review the rest of the bug report below. You can delete any lines you don't wish to share. [System Info] git version: git version 2.36.0 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh feature: fsmonitor--daemon uname: Darwin 20.6.0 Darwin Kernel Version 20.6.0: Tue Oct 12 18:33:42 PDT 2021; root:xnu-7195.141.8~1/RELEASE_X86_64 x86_64 compiler info: clang: 13.0.0 (clang-1300.0.29.30) libc info: no libc information available $SHELL (typically, interactive shell): /bin/zsh [Enabled Hooks] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Bug report - ssh signing causes git tag -l malloc failed 2022-05-02 19:51 Bug report - ssh signing causes git tag -l malloc failed Brad Beam @ 2022-05-02 20:24 ` Junio C Hamano 2022-05-03 1:02 ` Taylor Blau 0 siblings, 1 reply; 3+ messages in thread From: Junio C Hamano @ 2022-05-02 20:24 UTC (permalink / raw) To: Brad Beam; +Cc: git Brad Beam <brad.beam@b-rad.info> writes: Thanks for a report. > What did you do before the bug happened? (Steps to reproduce your issue) > > When using ssh signing `git tag -l --format='%(contents:body)' <tag>` returns `fatal: Out of memory, malloc failed (tried to allocate 18446744073709551323 bytes)` An obvious first follow-up question is if there is any difference in behaviour if another kind of signing (like PGP) is used. > What did you expect to happen? (Expected behavior) > > The tag to be returned without crashing > > What happened instead? (Actual behavior) > > git crashed with the above error (`fatal: Out of memory, malloc failed (tried to allocate 18446744073709551323 bytes)`) > > What's different between what you expected and what actually happened? > > Anything else you want to add: > > > ``` > [14:23:54] (0):~/src/github.com/my/repo > % git tag -sam v0.0.9 v0.0.9 Here, or before this step, there would probably have been something to say "No, I do not use the default PGP sign, but I want SSH sign"? For those who are reading this bug report and mistakenly thought it is a bug to show a self-recursive tag (like I did during my first reading of the report), the first v0.0.9 is merely an argument to the "-m" option, and the second v0.0.9 is the name of the newly created tag. We are creating a signed tag with v0.0.9 in the message that points at HEAD and has "tag v0.0.9" in the header, and storing the resulting tag at refs/tags/v0.0.9 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Bug report - ssh signing causes git tag -l malloc failed 2022-05-02 20:24 ` Junio C Hamano @ 2022-05-03 1:02 ` Taylor Blau 0 siblings, 0 replies; 3+ messages in thread From: Taylor Blau @ 2022-05-03 1:02 UTC (permalink / raw) To: Junio C Hamano; +Cc: Brad Beam, git On Mon, May 02, 2022 at 01:24:01PM -0700, Junio C Hamano wrote: > Brad Beam <brad.beam@b-rad.info> writes: > > Thanks for a report. > > > What did you do before the bug happened? (Steps to reproduce your > > issue) > > > > When using ssh signing `git tag -l --format='%(contents:body)' > > <tag>` returns `fatal: Out of memory, malloc failed (tried to > > allocate 18446744073709551323 bytes)` > > An obvious first follow-up question is if there is any difference in > behaviour if another kind of signing (like PGP) is used. It works when using gpg.format=openpgp, and breaks reliably when signing using OpenSSH. The simplest reproduction I could come up with is: git init repo ( cd repo >foo git add foo git commit -m "$(date)" git tag -sam foo foo ) I think the difference is that when signing with OpenPGP, the "foo" tag looks like this: $ git -C repo cat-file -p foo object d9b42c39c8520b2b9d62d67aa4138e1a28ce7aee type commit tag foo tagger Taylor Blau <me@ttaylorr.com> 1651538928 -0400 foo -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEuSAhSeE5DcWB+EsnUHZwBbY/KHsFAmJwe/AACgkQUHZwBbY/ [...] and with OpenSSH, the tag object looks like: $ git -C repo cat-file -p foo object 64303f1200e1114d91f250cede3245364b07fce7 type commit tag foo tagger Taylor Blau <me@ttaylorr.com> 1651538975 -0400 foo -----BEGIN SSH SIGNATURE----- U1NIU0lHAAAAAQAAARcAAAAHc3NoLXJzYQAAAAMBAAEAAAEBAPKMdi3zhEm/soWtUUR9bZ [...] note the missing newline after "-----BEGIN SSH SIGNATURE-----", which confuses ref-filter.c:find_subpos(). In particular, it seems to confuse the code near the comment "subject goes to first empty line before signature begins", since the OpenSSH-signed version of "foo" treats the entire message (including the signature itself) as the subject. That puts buf after sigstart, meaning that *nonsiglen gets assigned to a negative number and overflows. Luckily this just results in a bogus malloc call which crashes us, so I don't think this is meaningfully exploitable. The following diff seems to do the trick by restoring the intent of our "scooch batch 'eol' if it goes beyond 'sigstart'" to the case where we just assume the whole message is the subject. Folks more familiar with this code are more than welcome to chime in ;). --- 8< --- diff --git a/ref-filter.c b/ref-filter.c index 7838bd22b8..1d69e28d68 100644 --- a/ref-filter.c +++ b/ref-filter.c @@ -1376,12 +1376,14 @@ static void find_subpos(const char *buf, *sub = buf; /* subject goes to first empty line before signature begins */ if ((eol = strstr(*sub, "\n\n"))) { - eol = eol < sigstart ? eol : sigstart; + ; /* check if message uses CRLF */ } else if (! (eol = strstr(*sub, "\r\n\r\n"))) { /* treat whole message as subject */ eol = strrchr(*sub, '\0'); } + if (sigstart < eol) + eol = sigstart; buf = eol; *sublen = buf - *sub; /* drop trailing newline, if present */ --- >8 --- Thanks, Taylor ^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-05-03 1:10 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-02 19:51 Bug report - ssh signing causes git tag -l malloc failed Brad Beam 2022-05-02 20:24 ` Junio C Hamano 2022-05-03 1:02 ` Taylor Blau
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).