Fix p_secstodate overflow handling (bug 22463)

  Here is a revised patch version.  This one detects the case where the 
conversion to time_t produces a negative result (with a static assertion 
to ensure this is the only case where the conversion is problematic); 
produces output in integer seconds since the epoch if __gmtime_r 
overflowed or the time_t value was negative, but the output would be less 
than 14 characters; still uses <overflow> in cases where the integer 
output would be 14 or more characters; adds a testcase.

Fix p_secstodate overflow handling (bug 22463).

The resolv/res_debug.c function p_secstodate (which is a public
function exported from libresolv, taking an unsigned long argument)
does:

        struct tm timebuf;
        time = __gmtime_r(&clock, &timebuf);
        time->tm_year += 1900;
        time->tm_mon += 1;
        sprintf(output, "%04d%02d%02d%02d%02d%02d",
                time->tm_year, time->tm_mon, time->tm_mday,
                time->tm_hour, time->tm_min, time->tm_sec);

If __gmtime_r returns NULL (because the year overflows the range of
int), this will dereference a null pointer.  Otherwise, if the
computed year does not fit in four characters, this will cause a
buffer overrun of the fixed-size 15-byte buffer.  With current GCC
mainline, there is a compilation failure because of the possible
buffer overrun.

I couldn't find a specification for how this function is meant to
behave, but Paul pointed to RFC 4034 as relevant to the cases where
this function is called from within glibc.  This patch makes the
overflow cases use integer seconds since the epoch unless that would
require 14 or more characters (and so be potentially ambiguous or
overflow the buffer), and <overflow> as the output string in other
overflow cases, in which case the patch also makes it set errno to
EOVERFLOW (__gmtime_r will already have done so in the case of NULL
return).  I couldn't persuade GCC to recognize the ranges of the
struct tm fields by adding explicit range checks with a call to
__builtin_unreachable if outside the range (this looks similar to
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80776>), so having added
a check for the year, this patch then disables the -Wformat-overflow=
warning for the sprintf call.

I do not know why this build failure should be new with mainline GCC
(that is, I don't know what GCC change might have introduced it, when
the basic functionality for such warnings was already in GCC 7).

I do not know if this is a security issue (that is, if there are
plausible ways in which a date before -999 or after 9999 from an
untrusted source might end up in this function).  The system clock is
arguably an untrusted source (in that e.g. NTP is insecure), but
probably not to that extent (NTP can't communicate such wild
timestamps), and Paul says uses from within glibc are limited to
32-bit inputs.

Tested with build-many-glibcs.py that this restores the build for arm
with mainline GCC.  Also tested for x86_64 and x86.

2017-11-21  Joseph Myers  <joseph@codesourcery.com>

	[BZ #22463]
	* resolv/res_debug.c: Include <libc-diag.h>.
	(p_secstodate): Use "<overflow>" as output and set errno to
	EOVERFLOW if year would not fit in four characters.
	(p_secstodate) [__GNUC_PREREQ (7, 0)]: Disable -Wformat-overflow=
	for sprintf call.

Fix p_secstodate overflow handling (bug 22463)

Commit Message

Comments

Patch