ntsync: absolute MONOTONIC timeout ignores time namespace offset

[Maoyi Xie]

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.
Otherwise, I am happy to send a [PATCH] or to leave the fix to you.
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/

Attachment: poc_ntsync_timens.log
Description: Binary data

Attachment: poc_ntsync_timens.c
Description: Binary data