From patchwork Sun May 21 16:19:25 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Ackermann, Eric" X-Patchwork-Id: 13249454 Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [141.89.225.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A15FA63B8 for ; Sun, 21 May 2023 16:19:28 +0000 (UTC) Received: from MX2018-DAG1.hpi.uni-potsdam.de (unknown [192.168.32.11]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTPS id 2CA6FE8821 for ; Sun, 21 May 2023 18:19:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hpi.uni-potsdam.de; s=201701; t=1684685966; bh=aLfO/f4aoOIsMb/8FflbcmJi2T6ci6WYl+j91yqAIkA=; h=From:To:Subject:Date:From; b=M8t8CLYFfP3NHSPfldbMedgf8MJGM5y2mTluPLpRjNYFANO8/GLOyC1C+jRNXnKY4 cYJI4EZSYn4XwrISgSAIbfNiFq/g/tvTCDpCvLw+qQZXEZCpgbqiqJW6+6HKX0OST5 JgqsFA74oMB6Ww9RlwV4fS1ooA9jdZa5YNcMSOpRF0Lk9Hn/6ipWhXxV0lP3qiCwyZ HVXPVv8Tsa2Z2Hs9u0NFu+uhybqp1zvVT1t+BxbJhZjGBv/m4xhmfbJwM1Or3BNvcZ 5+5RdmRgXbKPt5U+lftsIgQZhxdmN8xseT1HR4TjsgXmpmc6b6bsx95isY8yKe3GLe SC2Qu3jm/op8Q== Received: from MX2018-DAG2.hpi.uni-potsdam.de (2001:638:807:200::b:16) by MX2018-DAG1.hpi.uni-potsdam.de (2001:638:807:200::b:b) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Sun, 21 May 2023 18:19:25 +0200 Received: from MX2018-DAG2.hpi.uni-potsdam.de ([fe80::49a2:3181:d674:f060]) by MX2018-DAG2.hpi.uni-potsdam.de ([fe80::49a2:3181:d674:f060%8]) with mapi id 15.01.2507.023; Sun, 21 May 2023 18:19:25 +0200 From: "Ackermann, Eric" To: "ell@lists.linux.dev" Subject: [PATCH] Y2038 bug on uClibc: Warn if sizeof(time_t) < 8 during configuration Thread-Topic: [PATCH] Y2038 bug on uClibc: Warn if sizeof(time_t) < 8 during configuration Thread-Index: AQHZi//HSJ4MyCc9YUOUDz0JWuA6kA== Date: Sun, 21 May 2023 16:19:25 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.89.225.172] Precedence: bulk X-Mailing-List: ell@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 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(+) -- 2.25.1 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