Re: PROBLEM: with daemon.c after y2038 on 32-bits Kernel

From: Arnaud Panaïotis
Date: Tue May 31 2022 - 08:17:10 EST

Hello,

On 31/05/2022 12:54, Adhemerval Zanella wrote:

On 31/05/2022 05:33, Arnd Bergmann via Libc-alpha wrote:
(cc correct libc-alpha list, sorry for the typo)

On Tue, May 31, 2022 at 10:24 AM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
On 17/05/2022 09:51, Arnaud Panaïotis wrote:
I'm working for a client to generate embedded 32-bits Linux Kernel working after y2038 issue.

I generated a 5.15 Kernel thought Buildroot with Coreutils 9.0, GCC 11.2.0, Binutils 2.37, Glibc 2.34-9 and CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64.

I encounter an issue while working with OpenSSH (I initially contacted them before).
To clarify: did you build just openssh with -D_TIME_BITS=64, or did
you build the entire user space this way?

I made a patch for the whole Builroot, this way all packages are built
with it (unless it is filter-out, I had to make few patches).

Option is present in build log for daemon.c and sshd.c


After 2038, /usr/sbin/sshd does not create an error but it child does generate this one:
daemon() failed: Value too large for defined data type

This happend here in sshd.c:

2019 /*
2020 * If not in debugging mode, not started from inetd and not already
2021 * daemonized (eg re-exec via SIGHUP), disconnect from the controlling
2022 * terminal, and fork. The original process exits.
2023 */
2024 already_daemon = daemonized();
2025 if (!(debug_flag || inetd_flag || no_daemon_flag || already_daemon)) {
2026
2027 if (daemon(0, 0) == -1)
2028 fatal("daemon() failed: %.200s", strerror(errno));
My guess is that there are parts of glibc that are not fully
y2038-safe at the moment, but
merely provide the interfaces for time64 applications.


In the glibc code, I see

int
daemon (int nochdir, int noclose)
{
...
if ((fd = __open_nocancel(_PATH_DEVNULL, O_RDWR, 0)) != -1
&& (__builtin_expect (__fstat64 (fd, &st), 0)
== 0)) {
...
} else {
__close_nocancel_nostatus (fd);
return -1;
}
return (0);
}
Thanks for catching it, I have opened a bug report for it [1] and I will fix
and backport to 2.34 and 2.35.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=29203
Thanks, I'll watch this.

__fstatat64 (int fd, const char *file, struct stat64 *buf, int flags)
{
struct __stat64_t64 st_t64;
return __fstatat64_time64 (fd, file, &st_t64, flags)
?: __cp_stat64_t64_stat64 (&st_t64, buf);
}

If I'm reading this correctly, daemon() internally uses the time32
version of 'stat', which fails for files with out-of-range timestamps.
Are you able to rebuild the ssh binary (or your entire distro, if that's
easier) against musl-1.2.x instead of glibc to see if the same thing
happens there?

Musl did not worked previously for me, not sure for openssh only within
Buildroot.

I'll test the patch from ticket 29203, probably the easiest solution for me.


Arnd

To reproduce:

# date -s "2040-05-12"
# hwclock --systohc
# reboot
# /usr/sbin/sshd

Note this error occurs only after the reboot, and setting a date before 2038 also require a reboot to remove the error.

strace and gdb trace linked.

Let me know if you need additional information.
--

*Arnaud PANAÏOTIS* | Lead Developer Freelance
+33 6 34 82 12 62 | arnaud.panaiotis@xxxxxx <mailto:Arnaud Panaïotis
<arnaud.panaiotis@xxxxxx>>

18 place Jean Moulin - 38000 Grenoble
APsudo - www.panaiotis.fr <https://www.panaiotis.fr>

--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus