AuroraMiddleware/glibc
1
0
Fork 0
mirror of https://sourceware.org/git/glibc.git synced 2024-11-22 13:00:06 +00:00
Code Issues Packages Projects Releases Wiki Activity
da616c1496
glibc/resolv/tst-p_secstodate.c

85 lines
2.1 KiB
C
Raw Normal View History

Obsolete p_secstodate. This patch, relative to a tree with <https://sourceware.org/ml/libc-alpha/2017-11/msg00797.html> (pending review) applied, obsoletes p_secstodate, making the underlying function __p_secstodate into a compat symbol not available for new binaries or ports. The calls in ns_print.c (part of incomplete handling of TKEY) are changed to use %lu to print times instead of trying to pretty-print the times any more. Tested for x86_64. * resolv/res_debug.c (p_secstodate): Condition definition on [SHLIB_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)]. Define directly as __p_secstodate, and as a compat symbol. Do not use libresolv_hidden_def. * resolv/resolv.h (p_secstodate): Remove macro and function declaration. * resolv/ns_print.c (ns_sprintrrf): Print times with %lu, not using p_secstodate. * include/resolv.h (__p_secstodate): Do not use libresolv_hidden_proto. * resolv/Makefile (tests): Move tst-p_secstodate to .... (tests-internal): ... here. * resolv/tst-p_secstodate.c: Include <shlib-compat.h>. Condition all contents on [TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] and declare and use __p_secstodate and use compat_symbol_reference in that case. [!TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] (do_test): Add implementation returning 77.
2017-11-22 22:21:10 +00:00
/* Test __p_secstodate compat symbol.
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.
2017-11-22 22:12:07 +00:00
Copyright (C) 2017 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
<http://www.gnu.org/licenses/>. */
#include <array_length.h>
#include <limits.h>
#include <resolv.h>
#include <stdbool.h>
#include <stdio.h>
#include <string.h>
Obsolete p_secstodate. This patch, relative to a tree with <https://sourceware.org/ml/libc-alpha/2017-11/msg00797.html> (pending review) applied, obsoletes p_secstodate, making the underlying function __p_secstodate into a compat symbol not available for new binaries or ports. The calls in ns_print.c (part of incomplete handling of TKEY) are changed to use %lu to print times instead of trying to pretty-print the times any more. Tested for x86_64. * resolv/res_debug.c (p_secstodate): Condition definition on [SHLIB_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)]. Define directly as __p_secstodate, and as a compat symbol. Do not use libresolv_hidden_def. * resolv/resolv.h (p_secstodate): Remove macro and function declaration. * resolv/ns_print.c (ns_sprintrrf): Print times with %lu, not using p_secstodate. * include/resolv.h (__p_secstodate): Do not use libresolv_hidden_proto. * resolv/Makefile (tests): Move tst-p_secstodate to .... (tests-internal): ... here. * resolv/tst-p_secstodate.c: Include <shlib-compat.h>. Condition all contents on [TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] and declare and use __p_secstodate and use compat_symbol_reference in that case. [!TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] (do_test): Add implementation returning 77.
2017-11-22 22:21:10 +00:00
#include <shlib-compat.h>
#if TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)
char *__p_secstodate (unsigned long int);
compat_symbol_reference (libresolv, __p_secstodate, __p_secstodate, GLIBC_2_0);
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.
2017-11-22 22:12:07 +00:00
struct test
{
Obsolete p_secstodate. This patch, relative to a tree with <https://sourceware.org/ml/libc-alpha/2017-11/msg00797.html> (pending review) applied, obsoletes p_secstodate, making the underlying function __p_secstodate into a compat symbol not available for new binaries or ports. The calls in ns_print.c (part of incomplete handling of TKEY) are changed to use %lu to print times instead of trying to pretty-print the times any more. Tested for x86_64. * resolv/res_debug.c (p_secstodate): Condition definition on [SHLIB_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)]. Define directly as __p_secstodate, and as a compat symbol. Do not use libresolv_hidden_def. * resolv/resolv.h (p_secstodate): Remove macro and function declaration. * resolv/ns_print.c (ns_sprintrrf): Print times with %lu, not using p_secstodate. * include/resolv.h (__p_secstodate): Do not use libresolv_hidden_proto. * resolv/Makefile (tests): Move tst-p_secstodate to .... (tests-internal): ... here. * resolv/tst-p_secstodate.c: Include <shlib-compat.h>. Condition all contents on [TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] and declare and use __p_secstodate and use compat_symbol_reference in that case. [!TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] (do_test): Add implementation returning 77.
2017-11-22 22:21:10 +00:00
/* Argument to __p_secstodate. */
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.
2017-11-22 22:12:07 +00:00
unsigned long int in;
/* Expected output. */
const char *out;
};
static const struct test tests[] =
{
{ 0UL, "19700101000000" },
{ 12345UL, "19700101032545" },
{ 999999999UL, "20010909014639" },
{ 2147483647UL, "20380119031407" },
{ 2147483648UL, "<overflow>" },
{ 4294967295UL, "<overflow>" },
Obsolete p_secstodate. This patch, relative to a tree with <https://sourceware.org/ml/libc-alpha/2017-11/msg00797.html> (pending review) applied, obsoletes p_secstodate, making the underlying function __p_secstodate into a compat symbol not available for new binaries or ports. The calls in ns_print.c (part of incomplete handling of TKEY) are changed to use %lu to print times instead of trying to pretty-print the times any more. Tested for x86_64. * resolv/res_debug.c (p_secstodate): Condition definition on [SHLIB_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)]. Define directly as __p_secstodate, and as a compat symbol. Do not use libresolv_hidden_def. * resolv/resolv.h (p_secstodate): Remove macro and function declaration. * resolv/ns_print.c (ns_sprintrrf): Print times with %lu, not using p_secstodate. * include/resolv.h (__p_secstodate): Do not use libresolv_hidden_proto. * resolv/Makefile (tests): Move tst-p_secstodate to .... (tests-internal): ... here. * resolv/tst-p_secstodate.c: Include <shlib-compat.h>. Condition all contents on [TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] and declare and use __p_secstodate and use compat_symbol_reference in that case. [!TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] (do_test): Add implementation returning 77.
2017-11-22 22:21:10 +00:00
# if ULONG_MAX > 0xffffffffUL
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.
2017-11-22 22:12:07 +00:00
{ 4294967296UL, "<overflow>" },
{ 9999999999UL, "<overflow>" },
{ LONG_MAX, "<overflow>" },
{ ULONG_MAX, "<overflow>" },
Obsolete p_secstodate. This patch, relative to a tree with <https://sourceware.org/ml/libc-alpha/2017-11/msg00797.html> (pending review) applied, obsoletes p_secstodate, making the underlying function __p_secstodate into a compat symbol not available for new binaries or ports. The calls in ns_print.c (part of incomplete handling of TKEY) are changed to use %lu to print times instead of trying to pretty-print the times any more. Tested for x86_64. * resolv/res_debug.c (p_secstodate): Condition definition on [SHLIB_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)]. Define directly as __p_secstodate, and as a compat symbol. Do not use libresolv_hidden_def. * resolv/resolv.h (p_secstodate): Remove macro and function declaration. * resolv/ns_print.c (ns_sprintrrf): Print times with %lu, not using p_secstodate. * include/resolv.h (__p_secstodate): Do not use libresolv_hidden_proto. * resolv/Makefile (tests): Move tst-p_secstodate to .... (tests-internal): ... here. * resolv/tst-p_secstodate.c: Include <shlib-compat.h>. Condition all contents on [TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] and declare and use __p_secstodate and use compat_symbol_reference in that case. [!TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] (do_test): Add implementation returning 77.
2017-11-22 22:21:10 +00:00
# endif
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.
2017-11-22 22:12:07 +00:00
};
static int
do_test (void)
{
int ret = 0;
for (size_t i = 0; i < array_length (tests); i++)
{
Obsolete p_secstodate. This patch, relative to a tree with <https://sourceware.org/ml/libc-alpha/2017-11/msg00797.html> (pending review) applied, obsoletes p_secstodate, making the underlying function __p_secstodate into a compat symbol not available for new binaries or ports. The calls in ns_print.c (part of incomplete handling of TKEY) are changed to use %lu to print times instead of trying to pretty-print the times any more. Tested for x86_64. * resolv/res_debug.c (p_secstodate): Condition definition on [SHLIB_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)]. Define directly as __p_secstodate, and as a compat symbol. Do not use libresolv_hidden_def. * resolv/resolv.h (p_secstodate): Remove macro and function declaration. * resolv/ns_print.c (ns_sprintrrf): Print times with %lu, not using p_secstodate. * include/resolv.h (__p_secstodate): Do not use libresolv_hidden_proto. * resolv/Makefile (tests): Move tst-p_secstodate to .... (tests-internal): ... here. * resolv/tst-p_secstodate.c: Include <shlib-compat.h>. Condition all contents on [TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] and declare and use __p_secstodate and use compat_symbol_reference in that case. [!TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] (do_test): Add implementation returning 77.
2017-11-22 22:21:10 +00:00
char *p = __p_secstodate (tests[i].in);
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.
2017-11-22 22:12:07 +00:00
printf ("Test %zu: %lu -> %s\n", i, tests[i].in, p);
if (strcmp (p, tests[i].out) != 0)
{
printf ("test %zu failed", i);
ret = 1;
}
}
return ret;
}
Obsolete p_secstodate. This patch, relative to a tree with <https://sourceware.org/ml/libc-alpha/2017-11/msg00797.html> (pending review) applied, obsoletes p_secstodate, making the underlying function __p_secstodate into a compat symbol not available for new binaries or ports. The calls in ns_print.c (part of incomplete handling of TKEY) are changed to use %lu to print times instead of trying to pretty-print the times any more. Tested for x86_64. * resolv/res_debug.c (p_secstodate): Condition definition on [SHLIB_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)]. Define directly as __p_secstodate, and as a compat symbol. Do not use libresolv_hidden_def. * resolv/resolv.h (p_secstodate): Remove macro and function declaration. * resolv/ns_print.c (ns_sprintrrf): Print times with %lu, not using p_secstodate. * include/resolv.h (__p_secstodate): Do not use libresolv_hidden_proto. * resolv/Makefile (tests): Move tst-p_secstodate to .... (tests-internal): ... here. * resolv/tst-p_secstodate.c: Include <shlib-compat.h>. Condition all contents on [TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] and declare and use __p_secstodate and use compat_symbol_reference in that case. [!TEST_COMPAT (libresolv, GLIBC_2_0, GLIBC_2_27)] (do_test): Add implementation returning 77.
2017-11-22 22:21:10 +00:00
#else
static int
do_test (void)
{
return 77;
}
#endif
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.
2017-11-22 22:12:07 +00:00
#include <support/test-driver.c>
Reference in New Issue Copy Permalink