[PATCH] Y2038 bug on uClibc: Warn if sizeof(time_t) < 8 during configuration
"Ackermann, Eric" <[email protected]> Sun, 21 May 2023 16:19:25 +0000
| Newsgroups | dev.linux.lists.ell |
|---|---|
| Message-ID | <[email protected]> |
Hello everyone,
I discovered a Y2038 bug in iwd that was caused by the TLS certificate parsing code in ell.
I compiled iwd for Linux with uClibc on armv7l. The test "EAPoL/8021x EAP-TLS & 4-Way
Handshake" failed with an assertion failure, as ell considered the certificate used in the
test invalid. The reason for this is that the expiration date of the test certificate was in 2050,
which cannot be represented in uClibc's 4-byte time_t. Hence, timegm() fails, causing a
failure of cert_parse_asn1_time() and so on.
I reckon that the issue is specific to uClibc and other C libraries that use a 4-byte time_t on
32 bit platforms, e.g., uClibc as configured by buildroot. Most C libraries (e.g. glibc, musl)
simply define time_t to always be 64 bits long, avoiding the issue.
However, especially on embedded systems that use uClibc, this is a real issue that might
cause unexpected behavior. Unfortunately, to my knowledge, there is no portable version
of timegm that always uses a 64-bit output. However, in my opinion, I believe that the C
library rather than ell should be changed. For the time being (and for users who use
unpatched versions of C libraries), the appended patch adds a warning to configure in case
sizeof(time_t) < 8 bytes.
Kind regards,
Eric Ackermann
---
configure.ac | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/configure.ac b/configure.ac
index fb7a997..23e719b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -31,6 +31,18 @@ AC_C_BIGENDIAN(little_endian=no, little_endian=yes, little_endian=no)
LT_PREREQ(2.2)
LT_INIT([disable-static])
+AC_CHECK_SIZEOF([time_t])
+SIZEOF_TIME_T=$($AWK '/SIZEOF_TIME_T/{print $3}' confdefs.h)
+if (test "${SIZEOF_TIME_T}" -lt "8"); then
+ AC_MSG_WARN([sizeof(time_t) is less than 8 bytes on your
+ platform. Hence, dates after 2038-01-19 cannot be
+ represented in a time_t. This might lead to overflow
+ errors in time processing functions such as timegm,
+ which can manifest themselves e.g. by TLS certificates
+ with an expiration date after 2038 not being accepted
+ by ell. Proceed with caution.])
+fi
+
AC_ARG_ENABLE(optimization, AS_HELP_STRING([--disable-optimization],
[disable code optimization through compiler]), [
if (test "${enableval}" = "no"); then
--
2.25.1