Page MenuHome GnuPG

Dereferencing of a NULL pointer may occur in file "src/sexp.c" in function "vsexp_sscan" inside the for loop on line 1071
Closed, ResolvedPublic


File : src/sexp.c
line no.:1071

libgcrypt version 1.5.4 code:

for (p = buffer, n = length; n; p++, n--)

      if (tokenp && !hexfmt)

->Here in the above for loop the pointer variable p is being looped from
'buffer' to 'buffer+length' , however the a problem arises when 'buffer' is
NULL, as the p will be NULL then and p is being dereferenced later inside the
loop body.

The line suggesting the possibility of buffer being 'NULL' is

if (buffer && length && gcry_is_secure (buffer))

    c.sexp = gcry_malloc_secure (sizeof *c.sexp + c.allocated - 1);
    c.sexp = gcry_malloc (sizeof *c.sexp + c.allocated - 1);

Here if buffer is NULL no action to re-allocate some NON-NULL value is taken so
buffer might be NULL.

So in order to prevent this issue from arising the following code changes can be

Recommended code:

for (p = buffer, n = length; p!=NULL && n; p++, n--)

      if (tokenp && !hexfmt)

I am attaching a patch for the above mentioned bug.



Related Objects

Event Timeline

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?

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

Okay, but probaly only in master.

werner closed this task as Resolved.