Devices and Embedded Systems

In brief: Most computers you can buy today, and the operating systems on them, already handle dates past 2038. The highest risk is in "invisible" computers: the controllers inside factories, fuel stations, cars, medical equipment, routers and TVs. Many of these use small 32-bit chips and old software, rarely or never get updates, and are expected to run for 15–30 years. Some of them are already known to fail when their clock is set past 19 January 2038, and attackers can trigger that failure early by feeding them a false time.

Risk level	Critical
Status	Fix exists in Linux kernel ≥ 5.6 and modern C libraries (musl ≥ 1.2, glibc ≥ 2.34 opt-in); installed base of 32-bit firmware largely unremediated; first CVEs for 2038 overflow issued in 2025
Last reviewed	2026-10-21

Overview

The Year 2038 problem is simple to describe: software that stores time as a signed 32-bit count of seconds since 1970 runs out of room at 03:14:07 UTC on 19 January 2038 and wraps to December 1901 (see Year-2038-Problem). On a modern 64-bit server or phone this is mostly solved. Embedded systems are different for five reasons.

Long lifecycles. Industrial controllers, substation relays, building management systems, tank gauges, vehicles and implanted medical devices commonly stay in service for 15–30 years. The ITU-T technical paper on "2038-class" rollover events calls out platforms with service lives of "fifteen to thirty years, and in some sectors substantially longer" that routinely incorporate 32-bit timestamps ^[12]. A device sold in 2026 will very likely still be running in 2038.
No (practical) updates. Many devices have no update channel, are owned by organisations without the skills to update them, or need regulatory re-certification for any firmware change (see Devices-Automotive-Aviation-Medical). The vendor may no longer exist.
32-bit CPUs are still shipping. 32-bit ARM and MIPS remain the default for cost-sensitive designs. When Debian announced its 64-bit time_t transition in 2025, its maintainers noted that cost-sensitive 32-bit hardware is still shipping in automotive, IoT, TVs, routers, plant control and building monitoring ^[6]. Bitsight cites projections that 32-bit microcontrollers hold about 44% of the MCU market in 2026 ^[8].
Old software stacks. Fixing 2038 on 32-bit Linux needs a kernel of 5.6 or later and a C library and every application rebuilt with a 64-bit time_t ^[1]. Firmware built on older kernels, older uClibc/glibc/musl versions, or 32-bit Android is not fixed by any patch to a single component ^[2]^[4]^[5].
Hardware clocks and firmware formats. Real-time-clock (RTC) chips, bootloaders and on-device file systems often have their own limits, separate from time_t. Many RTCs store only a two-digit year; the Linux RTC subsystem records such chips as valid only from 2000 to 2099 ^[15]. File systems used on flash storage (FAT, ext2/3, ext4 with small inodes) have their own ceilings (see File-Systems).

A newer concern is that the failure can be triggered today. Researchers from Bitsight and the Epochalypse Project showed in 2025 that manipulating a device's NTP or GPS time source can push it past 2038 now, causing crashes, log corruption and denial of access ^[8]^[11]. This turned 2038 from a "future date bug" into a present-day vulnerability class, and in 2025 CISA published the first ICS advisories with CVEs for 2038 overflows in fuel-tank gauges ^[9]^[10].

Technical details

What has to be true for a 32-bit device to survive 2038

Layer	Requirement	Where it was fixed
Kernel	64-bit time system calls (`clock_gettime64`, etc.) on 32-bit architectures	Linux 5.1 added the time64 syscalls; 5.6 (2020) is "the first release that can serve as a base for a 32-bit system designed to run beyond year 2038" ^[1]
C library	64-bit `time_t` in the user-space ABI	musl 1.2.0 (Feb 2020), unconditional on all 32-bit archs ^[2]; glibc 2.34 (Aug 2021), opt-in with `-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64` ^[3]; uClibc-ng time64 support added in 2024, initially fully supported only on 32-bit ARM ^[4]
Applications	Rebuilt against the new ABI; no `time_t` in on-disk or wire formats	Per-application; Debian found `time_t` in 6,429 packages ^[6]
On-disk formats	File system and database timestamp fields ≥ 2038	See File-Systems, Databases
Protocols	Wire formats with 32-bit time fields handled correctly	See File-Formats-and-Protocols
RTC hardware	Year register covers 2038+	Chip-specific; many two-digit-year RTCs are limited to 2000–2099 ^[15]

