gpg: Fix bug parsing a zero length user id.

* g10/getkey.c (get_user_id): Do not call xmalloc with 0.

* common/xmalloc.c (xmalloc, xcalloc): Take extra precaution not to
pass 0 to the arguments.
--

The problem did not occur in 1.x because over there the xmalloc makes
sure to allocate at least one byte.  With 2.x for most calls the
xmalloc of Libgcrypt is used and Libgcrypt returns an error insteead
of silent allocating a byte.  Thus gpg 2.x bailed out with an
"Fatal: out of core while allocating 0 bytes".

The extra code in xmalloc.c is for more robustness for the other
xmalloc calls.

2 files changed, 21 insertions, 3 deletions

diff --git a/common/xmalloc.c b/common/xmalloc.c
index 999ec00f8..3378e487b 100644
--- a/common/xmalloc.c
+++ b/common/xmalloc.c
@@ -47,7 +47,15 @@ out_of_core(void)
 void *
 xmalloc( size_t n )
 {
-    void *p = malloc( n );
+    void *p;
+
+    /* Make sure that xmalloc (0) works.  This is the same behaviour
+       has in gpg 2.x.  Note that in contrast to this code, Libgcrypt
+       (and thus most xmallocs in gpg 2.x) detect the !n and bail out.  */
+    if (!n)
+      n = 1;
+
+    p = malloc( n );
     if( !p )
 	out_of_core();
     return p;
@@ -65,7 +73,14 @@ xrealloc( void *a, size_t n )
 void *
 xcalloc( size_t n, size_t m )
 {
-    void *p = calloc( n, m );
+    void *p;
+
+    if (!n)
+      n = 1;
+    if (!m)
+      m = 1;
+
+    p = calloc( n, m );
     if( !p )
 	out_of_core();
     return p;
diff --git a/g10/getkey.c b/g10/getkey.c
index 458672a09..707a106e4 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -2775,7 +2775,10 @@ get_user_id (u32 * keyid, size_t * rn)
 	    {
 	      if (a->keyid[0] == keyid[0] && a->keyid[1] == keyid[1])
 		{
-		  p = xmalloc (r->len);
+                  /* An empty string as user id is possible.  Make
+                     sure that the malloc allocates one byte and does
+                     not bail out.  */
+		  p = xmalloc (r->len? r->len : 1);
 		  memcpy (p, r->name, r->len);
 		  *rn = r->len;
 		  return p;