Re: ntsync: absolute MONOTONIC timeout ignores time namespace offset

[Elizabeth Figura]

On Monday, 18 May 2026 05:21:08 CDT Maoyi Xie wrote:
> Hi all,
> 
> While reading drivers/misc/ntsync.c I noticed something that
> might be a time-namespace bug. I would appreciate it if you
> could take a look and let me know whether this is a real bug,
> and whether it is worth fixing.
> 
> ntsync_schedule() takes the user-supplied absolute timeout
> and hands it to schedule_hrtimeout_range_clock() with
> HRTIMER_MODE_ABS. For the default CLOCK_MONOTONIC path, it
> does not call timens_ktime_to_host() first.
> 
> A process inside a CLOCK_MONOTONIC time namespace computes
> the absolute timeout in its own clock view. The kernel reads
> the same value against the host clock. The two differ by the
> namespace offset.
> 
> The other absolute-timeout consumers (timerfd, posix-timers,
> alarmtimer, posix-stubs, futex) all run user-supplied
> absolute MONOTONIC ktime through timens_ktime_to_host()
> before hrtimer. ntsync was added post-5.17 and seems to have
> missed that step.
> 
> /dev/ntsync is mode 0666, so any user in a time namespace
> that can open it is affected. The user-visible impact is
> wrong timeout behaviour for Wine inside a container that
> sets a CLOCK_MONOTONIC offset.
> 
> Attached PoC: baseline run elapsed ~100 ms; the --in-timens
> run inside a -10s namespace elapsed ~0 ms.
> 
> A candidate fix would call timens_ktime_to_host(clock, timeout)
> in the else branch (i.e., when NTSYNC_WAIT_REALTIME is not set)
> before passing the value to schedule_hrtimeout_range_clock().
> 
> If this is intentional or already known, please disregard.

I was not aware of time namespaces, so no, this was not intentional, and there's no reason to keep it this way. I don't remember at this point if I wrote the timeout logic using any other code as a model... you'd think I would have used futex, but evidently I either didn't or missed the timens call. Thank you for catching this.

> Otherwise, I am happy to send a [PATCH] or to leave the fix to you.

No strong feelings here, so I suppose whoever gets to it first ;-)

> Thank you for your time, and sorry for the noise if this is not actually
> a bug or has already been spotted.
> 
> Thanks,
> Maoyi Xie
> https://maoyixie.com/
>