Bug 22463 - p_secstodate overflow handling
Summary: p_secstodate overflow handling
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: network (show other bugs)
Version: 2.26
: P2 normal
Target Milestone: 2.27
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-20 19:00 UTC by Joseph Myers
Modified: 2018-10-22 12:54 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Myers 2017-11-20 19:00:45 UTC
The resolv/res_debug.c function p_secstodate 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 (the estimate of possible output size is excessive because GCC doesn't know the range limits on most of the fields - putting checks on the ranges that call __builtin_unreachable or abort on failure would probably suffice to tell GCC the possible size of output for fields other than tm_year - but for tm_year there is a genuine buffer overrun bug if called for times that involve large years):

res_debug.c:1069:23: error: '%02d' directive writing between 2 and 11 bytes into a region of size between 4 and 11 [-Werror=format-overflow=]
  sprintf(output, "%04d%02d%02d%02d%02d%02d",
                       ^~~~
res_debug.c:1069:18: note: directive argument in the range [-2147483647, 2147483647]
  sprintf(output, "%04d%02d%02d%02d%02d%02d",
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~
res_debug.c:1069:2: note: 'sprintf' output between 15 and 67 bytes into a destination of size 15
  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);
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Comment 1 cvs-commit@gcc.gnu.org 2017-11-22 22:13:36 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  f120cda6072d830df92656dad0c89967547b97dc (commit)
      from  a90d1ac2d2f7b20a9df676ac9bd0aa512ab5b708 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f120cda6072d830df92656dad0c89967547b97dc

commit f120cda6072d830df92656dad0c89967547b97dc
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Wed Nov 22 22:12:07 2017 +0000

    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.  The function's interface
    is inherently problematic when dates beyond Y2038 might be involved,
    because of the ambiguity in how to interpret 32-bit timestamps as such
    dates (the RFC suggests interpreting times as being within 68 years of
    the present date, which would mean some kind of interface whose
    behavior depends on the present date).
    
    This patch works on the basis of making a minimal fix in preparation
    for obsoleting the function.  The function is made to handle times in
    the interval [0, 0x7fffffff] only, on all platforms, with <overflow>
    used as the output string in other cases (and errno set to EOVERFLOW
    in such cases).  This seems to be a reasonable state for the function
    to be in when made a compat symbol by a future patch, being compatible
    with any existing uses for existing timestamps without trying to work
    for later timestamps.  Results independent of the range of time_t also
    simplify the testcase.
    
    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 range check on the input, this patch then disables the
    -Wformat-overflow= warning for the sprintf call (I prefer that to the
    use of strftime, as being more transparently correct without knowing
    what each of %m and %M etc. is).
    
    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 uses from within glibc are limited to 32-bit inputs.
    
    Tested with build-many-glibcs.py that this restores the build for arm
    with yesterday's mainline GCC.  Also tested for x86_64 and x86.
    
    	[BZ #22463]
    	* resolv/res_debug.c: Include <libc-diag.h>.
    	(p_secstodate): Assert time_t at least as wide as u_long.  On
    	overflow, use integer seconds since the epoch as output, or use
    	"<overflow>" as output and set errno to EOVERFLOW if integer
    	seconds since the epoch would be 14 or more characters.
    	(p_secstodate) [__GNUC_PREREQ (7, 0)]: Disable -Wformat-overflow=
    	for sprintf call.
    	* resolv/tst-p_secstodate.c: New file.
    	* resolv/Makefile (tests): Add tst-p_secstodate.
    	($(objpfx)tst-p_secstodate): Depend on $(objpfx)libresolv.so.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                 |   12 ++++++++
 resolv/Makefile           |    2 +
 resolv/res_debug.c        |   24 +++++++++++++++-
 resolv/tst-p_secstodate.c |   67 +++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 104 insertions(+), 1 deletions(-)
 create mode 100644 resolv/tst-p_secstodate.c
Comment 2 Joseph Myers 2017-11-22 22:13:55 UTC
Fixed for 2.27.
Comment 3 cvs-commit@gcc.gnu.org 2018-10-22 12:54:56 UTC
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, release/2.26/master has been updated
       via  33f5de7a79b27b9dce30a46d6681974653a85004 (commit)
       via  6ae2ca620a955f1e3465e58b5180c5a7fd596dd0 (commit)
       via  fe5978e1a5d7419de3a779823fb5ed0d1dcee8ff (commit)
       via  70e810a30cb15d0b54118f8eb92aa656b945b984 (commit)
       via  dd03d15e283de6c2fff8f5204b092e9d9d127cc6 (commit)
       via  935cecfe9a4c9bf0396766f5e2b24570f92317ae (commit)
       via  3fb525c1033c70693d78010d01472bd0ed96e25f (commit)
       via  636f49ba925d5fe677212bb94b20f2c5e67d4a4f (commit)
       via  d161b294e1267ca275352c26850255c5efc998de (commit)
       via  e37ec9c813de3faeabc31d9ffc896ba45b4dfd5f (commit)
       via  27611fd05b444042de4a718c2f21e9efae755825 (commit)
      from  48bef587bfd4b6c11ae227075eb1492b10a395a8 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=33f5de7a79b27b9dce30a46d6681974653a85004

commit 33f5de7a79b27b9dce30a46d6681974653a85004
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Mon Dec 18 22:55:28 2017 +0000

    Disable -Wrestrict for two nptl/tst-attr3.c tests.
    
    nptl/tst-attr3 fails to build with GCC mainline because of
    (deliberate) aliasing between the second (attributes) and fourth
    (argument to thread start routine) arguments to pthread_create.
    
    Although both those arguments are restrict-qualified in POSIX,
    pthread_create does not actually dereference its fourth argument; it's
    an opaque pointer passed to the thread start routine.  Thus, the
    aliasing is actually valid in this case, and it's deliberate in the
    test.  So this patch makes the test disable -Wrestrict for the two
    pthread_create calls in question.  (-Wrestrict was added in GCC 7,
    hence the __GNUC_PREREQ conditions, but the particular warning in
    question is new in GCC 8.)
    
    Tested compilation with build-many-glibcs.py for aarch64-linux-gnu.
    
    	* nptl/tst-attr3.c: Include <libc-diag.h>.
    	(do_test) [__GNUC_PREREQ (7, 0)]: Ignore -Wrestrict for two tests.
    
    (cherry picked from commit 40c4162df6766fb1e8ede875ca8df25d8075d3a5)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=6ae2ca620a955f1e3465e58b5180c5a7fd596dd0

commit 6ae2ca620a955f1e3465e58b5180c5a7fd596dd0
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Tue Nov 14 17:50:36 2017 +0000

    Fix string/bug-strncat1.c build with GCC 8.
    
    GCC 8 warns about strncat calls with truncated output.
    string/bug-strncat1.c tests such a call; this patch disables the
    warning for it.
    
    Tested (compilation) with GCC 8 for x86_64-linux-gnu with
    build-many-glibcs.py (in conjunction with Martin's patch to allow
    glibc to build).
    
    	* string/bug-strncat1.c: Include <libc-diag.h>.
    	(main): Disable -Wstringop-truncation for strncat call for GCC 8.
    
    (cherry picked from commit ec72135e5f1d061cb5cf7cd1b855fd6290be10d9)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=fe5978e1a5d7419de3a779823fb5ed0d1dcee8ff

commit fe5978e1a5d7419de3a779823fb5ed0d1dcee8ff
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Thu Jun 14 14:20:00 2018 +0000

    Ignore -Wrestrict for one strncat test.
    
    With current GCC mainline, one strncat test involving a size close to
    SIZE_MAX results in a -Wrestrict warning that that buffer size would
    imply that the two buffers must overlap.  This patch fixes the build
    by adding disabling of -Wrestrict (for GCC versions supporting that
    option) to the already-present disabling of -Wstringop-overflow= and
    -Warray-bounds for this test.
    
    Tested with build-many-glibcs.py that this restores the testsuite
    build with GCC mainline for aarch64-linux-gnu.
    
    	* string/tester.c (test_strncat) [__GNUC_PREREQ (7, 0)]: Also
    	ignore -Wrestrict for one test.
    
    (cherry picked from commit 35ebb6b0c48bc671d9c54e089884f9bf6fca540e)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=70e810a30cb15d0b54118f8eb92aa656b945b984

commit 70e810a30cb15d0b54118f8eb92aa656b945b984
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Mon Dec 18 22:52:41 2017 +0000

    Disable strncat test array-bounds warnings for GCC 8.
    
    Some strncat tests fail to build with GCC 8 because of -Warray-bounds
    warnings.  These tests are deliberately test over-large size arguments
    passed to strncat, and already disable -Wstringop-overflow warnings,
    but now the warnings for these tests come under -Warray-bounds so that
    option needs disabling for them as well, which this patch does (with
    an update on the comments; the DIAG_IGNORE_NEEDS_COMMENT call for
    -Warray-bounds doesn't need to be conditional itself, because that
    option is supported by all versions of GCC that can build glibc).
    
    Tested compilation with build-many-glibcs.py for aarch64-linux-gnu.
    
    	* string/tester.c (test_strncat): Also disable -Warray-bounds
    	warnings for two tests.
    
    (cherry picked from commit 1421f39b7eadd3b5fbd2a3f2da1fc006b69fbc42)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=dd03d15e283de6c2fff8f5204b092e9d9d127cc6

commit dd03d15e283de6c2fff8f5204b092e9d9d127cc6
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Tue Nov 14 17:52:26 2017 +0000

    Fix string/tester.c build with GCC 8.
    
    GCC 8 warns about more cases of string functions truncating their
    output or not copying a trailing NUL byte.
    
    This patch fixes testsuite build failures caused by such warnings in
    string/tester.c.  In general, the warnings are disabled around the
    relevant calls using DIAG_* macros, since the relevant cases are being
    deliberately tested.  In one case, the warning is with
    -Wstringop-overflow= instead of -Wstringop-truncation; in that case,
    the conditional is __GNUC_PREREQ (7, 0) (being the version where
    -Wstringop-overflow= was introduced), to allow the conditional to be
    removed sooner, since it's harmless to disable the warning for a
    GCC version where it doesn't actually occur.  In the case of warnings
    for strncpy calls in test_memcmp, the calls in question are changed to
    use memcpy, as they don't copy a trailing NUL and the point of that
    code is to test memcmp rather than strncpy.
    
    Tested (compilation) with GCC 8 for x86_64-linux-gnu with
    build-many-glibcs.py (in conjunction with Martin's patch to allow
    glibc to build).
    
    	* string/tester.c (test_stpncpy): Disable -Wstringop-truncation
    	for stpncpy calls for GCC 8.
    	(test_strncat): Disable -Wstringop-truncation warning for strncat
    	calls for GCC 8.  Disable -Wstringop-overflow= warning for one
    	strncat call for GCC 7.
    	(test_strncpy): Disable -Wstringop-truncation warning for strncpy
    	calls for GCC 8.
    	(test_memcmp): Use memcpy instead of strncpy for calls not copying
    	trailing NUL.
    
    (cherry picked from commit 2e64ec9c9eac3aeb70f7cfa2392846c87c28068e)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=935cecfe9a4c9bf0396766f5e2b24570f92317ae

commit 935cecfe9a4c9bf0396766f5e2b24570f92317ae
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Mon Oct 22 14:08:12 2018 +0200

    Fix nscd readlink argument aliasing (bug 22446).
    
    Current GCC mainline detects that nscd calls readlink with the same
    buffer for both input and output, which is not valid (those arguments
    are both restrict-qualified in POSIX).  This patch makes it use a
    separate buffer for readlink's input (with a size that is sufficient
    to avoid truncation, so there should be no problems with warnings
    about possible truncation, though not strictly minimal, but much
    smaller than the buffer for output) to avoid this problem.
    
    Tested compilation for aarch64-linux-gnu with build-many-glibcs.py.
    
    	[BZ #22446]
    	* nscd/connections.c (handle_request) [SO_PEERCRED]: Use separate
    	buffers for readlink input and output.
    
    (cherry picked from commit 49b036bce9f021ae994a85aee8b410d20b29c8b7)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=3fb525c1033c70693d78010d01472bd0ed96e25f

commit 3fb525c1033c70693d78010d01472bd0ed96e25f
Author: Steve Ellcey <sellcey@caviumnetworks.com>
Date:   Fri Dec 15 09:08:23 2017 -0800

    Increase buffer size due to warning from ToT GCC
    
    	* nscd/dbg_log.c (dbg_log): Increase msg buffer size.
    
    (cherry picked from commit a7e3edf4f252fb72afeb8ecca946a2d8294bb577)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=636f49ba925d5fe677212bb94b20f2c5e67d4a4f

commit 636f49ba925d5fe677212bb94b20f2c5e67d4a4f
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Mon Oct 22 13:58:06 2018 +0200

    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.  The function's interface
    is inherently problematic when dates beyond Y2038 might be involved,
    because of the ambiguity in how to interpret 32-bit timestamps as such
    dates (the RFC suggests interpreting times as being within 68 years of
    the present date, which would mean some kind of interface whose
    behavior depends on the present date).
    
    This patch works on the basis of making a minimal fix in preparation
    for obsoleting the function.  The function is made to handle times in
    the interval [0, 0x7fffffff] only, on all platforms, with <overflow>
    used as the output string in other cases (and errno set to EOVERFLOW
    in such cases).  This seems to be a reasonable state for the function
    to be in when made a compat symbol by a future patch, being compatible
    with any existing uses for existing timestamps without trying to work
    for later timestamps.  Results independent of the range of time_t also
    simplify the testcase.
    
    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 range check on the input, this patch then disables the
    -Wformat-overflow= warning for the sprintf call (I prefer that to the
    use of strftime, as being more transparently correct without knowing
    what each of %m and %M etc. is).
    
    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 uses from within glibc are limited to 32-bit inputs.
    
    Tested with build-many-glibcs.py that this restores the build for arm
    with yesterday's mainline GCC.  Also tested for x86_64 and x86.
    
    	[BZ #22463]
    	* resolv/res_debug.c: Include <libc-diag.h>.
    	(p_secstodate): Assert time_t at least as wide as u_long.  On
    	overflow, use integer seconds since the epoch as output, or use
    	"<overflow>" as output and set errno to EOVERFLOW if integer
    	seconds since the epoch would be 14 or more characters.
    	(p_secstodate) [__GNUC_PREREQ (7, 0)]: Disable -Wformat-overflow=
    	for sprintf call.
    	* resolv/tst-p_secstodate.c: New file.
    	* resolv/Makefile (tests): Add tst-p_secstodate.
    	($(objpfx)tst-p_secstodate): Depend on $(objpfx)libresolv.so.
    
    (cherry picked from commit f120cda6072d830df92656dad0c89967547b97dc)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=d161b294e1267ca275352c26850255c5efc998de

commit d161b294e1267ca275352c26850255c5efc998de
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Sun Nov 12 22:00:28 2017 -0800

    timezone: pacify GCC -Wstringop-truncation
    
    Problem reported by Martin Sebor in:
    https://sourceware.org/ml/libc-alpha/2017-11/msg00336.html
    * timezone/zic.c (writezone): Use memcpy, not strncpy.
    
    (cherry picked from commit e69897bf202e18034cbef26f363bae64de70a196)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=e37ec9c813de3faeabc31d9ffc896ba45b4dfd5f

commit e37ec9c813de3faeabc31d9ffc896ba45b4dfd5f
Author: Martin Sebor <msebor@redhat.com>
Date:   Wed Nov 15 17:39:59 2017 -0700

    utmp: Avoid -Wstringop-truncation warning
    
    The -Wstringop-truncation option new in GCC 8 detects common misuses
    of the strncat and strncpy function that may result in truncating
    the copied string before the terminating NUL.  To avoid false positive
    warnings for correct code that intentionally creates sequences of
    characters that aren't guaranteed to be NUL-terminated, arrays that
    are intended to store such sequences should be decorated with a new
    nonstring attribute.  This change add this attribute to Glibc and
    uses it to suppress such false positives.
    
    ChangeLog:
    	* misc/sys/cdefs.h (__attribute_nonstring__): New macro.
    	* sysdeps/gnu/bits/utmp.h (struct utmp): Use it.
    	* sysdeps/unix/sysv/linux/s390/bits/utmp.h (struct utmp): Same.
    
    (cherry picked from commit 7532837d7b03b3ca5b9a63d77a5bd81dd23f3d9c)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=27611fd05b444042de4a718c2f21e9efae755825

commit 27611fd05b444042de4a718c2f21e9efae755825
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Wed Nov 22 18:44:23 2017 +0000

    Avoid use of strlen in getlogin_r (bug 22447).
    
    Building glibc with current mainline GCC fails, among other reasons,
    because of an error for use of strlen on the nonstring ut_user field.
    This patch changes the problem code in getlogin_r to use __strnlen
    instead.  It also needs to set the trailing NUL byte of the result
    explicitly, because of the case where ut_user does not have such a
    trailing NUL byte (but the result should always have one).
    
    Tested for x86_64.  Also tested that, in conjunction with
    <https://sourceware.org/ml/libc-alpha/2017-11/msg00797.html>, it fixes
    the build for arm with mainline GCC.
    
    	[BZ #22447]
    	* sysdeps/unix/getlogin_r.c (__getlogin_r): Use __strnlen not
    	strlen to compute length of ut_user and set trailing NUL byte of
    	result explicitly.
    
    (cherry picked from commit 4bae615022cb5a5da79ccda83cc6c9ba9f2d479c)

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                |   76 ++++++++++++++++++++++++++++++
 NEWS                                     |    3 +
 misc/sys/cdefs.h                         |    9 ++++
 nptl/tst-attr3.c                         |   19 +++++++
 nscd/connections.c                       |    5 +-
 nscd/dbg_log.c                           |    2 +-
 resolv/Makefile                          |    3 +-
 resolv/res_debug.c                       |   24 +++++++++-
 resolv/tst-p_secstodate.c                |   67 ++++++++++++++++++++++++++
 string/bug-strncat1.c                    |    8 +++
 string/tester.c                          |   58 +++++++++++++++++++++--
 sysdeps/gnu/bits/utmp.h                  |    9 ++-
 sysdeps/unix/getlogin_r.c                |    5 +-
 sysdeps/unix/sysv/linux/s390/bits/utmp.h |    9 ++-
 timezone/zic.c                           |    2 +-
 15 files changed, 281 insertions(+), 18 deletions(-)
 create mode 100644 resolv/tst-p_secstodate.c