GNU bug report logs - #25757
Fix segfault when adns_strerror() is called with a value, for which there is no message defined

Previous Next

Package: adns;

Reported by: Tomas Hozza <thozza <at> redhat.com>

Date: Thu, 16 Feb 2017 16:36:02 UTC

Severity: normal

Full log


View this message in rfc822 format

From: Ian Jackson <ijackson <at> chiark.greenend.org.uk>
To: Tomas Hozza <thozza <at> redhat.com>
Cc: 25757 <at> debbugs.gnu.org
Subject: bug#25757: Fix segfault when adns_strerror() is called with a value, for which there is no message defined
Date: Wed, 1 Mar 2017 18:43:54 +0000
(CCing the bug report again.  Please let us keep the bug in the CC, so
that others can see and help and so on.  Thanks.)

Tomas Hozza writes ("Re: bug#25757: Fix segfault when adns_strerror() is called with a value, for which there is no message defined"):
> The reproducer is actually also:
> 
> int main(void) {
>     printf("%s\n", adns_strerror(adns_s_inconsistent));
>     printf("%s\n", adns_strerror(adns_s_max_misconfig));
> }
> 
> which uses values defined by adns.

The header file says:

> >     You MUST NOT call these functions with status values
> >     not returned by the same adns library.

These values were not `returned'.  Perhaps this could be clarified in
the documentation.

> In my opinion NULL is not really a good option, as the function is expected to return a string and therefore people will usually use it in print functions. Maybe the same approach as used by strerror() could be used:

The real question for me is why someone would do
    adns_strerror(adns_s_inconsistent))
at all.  If we knew that we might be able to help them out.  I don't
think this is useful.  adns will never return that value from an
actual adns function.

Is it possible that in fact this whole thing is the result of a static
analysis tool observing that this code might segfault ?

> "The strerror(), strerror_l(), and the GNU-specific strerror_r() functions return the appropriate error description string, or an "Unknown error nnn" message if the error number is unknown."
> 
> This means the call would return the message with the error number, so that it is not lost.

This would be an option but this would involve dynamic allocation and
there is no good place to memoise the result.

> Do you want me to modify the fix or you'll implement something on your own?

Do you have an answer to my point about memoisation ?

Thanks,
Ian.




This bug report was last modified 8 years and 112 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.