Two widely used platforms remain on 32-bit time by design:

32-bit Android. Bionic's own documentation says: "On 32-bit Android, time_t is 32-bit, which will overflow in 2038." A time64_t workaround type exists, but Android does not plan to add 64-bit kernel time support to the 32-bit C library ^[5].
Debian i386. Debian moved its other 32-bit ports to 64-bit time_t after Debian 13 "Trixie", but i386 keeps 32-bit time_t as a compatibility architecture ^[6].

Embedded Linux distributions have moved at different speeds. OpenWrt 22.03 (2022) adopted musl 1.2.x and therefore 64-bit time_t on 32-bit targets, which required recompiling all user space ^[7]. Any router firmware built from OpenWrt 21.02 or earlier, or from vendor SDKs based on old uClibc, keeps the 32-bit ABI.

The attack angle

The Bitsight team reports that its ICS lab was able to manipulate both NTP and GPS to trigger 2038-related failures ^[8]. In an internet scan of about 1.5 million public NTP services, of the ~200,000 that disclosed enough detail, almost 60% ran old 32-bit operating systems ^[8]. The same post counts about 500,000 reachable instances of the Boa web server (unmaintained since 2005 and common in embedded devices) and 5,000–10,000 exposed automatic tank gauges ^[8]. The Hack.lu 2025 talk "2038 is gonna be epoch!" by Pedro Umbelino and Trey Darley describes controlled experiments on IoT, ICS/OT and embedded devices ^[11].

Affected versions / products

Summary of embedded exposure by sector. Details are on the linked pages.

Sector	Typical devices	Typical lifetime	Main 2038-class exposure	Known public findings	Page
Industrial control (ICS/OT)	PLCs, HMIs, RTUs, SCADA servers, historians	15–30 yrs ^[12]	32-bit RTOS/Linux firmware; protocol time fields (IEC 61850 Ed. 1 `INT32`)	CVE-2025-55068 (Dover MagLink LX4), CVE-2025-55067 (Veeder-Root TLS4B) ^[9]^[10]	Devices-Industrial-and-Infrastructure
Energy / smart grid	Protection relays, substation gateways, smart meters	15–20+ yrs	IEC 61850 timestamps; meter firmware; GPS/PTP time chains	IEC 61850 Ed. 1 overflows 2038; Ed. 2 to 2106	Devices-Industrial-and-Infrastructure
Telecom	DSLAMs, aggregation nodes, CPE, timing gear	10–20 yrs	Legacy access equipment; NTP/PTP/GNSS timing chain ^[12]	ITU-T XSTP.EPOCH (2026)	Devices-Industrial-and-Infrastructure
Fuel retail	Automatic tank gauges	10–20 yrs	Embedded Linux with 32-bit time	Two CISA advisories in 2025 ^[9]^[10]	Devices-Industrial-and-Infrastructure
Automotive	ECUs, infotainment, telematics, EV chargers	15–20 yrs ^[12]	150–300 ECUs per vehicle from multi-tier suppliers; 32-bit Android head units; ISO 15118 PKI	No public 2038 recall found (as of 2026-10-21)	Devices-Automotive-Aviation-Medical
Aviation	Avionics LRUs, ground systems	25–40 yrs	Certified software, hard to change	Boeing 787 248-day counter AD (analogous overflow) ^[16]	Devices-Automotive-Aviation-Medical
Medical	Implants, infusion pumps, imaging, lab systems	10–15+ yrs	Re-certification needed for firmware changes ^[12]	No FDA 2038-specific guidance found	Devices-Automotive-Aviation-Medical
Networking & consumer IoT	Routers, NAS, IP cameras, smart TVs, set-top boxes	5–15 yrs	32-bit MIPS/ARM Linux, old uClibc, 32-bit Android; certificate validation	~60% of exposed NTP servers on 32-bit OS ^[8]	Devices-Networking-and-IoT
Payments / transport	POS terminals, ticket gates	10+ yrs	Embedded firmware, certificate checks	Named as at-risk by Kaspersky ^[14]	Devices-Networking-and-IoT

Risk & compliance notes

