Thanks. I appreciate that you look at the code.

Given that the code in question is preety old and this is the first problem
report on it, I hesitate to apply the patch as is. You you mind if I make it
netbsd specific?

Any reason why stdin and stdout are re-opened earlier than stderr?
I would use

  if (fstat (STDIN_FILENO, &statbuf) == -1 && errno ==EBADF)
    open ("/dev/null",O_RDONLY);
  if (fstat (STDOUT_FILENO, &statbuf) == -1 && errno ==EBADF)
    open ("/dev/null",O_RDONLY);
  if (fstat (STDERR_FILENO, &statbuf) == -1 && errno ==EBADF)
    open ("/dev/null",O_RDONLY);

right after the "Stuart code" line.

ok sir, i will abide by what you say.

I include both of you as i noticed that you both are active code checkers in
Gcrypt, thats the only reason, anyways thanks for lookup.

To disable the visibility feature the GCRY_USE_VISIBILITY macro is used. That
is figured out by configure and thus the place to fix it. I can't accept this
patch.

An no reminders after 3 days please. We are all unpaid volunteers.

Such leaks won't be fixed in an old branch. Please report only for stable and
master. Is there a reason why you always include aheinecke in the nosy list?
And please do not assign a bug to a specific person - keep it unspecified.

Reminder for bug review.

Reminder for bug review.

Reminder for bug review.

On 32 bit, a problem was just discovered in the kernel development branch: see
discussion in https://lkml.org/lkml/2014/8/26/59.

The base line is that the bit shift in drbg_max_addtl and drbg_max_requests are
stored in a size_t which is 32 bit on 32 bit machines. Yet, the bit shift is
larger than 32 bit. It will be fixed in the next installment of the patch.

D243: 480_pubkey.patch

File: cipher/pubkey.c

Bug No. : 1

Function: gcry_pk_encrypt
Line of error: 2879

Resource leak occurs as variable "data" with assigned memory is not freed
before going out of scope , which causes memory leak.

Libgcrypt version 1.5.4 code:

  rc = sexp_data_to_mpi (s_data, &data, &ctx);
  if (rc)
    goto leave;

-> here when the code flow jumps to leave,"data" goes out of scope ,which
despite of being allocated memory is not freed before going out of scope.

Recommended Code:

rc = sexp_data_to_mpi (s_data, &data, &ctx);
if (rc)

    {
      mpi_free (data);
      data = NULL;
      goto leave;
    }

Here it is ensured that "data" is freed ,preventing any chances of leak

Bug No. : 2

Function: gcry_pk_genkey
Line of error: 3623

Resource leak occurs as variable "string" with assigned memory is not freed
before going out of scope , which causes memory leak.

Libgcrypt version 1.5.4 code:

   if (!arg_list)
        {
          rc = gpg_err_code_from_syserror ();
          goto leave;
        }

-> here when the code flow jumps to leave,"string" goes out of scope ,which
despite of being allocated memory is not freed before going out of scope.

Recommended Code:

if (!arg_list)

{
  rc = gpg_err_code_from_syserror ();
  gcry_free (string)
  goto leave;
}

I am attaching a patch for the above raised bugs.

D241: 478_primegen.patch

D238: 474_patch-ab

D231: 473_v7-0007-User-interface-to-DRBG.patch

D232: 472_v7-0006-DRBG-specific-gcry_control-requests.patch

D233: 471_v7-0005-Function-definitions-for-gcry_control-callbacks.patch

D234: 470_v7-0004-Invoke-DRBG-from-common-libgcrypt-RNG-code.patch

D235: 469_v7-0003-Function-definitions-of-interfaces-for-random.c.patch

D236: 468_v7-0001-SP800-90A-Deterministic-Random-Bit-Generator.patch

D237: 467_v7-0002-Compile-DRBG.patch

To go into master.

Please send a DCO to gcrypt-devel and ask for a review of the code.

fixed. Thanks.

Done for master and 1.6.

Okay, but probaly only in master.

ported to 1.6.

Yes you may , as it would be quite helpful in further vigilance :)

This is a false positive of your scanner. BUFFER may very well be NULL if the
caller used NULL for the buffer arg (which is the format string). Using NULL
for the format is not defined (cf. printf).

The condition testing BUFFER before calling is merely a general failsafe pattern
of a commly used code snippet.

If it helps you scanner to avoid such fails positive I can do an explicit check
for buffer being NULL. Shall I do that?

Fixed in master. Will be ported to 1.6.

Fixed in master.

Fixed with 1700

Duplicate of T1700

Thanks for looking at this. However, please do not file separate bug reports
for similar problems. This is just too much overhead. Frankly, I 'd would
appreciate that such audit results are send to the mailing list.

The suggested fix is not suitable because this function or its callers returns
an error code and should just do this. An assert is only to be used to make
sure that nothing unexpected happens. You have shown that this may indeed
happen (by using wrong call args or a malloc failure) and thus this needs more
work. Given that such NULL dereference are not a critical security problems,
this won't be fixed for old Libgcrypt versions as 1.5. Instead I will apply a
fix to master (1.7) and backport it to stable (1.6).

D215: 464_elgamal.patch

D214: 463_dsa.patch

D213: 462_sexp.patch

Updated by 1697.

FWIW, I checked my POSIX 2001 standard and it does not define -p. The
GNU manual for uname however has to say:

`-m'
`--machine'

     Print the machine hardware name (sometimes called the hardware
     class or hardware type).

`-p'
`--processor'

Print the processor type (sometimes called the instruction set
architecture or ISA).  Print `unknown' if the kernel does not make
this information easily available, as is the case with Linux
kernels.

Fix has been pushed for 1.6 and master. Thanks,

Thanks for that good description. Fixes pushed to master and 1.6. I can't test
it, though.