This commit

commit 769071ac9f20b6a447410c7eaa55d1a5233ef40c
Author: Andrei Vagin <avagin>
Date:   Tue Nov 12 01:26:52 2019 +0000

    ns: Introduce Time Namespace

added support for unshare(CLONE_NEWTIME), but the initial implementation was incompatible with vfork. This has been fixed in this commit (merged into Linux 6.0):

commit 133e2d3e81de5d9706cab2dd1d52d231c27382e5
Author: Andrei Vagin <avagin>
Date:   Sun Jun 12 23:07:22 2022 -0700

    fs/exec: allow to unshare a time namespace on vfork+exec
    
    Right now, a new process can't be forked in another time namespace
    if it shares mm with its parent. It is prohibited, because each time
    namespace has its own vvar page that is mapped into a process address
    space.
    
    When a process calls exec, it gets a new mm and so it could be "legal"
    to switch time namespace in that case. This was not implemented and
    now if we want to do this, we need to add another clone flag to not
    break backward compatibility.
    
    We don't have any user requests to switch times on exec except the
    vfork+exec combination, so there is no reason to add a new clone flag.
    As for vfork+exec, this should be safe to allow switching timens with
    the current clone flag. Right now, vfork (CLONE_VFORK | CLONE_VM) fails
    if a child is forked into another time namespace. With this change,
    vfork creates a new process in parent's timens, and the following exec
    does the actual switch to the target time namespace.
    
    Suggested-by: Florian Weimer <fweimer>
    Signed-off-by: Andrei Vagin <avagin>
    Acked-by: Christian Brauner (Microsoft) <brauner>
    Signed-off-by: Kees Cook <keescook>
    Link: https://lore.kernel.org/r/20220613060723.197407-1-avagin@gmail.com

Without this kernel change, we'd have to patch glibc and various other libraries that provide generic process-start facilities that are based on vfork, so that applications can call unshare(CLONE_NEWTIME) and still launch new processes.