From: Hyunwoo Kim <imv4bel@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Chen Yu <yu.c.chen@intel.com>
Cc: Tim Chen <tim.c.chen@linux.intel.com>,
Kees Cook <kees@kernel.org>,
Christian Brauner <brauner@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Qais Yousef <qyousef@layalina.io>,
Aaron Lu <ziqianlu@bytedance.com>,
Srikar Dronamraju <srikar@linux.ibm.com>,
Vineeth Remanan Pillai <vineethr@linux.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, imv4bel@gmail.com
Subject: [PATCH v2] sched/cache: Fix use-after-free of the mm replaced by exec
Date: Tue, 1 Sep 2026 06:33:02 +0900 [thread overview]
Message-ID: <apXzDjnvOm9GfTLK@v4bel> (raw)
When the waker cannot use the wakelist, ttwu_queue() takes the target rq
lock and goes down into update_curr(). If the target rq belongs to another
CPU, the task handed to account_mm_sched() is the one running on that CPU,
not the task being woken.
account_mm_sched() reads p->mm and updates mm->sc_stat. Nothing keeps that
mm alive. The rq lock and rq->cpu_epoch_lock it holds have nothing to do
with the lifetime of the mm.
If that task happens to be in execve(), exec_mmap() points tsk->mm and
tsk->active_mm at the new mm, and exec_mm_put_old() from setup_new_exec()
drops the old one. free_bprm() does the same when exec fails. On the way
from mmput() down to __mmdrop(), mm_destroy_sched() calls free_percpu() on
sc_stat.pcpu_sched and free_mm() returns the mm_struct.
Whoever already read the old pointer keeps using it. It adds to runtime in
the freed per-cpu area and reads sc_stat in the freed mm_struct. Depending
on the condition it also writes sc_stat.cpu. That is a use-after-free.
Commit 9f23469401b0 ("sched/cache: Fix potential NULL mm pointer access")
changed the remaining p->mm dereference to the local variable, and said the
active_mm reference keeps the structure allocated. That holds for the other
paths that detach an mm, since they take an mmgrab_lazy_tlb() reference.
exec reassigns active_mm to the new mm as well, so that reference is gone.
What is left is the mm_users reference in bprm->old_mm, and dropping it is
the free.
CPU0 CPU1
write(pipe)
try_to_wake_up()
ttwu_queue() // takes rq0 lock
enqueue_task_fair()
update_curr()
update_se()
account_mm_sched()
mm = rq0->curr->mm
// old mm
execve()
exec_mmap() // tsk->mm = new mm
setup_new_exec()
exec_mm_put_old()
mmput() -> ... -> __mmdrop()
mm_destroy_sched() // free_percpu()
free_mm()
read mm->sc_stat.epoch
// use-after-free
KASAN log:
BUG: KASAN: slab-use-after-free in update_se+0xe6e/0xf70
Read of size 8 at addr ffff8880093cad10 by task sc-direct-set/80
...
Call Trace:
update_se+0xe6e/0xf70
update_curr.isra.0+0x28/0x380
enqueue_task_fair+0xb58/0x3560
enqueue_task+0x70/0x170
ttwu_do_activate+0xeb/0x590
try_to_wake_up+0x79b/0x14f0
autoremove_wake_function+0x16/0x150
__wake_up_common+0xed/0x160
__wake_up_sync_key+0x36/0x50
anon_pipe_write+0xa62/0x1830
vfs_write+0xa4f/0xcf0
ksys_write+0x17c/0x1c0
do_syscall_64+0xdd/0x4a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
...
Freed by task 1:
kmem_cache_free+0xba/0x3b0
setup_new_exec+0x2c4/0x3d0
load_elf_binary+0x435/0x4740
bprm_execve+0x6d2/0x1290
do_execveat_common.isra.0+0x3a3/0x580
__x64_sys_execve+0x8e/0xc0
...
The buggy address belongs to the object at ffff8880093cab80
which belongs to the cache mm_struct of size 1688
The buggy address is located 400 bytes inside of
freed 1688-byte region [ffff8880093cab80, ffff8880093cb218)
Wait for an RCU grace period before the old mm is dropped.
account_mm_sched() runs with the rq lock held, so preemption is disabled
there and that section is an RCU read-side critical section. A reader that
already holds the old pointer finishes before the grace period ends, and
the store to tsk->mm precedes the wait, so a reader that starts afterwards
observes the new mm.
Fixes: df0d98475954 ("sched/cache: Introduce infrastructure for cache-aware load balancing")
Suggested-by: Chen Yu <yu.c.chen@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
Changes in v2:
- Drop an unrelated hunk that slipped into v1.
- Use synchronize_rcu() instead of cycling the rq lock, which covers
every reader that runs with preemption disabled.
- v1: https://lore.kernel.org/all/apPb-Dr4nPYuHQOK@v4bel/
---
fs/exec.c | 1 +
include/linux/sched.h | 4 ++++
kernel/sched/fair.c | 12 ++++++++++++
3 files changed, 17 insertions(+)
diff --git a/fs/exec.c b/fs/exec.c
index 745f6eb5279e65..6194c388079805 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -916,6 +916,7 @@ static void exec_mm_put_old(struct mm_struct *old_mm)
{
setmax_mm_hiwater_rss(¤t->signal->maxrss, old_mm);
mm_update_next_owner(old_mm);
+ sched_cache_exec_done();
mmput(old_mm);
}
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 8b3d47a325cca9..6ae31bffe049e3 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2415,10 +2415,14 @@ struct sched_cache_stat {
int cpu;
} ____cacheline_aligned_in_smp;
+void sched_cache_exec_done(void);
+
#else
struct sched_cache_stat { };
+static inline void sched_cache_exec_done(void) { }
+
#endif
#ifndef MODULE
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8dff37059faf70..a3d0185717f7b1 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1989,6 +1989,18 @@ void init_sched_mm(struct task_struct *p)
p->preferred_llc = -1;
}
+/* exec() has switched to the new mm and is about to drop the old one. */
+void sched_cache_exec_done(void)
+{
+ /*
+ * account_mm_sched() dereferences rq->curr->mm with the rq lock held,
+ * so a remote CPU can still be using the old mm. That section runs with
+ * preemption disabled and is therefore an RCU read-side critical
+ * section, so wait for a grace period before the mm goes away.
+ */
+ synchronize_rcu();
+}
+
#else /* CONFIG_SCHED_CACHE */
static inline void account_mm_sched(struct rq *rq, struct task_struct *p,
--
2.43.0
reply other threads:[~2026-08-31 21:33 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=apXzDjnvOm9GfTLK@v4bel \
--to=imv4bel@gmail.com \
--cc=brauner@kernel.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=jack@suse.cz \
--cc=juri.lelli@redhat.com \
--cc=kees@kernel.org \
--cc=kprateek.nayak@amd.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qyousef@layalina.io \
--cc=rostedt@goodmis.org \
--cc=srikar@linux.ibm.com \
--cc=sshegde@linux.ibm.com \
--cc=tim.c.chen@linux.intel.com \
--cc=vincent.guittot@linaro.org \
--cc=vineethr@linux.ibm.com \
--cc=viro@zeniv.linux.org.uk \
--cc=vschneid@redhat.com \
--cc=yu.c.chen@intel.com \
--cc=ziqianlu@bytedance.com \
/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