gpg-agent crashes when servicing concurrent connections

Bug #1746921 reported by Amul Shah
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnupg2 (Ubuntu)
Fix Released
Undecided
Unassigned
libgcrypt20 (Ubuntu)
New
Undecided
Unassigned

Bug Description

A defect in the gpg-agent causes it to crash while servicing multiple concurrent private decryption requests. This bug has been fixed in the upstream (see https://dev.gnupg.org/T3530) in GnuPG 2.2.4 and libgcrypt 1.8.2.

Users with larger keys will see this problem more often and persistently.

I made the following bug report to Debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882985
-------
As reported in the gnupg mailing list (thread links below), the
gpg-agent failed to decrypt secret keys for client applications when a
large number of concurrent requests were made.

libgcrypt takes care to manage secure memory. It allocates pools of
memory in SECMEM_BUFFER_SIZE size chunks. The first of these pools is
mlock()ed to prevent swapping. Certain secure memory allocation only
use memory from this first pool. If this first pool is full, libgcrypt
reported an ENOMEM error up to the caller.

In the case of the gpg-agent, it failed to decrypt private keys when it
received a large number of concurrent key decryption requests. These
decryption failures resulted in intermittment to short periods of
persistent failures in calling applications.

libgcrypt 1.8.1 contains the needed fixes and is compatile with GnuPG
2.1. Specific changes also need to be back ported to GnuPG 2.1 to take
advantage of these options. These changes are trivial to backport.

Mailing list threads:
https://lists.gnupg.org/pipermail/gnupg-devel/2017-June/032937.html
https://lists.gnupg.org/pipermail/gnupg-devel/2017-November/033280.html
-------

Related issues:
https://dev.gnupg.org/T3606 - failed to build S-Exp (off=0): Cannot allocate memory
https://dev.gnupg.org/T3473 - gnupg agent configurable backlog for sockets

Revision history for this message
Julian Andres Klode (juliank) wrote :

We are using gpg 2.2.4 in bionic+ and libgcrypt 1.8.1 in bionic, and 1.8.2 in cosmic; so that's fixed. Now, you say 1.8.2 once and 1.8.1 the other time, so I'm not sure if the problem is resolved in bionic or not - I think it mostly is?

Changed in libgcrypt20 (Ubuntu):
status: New → Fix Released
Changed in gnupg2 (Ubuntu):
status: New → Fix Released
Revision history for this message
Amul Shah (amul-shah) wrote :

libgcrypt 1.8.2 has the fixes. That 1.8.1 was a typo on my part. The problem is not fixed in bionic.

Amul Shah (amul-shah)
Changed in libgcrypt20 (Ubuntu):
status: Fix Released → New
Revision history for this message
Amul Shah (amul-shah) wrote :

Is there no interest in fixing this bug in an LTS release? We are avoiding using GnuPG on our Ubuntu LTS servers due to this bug.

no longer affects: libgcrypt
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.