timers: Prevent union confusion from unexpected restart_syscall()
authorJann Horn <jannh@google.com>
Thu, 5 Jan 2023 13:44:03 +0000 (14:44 +0100)
committerThomas Gleixner <tglx@linutronix.de>
Wed, 11 Jan 2023 18:31:47 +0000 (19:31 +0100)
commit9f76d59173d9d146e96c66886b671c1915a5c5e5
treeeb7f50f13efa64d074376eae8ee736ff2c3a3596
parentb7bfaa761d760e72a969d116517eaa12e404c262
timers: Prevent union confusion from unexpected restart_syscall()

The nanosleep syscalls use the restart_block mechanism, with a quirk:
The `type` and `rmtp`/`compat_rmtp` fields are set up unconditionally on
syscall entry, while the rest of the restart_block is only set up in the
unlikely case that the syscall is actually interrupted by a signal (or
pseudo-signal) that doesn't have a signal handler.

If the restart_block was set up by a previous syscall (futex(...,
FUTEX_WAIT, ...) or poll()) and hasn't been invalidated somehow since then,
this will clobber some of the union fields used by futex_wait_restart() and
do_restart_poll().

If userspace afterwards wrongly calls the restart_syscall syscall,
futex_wait_restart()/do_restart_poll() will read struct fields that have
been clobbered.

This doesn't actually lead to anything particularly interesting because
none of the union fields contain trusted kernel data, and
futex(..., FUTEX_WAIT, ...) and poll() aren't syscalls where it makes much
sense to apply seccomp filters to their arguments.

So the current consequences are just of the "if userspace does bad stuff,
it can damage itself, and that's not a problem" flavor.

But still, it seems like a hazard for future developers, so invalidate the
restart_block when partly setting it up in the nanosleep syscalls.

Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20230105134403.754986-1-jannh@google.com
kernel/time/hrtimer.c
kernel/time/posix-stubs.c
kernel/time/posix-timers.c