Follow-up to Crashes with gpg-agent 2.1.18

[Shah, Amul]

> From: Shah, Amul Sent: Monday, April 10, 2017 4:32 PM
> > From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] Sent: Monday,
> > April 10, 2017 3:55 PM
> >
> > On Mon 2017-04-10 16:10:20 +0000, Shah, Amul wrote:
> > >> From: Shah, Amul Sent: Wednesday, April 05, 2017 11:24 AM
> > >> Subject: Follow-up to Crashes with gpg-agent 2.1.18
> > >>
> > >> I think that this is a follow up to a thread from January (last
> > >> email in thread https://lists.gnupg.org/pipermail/gnupg-devel/2017-January/032486.html)
> > because it started with me seeing the message "Ohhhh jeeee: ... this is a bug
> > (sexp.c:1433:do_vsexp_sscan)" in the gpg-agent log. Now in trying to
> > reproduce the error, the gpg- agent hits a PKDECRYPT failure claiming
> > that it cannot allocate memory.
> > >>
> > >> I tried debugging the error down into libgcrypt, but could not see
> > >> where things could go wrong unless the memory manager is not
> > npthread
> > >> safe. Since I made no progress, I'm sending this mail along with a
> > >> test case similar to the one from the previous thread.
> > >>
> > >> Note that we don't encounter this problem with older GnuPG
> > >> versions, GnuPG 2.15 and earlier.
> > >>
> > >> Could someone take a look at this or give me some pointers on how I
> > >> can help myself?
> > >
> > > [amul:1] No hints or suggestions? I guess I'll file a bug report
> > > instead and downgrade my Software.
> >
> > Could you try with the version in debian experimental (2.1.20)?  I
> > believe the "Ohhh jeeee" crash was fixed upstream by commit
> > e175152ef7515921635bf1e00383e812668d13fc
> >
> >         --dkg
>
> I didn't try 2.20 since I didn't see anything promising in git log. I will
> give it a try since you asked. Next time I write back, I'll try to include
> some more useful details like a stack trace of all threads at the point of
> failure.
>
> Debian 9's gnupg-2.18-6 has that patch (see below). I thought you were the
> one who put it in. :)
> $ apt-get source gnupg
> $ cd gnupg2-2.1.18
> $ cat debian/patches/0017-agent-Fix-double-free.patch
> From: Justus Winter <justus at g10code.com>
> Date: Wed, 25 Jan 2017 13:51:57 +0100
> Subject: agent: Fix double free.
[snip]
[amul]

No luck with GPG 2.1.20. I turned up the agent logging all the way
(--debug-level guru --debug-all) and repeated my testing. In the last
few lines we see the bug message.

  13817 2017-04-11 16:54:29 gpg-agent[973941] DBG: rsa_decrypt    => Success
  13818 2017-04-11 16:54:29 gpg-agent[973941] DBG: plain: [data="\x02\xc1-\xd1'\xaa\x13\x96`\x0ebH\x8d\xf0\x18\xc3q\xf6\xcaw\x1da\x8d\xe1\xcc\x9a\xc0\xe5\xfa\xf9\xa2\x14\xea!\x98\xaa1\xad\xe5A\xf4\xe1sXc\xb6b\x
  13819 2017-04-11 16:54:29 gpg-agent[973941] DBG: chan_9 -> [ 44 20 28 35 3a 76 61 6c 75 65 32 35 35 3a 02 c1 ...(261 byte(s) skipped) ]
  13820 2017-04-11 16:54:29 gpg-agent[973941] DBG: chan_9 -> OK
  13821 2017-04-11 16:54:29 gpg-agent[973941] DBG: chan_9 <- [eof]
  13822 2017-04-11 16:54:29 gpg-agent[973941] DBG: rsa_decrypt  res:+02c12dd127aa1396600e62488df018c371f6ca771d618de1cc9ac0e5faf9a214 \
  13823 2017-04-11 16:54:29 gpg-agent[973941] DBG:                   ea2198aa31ade541f4e1735863b6628d840e471f654163ed444097553755db79 \
  13824 2017-04-11 16:54:29 gpg-agent[973941] DBG:                   739f476f56fa57400333a7612198865275e41a7ab427434df30d931e272322c3 \
  13825 2017-04-11 16:54:29 gpg-agent[973941] DBG:                   a7c722a9b524c62ba90837f39627bce1afe26050e9a55e9d52af5135d876c9f3 \
  13826 2017-04-11 16:54:29 gpg-agent[973941] DBG:                   3489d0ec4295c515813f2cb866f1424010b9a24e5d0e7ee40ec833d75229488f \
  13827 2017-04-11 16:54:29 gpg-agent[973941] DBG:                   67473945b2484cb2e1448c9f278fff09bf3e5507cb1067a32d439ca82c229ac4 \
  13828 2017-04-11 16:54:29 gpg-agent[973941] DBG:                   b96c82419e1a0c74c8a64fd0f5cdade98464a5f4a95a3beb4f888a0009e61826 \
  13829 2017-04-11 16:54:29 gpg-agent[973941] DBG:                   d423ecd9250af4bdb50ebd83e64309228d3687d7f9e9919fa1ecd8a3431195
  13830 2017-04-11 16:54:29 gpg-agent[973941] DBG: rsa_decrypt    => Success
  13831 2017-04-11 16:54:29 gpg-agent[973941] DBG: plain: [data="\x02\xc1-\xd1'\xaa\x13\x96`\x0ebH\x8d\xf0\x18\xc3q\xf6\xcaw\x1da\x8d\xe1\xcc\x9a\xc0\xe5\xfa\xf9\xa2\x14\xea!\x98\xaa1\xad\xe5A\xf4\xe1sXc\xb6b\x
  13832 2017-04-11 16:54:29 gpg-agent[973941] DBG: chan_50 -> [ 44 20 28 35 3a 76 61 6c 75 65 32 35 35 3a 02 c1 ...(261 byte(s) skipped) ]
  13833 2017-04-11 16:54:29 gpg-agent[973941] DBG: chan_50 -> OK
  13834 2017-04-11 16:54:29 gpg-agent[973941] DBG: chan_50 <- [eof]
  13835 2017-04-11 16:54:29 gpg-agent[973941] DBG: rsa_decrypt  res: [out of core]
  13836 2017-04-11 16:54:29 gpg-agent[973941] Ohhhh jeeee: ... this is a bug (../../src/sexp.c:1433:do_vsexp_sscan)
(I can share the full log if that helps)

I drilled into libgcrypt and saw that there is a lock, use_m_guard, but
the threaded gpg-agent is not using it. Not using the memory manager's
thread lock looks like a problem. I don't see where the current code
would enable the memory guard (via GCRYCTL_ENABLE_M_GUARD).
Am I barking up the wrong tree?

Amul
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.