From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from xmbghk7.mail.qq.com (xmbghk7.mail.qq.com [43.163.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 22BF730BB9B for ; Sun, 28 Jun 2026 19:29:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=43.163.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782674975; cv=none; b=FpnAgqMeeRXLARtBp3ud9Jz9lHwNWwLsXnECEai/0QJWLTwYh7lPzTxrf52+d/KfkbP639vulSjpiTuKT6HFzzfkELx3pBiX7dRaAiB307z7iJBCHngC12/3XNDsRFtyPAfYRG/B2gR0bFL1XUMzp3NsxtJ0YPb1hsK6nW+ial0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782674975; c=relaxed/simple; bh=fCURcPBpSFeorKthomy+WYwfQJL2cFiN0rUPB0wiXs4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jus+N/vBs40wfvTYLRUduhWvVlZxabBgbdOl2WHX9AqXN5KJnJjTNfnPFeT/5Yxg8Bk+v0413nwHbRV2wvTBaTFFCKz1ZNjjCPycFq5AR/tD2tXZmBE42MnuArotYVFvAiQT4AKn/jsGFdHzSxEUWTDJMfXioFqnnrSfrW49yQA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com; spf=pass smtp.mailfrom=qq.com; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b=CzWqxJZF; arc=none smtp.client-ip=43.163.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=qq.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b="CzWqxJZF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1782674969; bh=riGs4IzKU93Rc2IJc6sdtXsFJEpGtf7fy6lwlLzUMdM=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=CzWqxJZFYA/D/+w/1QcO22qFuy/Ert2C1Wxe+Vbw1bm0LSbIHlDzIv0aL3Lu13UJ0 FlsxEA93d0smcHfounfFTrz+uvauFHo6xIkwC9W1l0S/IAidgeNKSHSoPK998O+6DS PMKSGCyi2HGM8wteoCrSJMBDALL8Bci6yfXwTOKE= Received: from [192.168.1.102] ([223.77.180.178]) by newxmesmtplogicsvrszb43-0.qq.com (NewEsmtp) with SMTP id 7593A20A; Mon, 29 Jun 2026 03:29:25 +0800 X-QQ-mid: xmsmtpt1782674965tr6hvqw92 Message-ID: X-QQ-XMAILINFO: OOO9dHjlsLs7dkG3IjYQakC4Lx7By4uBq+nCf/dmZIWWhyBaN9jMSR3q3IVys1 tNcd4XVJ8hrQTZUCEC5xs9KnfHJXYDsLEKObsrkslBiFngqts7RC+eImSuKDfwkrNqKNGW5UtlQt EHMOQXXFlIRFDbUWQnX2TIBS/BZKs88g8tWUJF78cWvVFq43suhXDvvRQYQQJjpf+iBUPlQwsdG8 1mzTlAX22OASS7Dxq+0zKq+l3/Mdw8JeU+wGQQMhB+0tM+tg048DZM52OoyK9TaVI9lDsm2NeVYp iUBn3oaB6qrd3rXS1COmkau/h7ZTAqQ8RWn7F+pen4kAALLNFICPpQ4/oxE8vMjAfdQKgzcjUAYm K6/vNxvJrvy39+cuERiVmj+paErWW1zPdwcMDkXt7O7gs+9//WWru5O6nz+Ufy/yxlRBuPKkaKq6 nLYoH2tZnTIWFuj2GOCiDVrKXj1+yyKpbeRqOEPM7H4NiydaiJcQRN1ZpGjTm7pWrI4xE7VIHnFm 90fqcPgt0sCbQMIkrwK9xXKdy6NpUId4Gg3j67SH1hrW2sGXmj4On/GeLZ4FpwgMpEURQirKKEW5 G1TnQpgvL8kGngnGupHxPyeWZ1/QrAitSLlSYE4atvXxOqdXAu3qmH+BY7Pj4sbVaMhrY45IeOYA WEI4gN2PDiEdzczEUNBK3KmM1YPY//kAH6f2FOsLF7zomaiakSQ7d9734z9X5nVXO+PwcKLodueU gBWnwmcM5Pq3z8c7pbEq9nsmLhYomZcbOAQgZVeTppY+JdIxSEtnstNYM99cyvYHHDey2gzqXi1J ZyNaP8ydZa/uQzMM/dtqPqewlYPpjZBy0kWqCEbAEzdkLKVusXUVGUs4Xc/XSoq6pHEzfbtLbeJV 7RTnwJr206kQ+tgRKBzvDHWelinHWrcFyhQeBZvSYP/T7U7nGIhbd5MldA1HRjBj4u0KemPne1Eg 225r9mZ1mKrIqL2XOAZfg731BohjhxpsQlLyB1JXD24U8jqK37RgR67m74TDp6uacEHx++FDFnuz JPwNX+kq54PVRVDw2Lw5j8kEqG9T2uDeIaAec/8lxirJRVpSYtNu5ZWXUoT8HJEBO9gla+TrTRyC FNo8M8mRBHqAPzCYQ= X-QQ-XMRINFO: NyFYKkN4Ny6FuXrnB5Ye7Aabb3ujjtK+gg== X-OQ-MSGID: <8e4bcffc-bf28-4ccf-a978-3d68313176e6@qq.com> Date: Mon, 29 Jun 2026 03:29:25 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 8/8] sched/debug: Print task preferred LLC for scheduler debugging To: Jianyong Wu , 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, zhongyuan@hygon.cn, yingzhiwei@hygon.cn, huangsj@hygon.cn References: <20260625030759.25928-1-wujianyong@hygon.cn> <20260625030759.25928-9-wujianyong@hygon.cn> From: XIAO WU In-Reply-To: <20260625030759.25928-9-wujianyong@hygon.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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//sched while the target task is concurrently exiting. The Sashiko review is at: https://sashiko.dev/#/patchset/20260625030759.25928-1-wujianyong@hygon.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//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//sched reads.  16 worker threads each fork children and read /proc//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]  [  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]  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//sched */ #define _GNU_SOURCE #include #include #include #include #include #include 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