From: Jianyong Wu <wujianyong@hygon.cn>
To: XIAO WU <xiaowu.417@qq.com>
Cc: "justin.he@arm.com" <justin.he@arm.com>,
Yuan Zhong <zhongyuan@hygon.cn>,
Zhiwei Ying <yingzhiwei@hygon.cn>, Huangsj <huangsj@hygon.cn>,
"mingo@redhat.com" <mingo@redhat.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"juri.lelli@redhat.com" <juri.lelli@redhat.com>,
"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
"dietmar.eggemann@arm.com" <dietmar.eggemann@arm.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"bsegall@google.com" <bsegall@google.com>,
"mgorman@suse.de" <mgorman@suse.de>,
"vschneid@redhat.com" <vschneid@redhat.com>,
"kprateek.nayak@amd.com" <kprateek.nayak@amd.com>,
"sshegde@linux.ibm.com" <sshegde@linux.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"yu.c.chen@intel.com" <yu.c.chen@intel.com>,
"tim.c.chen@linux.intel.com" <tim.c.chen@linux.intel.com>
Subject: RE: [RFC PATCH 8/8] sched/debug: Print task preferred LLC for scheduler debugging
Date: Tue, 30 Jun 2026 02:03:05 +0000 [thread overview]
Message-ID: <510cee91f67a4aa98d24eef7c1c59d80@hygon.cn> (raw)
In-Reply-To: <tencent_211B975024CBC27863929B9003111BE18609@qq.com>
Hi Xiao,
Thanks for catching this bug and for suggesting the fix. I'll incorporate it in v2.
Thanks
Jianyong
> -----Original Message-----
> From: XIAO WU <xiaowu.417@qq.com>
> Sent: Monday, June 29, 2026 3:29 AM
> To: Jianyong Wu <wujianyong@hygon.cn>; mingo@redhat.com;
> peterz@infradead.org; juri.lelli@redhat.com; vincent.guittot@linaro.org;
> dietmar.eggemann@arm.com; rostedt@goodmis.org; bsegall@google.com;
> mgorman@suse.de; vschneid@redhat.com; kprateek.nayak@amd.com;
> sshegde@linux.ibm.com; linux-kernel@vger.kernel.org;
> yu.c.chen@intel.com; tim.c.chen@linux.intel.com
> Cc: justin.he@arm.com; Yuan Zhong <zhongyuan@hygon.cn>; Zhiwei Ying
> <yingzhiwei@hygon.cn>; Huangsj <huangsj@hygon.cn>
> Subject: Re: [RFC PATCH 8/8] sched/debug: Print task preferred LLC for
> scheduler debugging
>
> Hi Jianyong,
>
> I came across the Sashiko AI review of this series and reproduced the
> use-after-free it flagged in sched_show_cache() — a KASAN
> slab-use-after-free triggers when reading /proc/<pid>/sched while the
> target task is concurrently exiting.
>
> The Sashiko review is at:
> https://sashiko.dev/#/patchset/20260625030759.25928-1-wujianyong@hyg
> on.cn
>
> > +static void sched_show_cache(struct task_struct *p, struct seq_file *m)
> > +{
> > +#ifdef CONFIG_SCHED_CACHE
> > + struct mm_struct *mm = p->mm;
> > + int sc_cpu, sc_llc, sc_node, pref_llc, pref_node;
> > +
> > + if (!mm)
> > + return;
> > +
> > + sc_cpu = READ_ONCE(mm->sc_stat.cpu);
>
> This saves p->mm into a local variable and checks it for NULL, but
> does so without holding task_lock(p) or taking a reference via
> get_task_mm(). If the target task is concurrently exiting,
> exit_mm() can drop the final reference and free the mm_struct
> between the NULL check and the READ_ONCE(mm->sc_stat.cpu) access,
> resulting in a slab-use-after-free.
>
> The access happens from proc_sched_show_task() which is reachable
> via /proc/<pid>/sched — userspace can trigger this for any visible
> task by simply reading the proc file while the task exits.
>
> === Reproduction ===
>
> Kernel: 7.1.0-rc2-gd93b88951718 #1 PREEMPT(full)
> Arch: x86_64 (QEMU Standard PC Q35 + ICH9, 2009)
> Config: CONFIG_KASAN=y, CONFIG_SCHED_CACHE=y
>
> Trigger: race fork/exit against /proc/<pid>/sched reads. 16 worker
> threads each fork children and read /proc/<child_pid>/sched while
> the child immediately exits.
>
> === Crash Log ===
>
> [ 991.032119][T535366] BUG: KASAN: slab-use-after-free in
> proc_sched_show_task+0x30c7/0x3470
> [ 991.032971][T535366] Read of size 4 at addr ffff88802fe0d960 by task
> poc/535366
> [ 991.033952][T535366] CPU: 1 UID: 0 PID: 535366 Comm: poc Not tainted
> 7.1.0-rc2-gd93b88951718 #1 PREEMPT(full)
> [ 991.033962][T535366] Hardware name: QEMU Standard PC (Q35 + ICH9,
> 2009)
> [ 991.033967][T535366] Call Trace:
> [ 991.033970][T535366] <TASK>
> [ 991.033973][T535366] dump_stack_lvl+0x116/0x1f0
> [ 991.033989][T535366] print_report+0xf4/0x600
> [ 991.034021][T535366] kasan_report+0xe0/0x110
> [ 991.034032][T535366] ? proc_sched_show_task+0x30c7/0x3470
> [ 991.034043][T535366] proc_sched_show_task+0x30c7/0x3470
> [ 991.034054][T535366] sched_show+0xf4/0x1b0
> [ 991.034062][T535366] seq_read_iter+0x513/0x12d0
> [ 991.034074][T535366] seq_read+0x3b1/0x590
> [ 991.034093][T535366] vfs_read+0x1e9/0xd00
> [ 991.034153][T535366] ksys_read+0x12f/0x250
> [ 991.034220][T535366] do_syscall_64+0x129/0x880
> [ 991.034240][T535366] entry_SYSCALL_64_after_hwframe+0x77/0x7f
> [ 991.034250][T535366] </TASK>
>
> The Read of size 4 at an offset into a freed mm_struct matches the
> READ_ONCE(mm->sc_stat.cpu) access racing against exit_mm().
>
> === PoC ===
>
> Build: gcc -o poc poc.c -static
> Run: ./poc
>
> /* sched_show_cache UAF PoC — race fork/exit against /proc/<pid>/sched
> */
> #define _GNU_SOURCE
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <signal.h>
> #include <sys/wait.h>
>
> static void worker(void)
> {
> char buf[64], path[64];
> for (int i = 0; i < 50000000; i++) {
> pid_t pid = fork();
> if (pid == 0) { _exit(0); }
> if (pid > 0) {
> snprintf(path, 64, "/proc/%d/sched", pid);
> int fd = open(path, O_RDONLY);
> if (fd >= 0) { read(fd, buf, 63); close(fd); }
> }
> }
> _exit(0);
> }
>
> int main(void)
> {
> signal(SIGCHLD, SIG_IGN);
> for (int i = 0; i < 16; i++)
> if (fork() == 0) { worker(); }
> while (wait(NULL) > 0);
> return 0;
> }
>
> The fix is to use get_task_mm(p) / mmput(mm) around the mm access,
> which safely pins the mm_struct for the duration of the read.
>
> Thanks,
> Xiao
>
next prev parent reply other threads:[~2026-06-30 2:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 3:07 [RFC PATCH 0/8] sched: Extend cache-aware scheduling into topology-aware scheduling Jianyong Wu
2026-06-25 3:07 ` [RFC PATCH 1/8] sched/topo: Add some llc related helpers Jianyong Wu
2026-06-25 3:07 ` [RFC PATCH 2/8] sched/fair: Introduce helpers for cross-domain migration decisions Jianyong Wu
2026-06-25 3:07 ` [RFC PATCH 3/8] sched/fair: Introduce rq affinity gain calculation for migration selection Jianyong Wu
2026-06-25 3:07 ` [RFC PATCH 4/8] sched/fair: Pick optimal src rq/group using affinity promotion metric Jianyong Wu
2026-06-25 3:07 ` [RFC PATCH 5/8] sched/fair: Drop prefer_sibling restriction for llc_balance Jianyong Wu
2026-06-25 3:07 ` [RFC PATCH 6/8] sched/fair: Judge migration eligibility via NUMA-wide Jianyong Wu
2026-06-25 3:07 ` [RFC PATCH 7/8] sched: Let sched cache take precedence over NUMA balancing Jianyong Wu
2026-06-25 3:07 ` [RFC PATCH 8/8] sched/debug: Print task preferred LLC for scheduler debugging Jianyong Wu
2026-06-28 19:29 ` XIAO WU
2026-06-30 2:03 ` Jianyong Wu [this message]
2026-06-25 8:42 ` [RFC PATCH 0/8] sched: Extend cache-aware scheduling into topology-aware scheduling Peter Zijlstra
2026-06-25 12:12 ` Jianyong Wu
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=510cee91f67a4aa98d24eef7c1c59d80@hygon.cn \
--to=wujianyong@hygon.cn \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=huangsj@hygon.cn \
--cc=juri.lelli@redhat.com \
--cc=justin.he@arm.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sshegde@linux.ibm.com \
--cc=tim.c.chen@linux.intel.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=xiaowu.417@qq.com \
--cc=yingzhiwei@hygon.cn \
--cc=yu.c.chen@intel.com \
--cc=zhongyuan@hygon.cn \
/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®