linux-kernel - CONFIG_DEVMEM=y breaks gettimeofday in next-20250708

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250709124216.3011-1-spasswolf@web.de>
Date: Wed,  9 Jul 2025 14:42:15 +0200
From: Bert Karwatzki <spasswolf@....de>
To: linux-kernel@...r.kernel.org
Cc: Bert Karwatzki <spasswolf@....de>,
	linux-next@...r.kernel.org,
	Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: CONFIG_DEVMEM=y breaks gettimeofday in next-20250708

Recently I found that my RAM has an error (memtest86+ reproducibly reports
a failing address) (this error may lead to random crashes every few days). 
To further investigate the issue I tried using memtester which needs access 
to /dev/mem and so I recompiled linux next-20250708 with CONFIG_DEMEM=y 
and found a strange and unusual side effect:

a) the time displayed by xfce is stuck at 1.1.1970 01:00 (UTC + 1)
b) most certificates in firefox-esr fail to work due to the date being 1.1.1970 
(this includes www.google.de, www.duckduckgo.com, wikipedia and youtube and many more)
c) some certificates in firefox-esr still work (kernel.org, xkcd.com, www.spiegel.de)
d) the shell built-in time (and also /usr/bin/time) fail to work, e.g.
$ time sleep 5
real	0m0,000s
user	0m0,000s
sys	0m0,002s
(even though it actually take 5 seconds for this)
e) date still works correctly, e.g.
$ date
Mi 9. Jul 11:51:20 CEST 2025
f) This example program 

#include <stdlib.h>
#include <stdio.h>
#include <sys/time.h>

int main()
{
	int ret;
	struct timeval tv;
	struct timezone tz;

	ret = gettimeofday(&tv, &tz);
	printf("gettimeofday returns ret = %d, tv.tv_sec = %lu tv.tv_usec = %lu\n", ret, tv.tv_sec, tv.tv_usec);

	return 0;
}

gives the following output on affected versions:

$
gettimeofday returns ret = 0, tv.tv_sec = 0 tv.tv_usec = 0

These errors do not occur when using v6.16-rc5 with CONFIG_DEVMEM=y, and are 100%
reproducible so are not related to the RAM error. 

I bisected the issue in between
v6.16-rc5 and next-20250708 and found commit fcc8e46f768f ("vdso/gettimeofday:
Return bool from clock_gettime() helpers") as the first bad commit.

Bert Karwatzki