mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Hyunwoo Kim <imv4bel@gmail.com>, Oleg Nesterov <oleg@redhat.com>,
	Frederic Weisbecker <frederic@kernel.org>,
	Christian Brauner <brauner@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	John Stultz <jstultz@google.com>, Ingo Molnar <mingo@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: [patch 0/8] exec/exit: POSIX timer related bugfixes and related cleanups
Date: Fri, 04 Sep 2026 13:22:17 +0200	[thread overview]
Message-ID: <20260904112100.683893401@kernel.org> (raw)

Recent findings from Hyunwoo unearthed two bugs in handling POSIX timers on
exec().

The relevant patches, reports and discussions can be found here:

   https://patch.msgid.link/aok1rdkBgZsynHZB@v4bel
   https://patch.msgid.link/ao7Q8miiuLAPVnWv@v4bel

TLDR:

Both problems are related to non-leader exec(). POSIX CPU timers which are
targeted at tasks hold a pid reference of the target task, which is used to
look up the task in the related POSIX timer operations.

The non-leader exec() switches the TID of the old and the new leader, which
obviously invalidates these references for pid_task(PIDTYPE_PID) lookups.

This causes UAFs due to the resulting list corruptions or premature freeing
without removing the underlying POSIX CPU timers from the involved tasks.

The first issue which corrupts the signal pending list is solved by:

    - Preventing the queueing of per task signals on a task which has
      PF_EXITING set.

    - Protecting the unlocked setting of PF_EXITING in exit_signals() with
      sighand lock.

    - Flushing all per task signals right in exit_signals()

The second issue which keeps the POSIX CPU timers queued on the new leader
is solved by:

    - Moving the exec related POSIX timer cleanup right after de_thread()
      which ensures that the timers queued in new_leader::posix_cputimers
      are removed before the underlying POSIX timers are deleted.

After looking deeper at the exit() handling it turned out that the POSIX
timer cleanups can be done early in do_exit() instead of delaying them
until release_task().

The reason for this late cleanup is that POSIX CPU timers can be created,
rearmed and deleted as long as a task is visible, i.e. the pid is hashed
and sighand is not NULL. This allows to retrieve information from the timer
up to the point where the task is gone for real and that can't be changed
easily as that'd be a user visible change.

But once PF_EXITING is set on a task the task does not longer expire POSIX
CPU timers. So it makes no sense that the timers stay queued in
task::posix_cputimers after that point.

The only thing which needs to be prevented is that timers are requeued on
task::posix_cputimers once PF_EXITING is set or requeued on
signal::posix_cputimers when PF_EXITING is set and signal::live is zero,
which indicates that the thread group is dead.

With that solved the timers can be dequeued from task::posix_cputimer
pending when a task exits and from signal::posix_cputimer pending once the
threadgroup reaches the dead state, i.e. signal::live goes to zero.

The series applies on 7.3-rc1 and is avalaible from git:

    git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git posix-timers

Thanks,

	tglx
---
 fs/exec.c                      |   18 ++++---
 include/linux/posix-timers.h   |   39 ++--------------
 include/linux/sched/task.h     |    1 
 kernel/exit.c                  |   24 +++------
 kernel/signal.c                |   70 ++++++++++++++++------------
 kernel/time/posix-cpu-timers.c |   99 +++++++++++++++++++++++++++++++++++++----
 kernel/time/posix-timers.c     |   26 ++++++++--
 kernel/time/posix-timers.h     |    3 +
 8 files changed, 179 insertions(+), 101 deletions(-)

             reply	other threads:[~2026-09-04 11:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04 11:22 Thomas Gleixner [this message]
2026-09-04 11:22 ` [patch 1/8] signal: Prevent exec() race Thomas Gleixner
2026-09-04 11:35   ` Oleg Nesterov
2026-09-05  7:34     ` Thomas Gleixner
2026-09-05  7:50       ` Frederic Weisbecker
2026-09-05 11:22         ` Thomas Gleixner
2026-09-04 11:22 ` [patch 2/8] exec: Cleanup POSIX timers right after de_thread() Thomas Gleixner
2026-09-04 11:22 ` [patch 3/8] posix-timers: Move posixtimer_exec_cleanup() out of exec.c Thomas Gleixner
2026-09-04 11:22 ` [patch 4/8] posix-timers: Move POSIX timer group exit related code out of do_exit() Thomas Gleixner
2026-09-04 11:22 ` [patch 5/8] posix-cpu-timers: Move inlines out of public header Thomas Gleixner
2026-09-04 11:22 ` [patch 6/8] posix-cpu-timers: Use PF_EXITING to indicate exit Thomas Gleixner
2026-09-04 11:22 ` [patch 7/8] posix-cpu-timers: Prevent enqueueing when PF_EXITING is set Thomas Gleixner
2026-09-04 12:06   ` Eric W. Biederman
2026-09-04 15:47     ` Eric W. Biederman
2026-09-05  7:50       ` Thomas Gleixner
2026-09-04 11:22 ` [patch 8/8] posix-timers: Handle exit in do_exit() completely Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260904112100.683893401@kernel.org \
    --to=tglx@kernel.org \
    --cc=brauner@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=frederic@kernel.org \
    --cc=imv4bel@gmail.com \
    --cc=jstultz@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®