Follow-up to Crashes with gpg-agent 2.1.18

[Shah, Amul]

> 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> >> sts.gnupg.org%2Fpipermail%2Fgnupg-devel%2F2017-
> January%2F032516.html&
> >>
> data=01%7C01%7CAmul.Shah%40fisglobal.com%7Cdcd940ffdc2e4e47cf0608
> d480
> >>
> 4b87dc%7Ce3ff91d834c84b15a0b418910a6ac575%7C0&sdata=qqETArFrGjgm
> gOQFu
> >> 30JIawLjopx0VegGTzapNmtxco%3D&reserved=0) 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.

* agent/cache.c (agent_store_cache_hit): Make sure the update is
atomic.
--
Previously, the function freed the last key, and duplicated the new
key after doing that.  There is a chance, however, that calling the
allocator surrenders control to a different thread, causing a double
free if a different thread also calls this function.

To make sure the update is atomic under the non-preemptive thread
model, we must make sure not to surrender control to a different
thread.  Therefore, we avoid calling the allocator during the
update.

Signed-off-by: Justus Winter <justus at g10code.com>
(cherry picked from commit e175152ef7515921635bf1e00383e812668d13fc)
....

Thanks,
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.