[EFF]

The libgcrypt memory leak patch

Contents


Motivation

The general purpose cryptographic library libgcrypt has a serious memory leakage, which prevents application developers from developing clean software applications. It is impossible to release all the allocated memory and thus the applications are wasting memory and decreasing the system performance.

To fix this problem I developed a patch, which removes this memory leakage from gcrypt package. The patch adds a normal cleanup system, but is not accepted by the gcrypt maintainers for still unexplainable reasons. See the communication of my tries to build your own opinion if you want:

As other users have this problems as well and it was a lot of work, I hereby release the changes as a patchfile, which can be applied to the Subversion sources of the gcrypt library.

Download

You can get the current libgcrypt sources, when using following Subversion commandline:

svn checkout svn://cvs.gnupg.org/libgcrypt/trunk

To apply the patch you need to use (in the trunk directory):

patch -p0 <libgcrypt.diff

Download the patch: libgcrypt patch for Revision 1279, Gzipped version (ask for updates, if it does no longer apply cleanly).

Usage

What does this patch do?

The library uses a function gcry_control() for different tasks (e.g. initialization). This function gets a command type as argument. It already has an argument called GCRYCTL_FINALIZE, which is not yet used. The patch gives this command the usage which finalizes the library cleaning up all the internal allocations and resetting the whole to initial state.

Adding gcry_control(GCRYCTL_FINALIZE); after using the gcrypt library in your application is enough to fix the memory issue.

Compatibility:

The patch is fully up- and downwards compatible.

Some users of libgcrypt want to use the library in dynamic contexts, which means dynamically loading and unloading. It may be a good idea to build an destructor for the library with calls gcry_control(GCRYCTL_FINALIZE) to automatically free the allocated resources. This call would be perfectly valid also if the library has not been initialized, as in this case no deallocation would be done.
I do not use it that way and thus did not care for such things, but contrary to the statements of the libgcrypt maintainers it is possible to use the library in dynamic loading as well.

In the time since the first release lots of other changes have been included, which are required to build the software under different conditions (like on Windows systems). I was not even possible to include such minor code fixes and BUG fixes into the main library. I generally gave up to try now and do all the stuff in a patch file updated everytime conflicts occur. Very seldom some of the fixes have been found by the libgcrypt developers also and fixed in an comparable way (but my fix was rejected :-).
The changes include following:


Information about last update you can see in source of the HTML file.