Inventory first. Kaspersky's 2026 guidance recommends a complete asset inventory that includes firmware and installed software, because no single tool produces an exhaustive list, then asking each vendor for its Y2K38 status and a fix timeline ^[14].
Standards are emerging. ITU-T Study Group 17 approved Version 1 of Technical Paper XSTP.EPOCH, "Global coordination requirements for 2038-class rollover events", at its June 2026 meeting in Geneva. It covers the 2036 NTP rollover, the 2038 time_t overflow, the 20 November 2038 GPS week rollover and the 2106 unsigned overflow, and has treatments for telecom, finance, connected vehicles and medical devices ^[12]. IEEE P4150, "Recommended Practice for Assessing and Documenting Preparedness for Time Rollover Events in Years 2036, 2038, and 2106", had its PAR approved on 2026-06-04 ^[13]. Both are non-normative or in progress, so treat them as frameworks, not compliance obligations.
Ownership. Embedded exposure usually sits with OT, facilities, clinical engineering or product teams, not central IT. Make sure each device class has a named owner.
Procurement. Ask suppliers to state the time_t width, C library version, RTC range and file-system format of new devices. The ITU-T paper suggests treating rollover evaluation as an explicit procurement criterion ^[12].

Detection & mitigation

Identify the kernel and libc: uname -r; check for musl ≥ 1.2, glibc ≥ 2.34 built with _TIME_BITS=64, or uClibc-ng with time64 enabled.
On a test unit (never in production ^[14]), set the clock to 2038-01-19 03:00 UTC and watch it cross the boundary. Isolate test time sources from the rest of the network.
Protect time sources: authenticated NTP (NTS) where supported, restricted NTP sources, GPS spoofing detection. This reduces the "trigger it early" attack.
Plan replacement where no fix is possible. Bitsight estimates replacing roughly 50,000 vulnerable tank gauges alone would cost about USD 1–1.8 billion and take 3–6 years ^[8].
See Testing-and-Detection, Remediation-Guide and Risk-Assessment-Checklist.

References

Arnd Bergmann, "[GIT PULL] y2038: core, driver and file system changes" — LKML, 2020-01-29 — Linux 5.6 as first base for 32-bit systems beyond 2038; caveats.
musl time64 notes — musl libc — musl 1.2.0 changes time_t to 64-bit on all archs; ABI notes.
GNU C Library 2.34 released — info-gnu, 2021-08 — opt-in 64-bit time_t on legacy 32-bit ABIs via _TIME_BITS=64.
Buildroot: "package/uclibc: bump to version 1.0.47, add Y2038 config option" — Buildroot list, 2024-04 — uClibc-ng time64 support and integration debate; see also the uClibc-ng time commit log.
32-bit ABI bugs — Android bionic docs — 32-bit Android keeps 32-bit time_t.
Debian isn't waiting for 2038 to blow up — The Register, 2025-07-25 — Debian 64-bit time_t transition, 6,429 packages, i386 exception, embedded hardware still shipping.
OpenWrt 22.03.0-rc6 release notes — OpenWrt, 2022-08-02 — musl 1.2.x brings 64-bit time_t to 32-bit targets.
Pedro Umbelino, "Forward to the Past: The Y2K38 Problem Ahead" — Bitsight, 2026-01-18 — NTP/GPS manipulation in ICS lab; NTP, Boa, ATG statistics; MCU share; ATG replacement cost.
ICSA-25-261-07: Dover Fueling Solutions ProGauge MagLink LX4 Devices — CISA, 2025-09-18 — CVE-2025-55068 Unix time integer overflow.
ICSA-25-296-03: Veeder-Root TLS4B Automatic Tank Gauge System — CISA, 2025-10-23 — CVE-2025-55067, 2038 epoch rollover.
Umbelino & Darley, "2038 is gonna be epoch!" — Hack.lu 2025, 2025-10-23 — controlled experiments on IoT, ICS/OT and embedded devices.
ITU-T Technical Paper XSTP.EPOCH, "Global coordination requirements for 2038-class rollover events" (liaison to IETF), 2026-07-21 — Version 1 approved by SG17, June 2026; sector survey and lifecycle analysis.
IEEE P4150 — IEEE Standards Association — PAR approved 2026-06-04; rollover-readiness recommended practice.
Stan Kaminsky, "Epochalypse Now — or how to deal with Y2K38" — Kaspersky, 2026-01-19 — affected device classes; inventory and testing advice.
Alexandre Belloni, "rtc: ab-b5ze-s3: let the core handle the RTC range" — LKML, 2018-05 — two-digit-year RTC range set to 2000–2099 in the Linux RTC core.
FAA AD 2015-09-07, Boeing 787 — Federal Register, 2015-05-01 (EASA mirror) — GCU software counter overflow after 248 days of power.