Looks like the libgdbm allocates dynamic memory, then writes
it out to the GDBM file without fully initializing the
entire memory buffer.  Observe:

#include        <gdbm.h>
#include        <stdlib.h>

int main()
{
GDBM_FILE g;
char    *foo;
int     i;

        foo=malloc(8192);
        for (i=0; i<8192; i++)
                foo[i]= "secret"[i % 6];
        free(foo);
        g=gdbm_open("foo.dat", 0, GDBM_WRCREAT, 0644, 0);
        gdbm_close(g);
}


Link this with -lgdbm, and run it.  Afterwards, examine
foo.dat.  It should have "secret" splattered all over it.
This was tested with gdbm-1.7.3-19 and glibc-2.1.1-6. All
versions of Red Hat are probably vulnerable.

There are security implications here.  If your app handles
sensitive information, like passwords, in dynamic memory,
and then frees it, and if the freed memory is recycled and
allocated by libgdbm, your sensitive information can end up
being splattered in unused portions of your GDBM files.

Earlier this year MS got reamed for doing the same thing
with some Office files.

I ran some tests, it appears that libdb and libdb1 are not
vulnerable to the same problem.