public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Ihor Solodrai <ihor.solodrai@linux.dev>,
	Shrikanth Hegde <sshegde@linux.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Michael Jeanson <mjeanson@efficios.com>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	Alexander Potapenko <glider@google.com>,
	"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>
Subject: [PATCH] sched/mmcid: Don't assume CID is CPU owned on mode switch
Date: Tue, 10 Feb 2026 17:20:51 +0100	[thread overview]
Message-ID: <87tsvoa7to.ffs@tglx> (raw)
In-Reply-To: <aYtE2xHG2A8DWWmD@shinmob>

Shinichiro reported a KASAN UAF, which is actually an out of bounds access
in the MMCID management code.

   CPU0						CPU1
   						T1 runs in userspace
   T0: fork(T4) -> Switch to per CPU CID mode
         fixup() set MM_CID_TRANSIT on T1/CPU1
   T4 exit()
   T3 exit()
   T2 exit()
						T1 exit() switch to per task mode
						 ---> Out of bounds access.

As T1 has not scheduled after T0 set the TRANSIT bit, it exits with the
TRANSIT bit set. sched_mm_cid_remove_user() clears the TRANSIT bit in
the task and drops the CID, but it does not touch the per CPU storage.
That's functionally correct because a CID is only owned by the CPU when
the ONCPU bit is set, which is mutually exclusive with the TRANSIT flag.

Now sched_mm_cid_exit() assumes that the CID is CPU owned because the
prior mode was per CPU. It invokes mm_drop_cid_on_cpu() which clears the
not set ONCPU bit and then invokes clear_bit() with an insanely large
bit number because TRANSIT is set (bit 29).

Prevent that by actually validating that the CID is CPU owned in
mm_drop_cid_on_cpu().

Fixes: 007d84287c74 ("sched/mmcid: Drop per CPU CID immediately when switching to per task mode")
Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Tested-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/aYsZrixn9b6s_2zL@shinmob
---

Linus, can you please take that directly?

---
 kernel/sched/core.c  |    7 +++----
 kernel/sched/sched.h |    6 ++++--
 2 files changed, 7 insertions(+), 6 deletions(-)

--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -10729,10 +10729,9 @@ void sched_mm_cid_exit(struct task_struc
 					return;
 				/*
 				 * Mode change. The task has the CID unset
-				 * already. The CPU CID is still valid and
-				 * does not have MM_CID_TRANSIT set as the
-				 * mode change has just taken effect under
-				 * mm::mm_cid::lock. Drop it.
+				 * already and dealt with an eventually set
+				 * TRANSIT bit. If the CID is owned by the CPU
+				 * then drop it.
 				 */
 				mm_drop_cid_on_cpu(mm, this_cpu_ptr(mm->mm_cid.pcpu));
 			}
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -3762,8 +3762,10 @@ static __always_inline void mm_unset_cid
 static __always_inline void mm_drop_cid_on_cpu(struct mm_struct *mm, struct mm_cid_pcpu *pcp)
 {
 	/* Clear the ONCPU bit, but do not set UNSET in the per CPU storage */
-	pcp->cid = cpu_cid_to_cid(pcp->cid);
-	mm_drop_cid(mm, pcp->cid);
+	if (cid_on_cpu(pcp->cid)) {
+		pcp->cid = cpu_cid_to_cid(pcp->cid);
+		mm_drop_cid(mm, pcp->cid);
+	}
 }
 
 static inline unsigned int __mm_get_cid(struct mm_struct *mm, unsigned int max_cids)

  reply	other threads:[~2026-02-10 16:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-02  9:39 [patch V2 0/4] sched/mmcid: Cure mode transition woes Thomas Gleixner
2026-02-02  9:39 ` [patch V2 1/4] sched/mmcid: Prevent live lock on task to CPU mode transition Thomas Gleixner
2026-02-02 14:50   ` Mathieu Desnoyers
2026-02-04 13:27   ` [tip: sched/urgent] " tip-bot2 for Thomas Gleixner
2026-02-02  9:39 ` [patch V2 2/4] sched/mmcid: Protect transition on weakly ordered systems Thomas Gleixner
2026-02-02 14:53   ` Mathieu Desnoyers
2026-02-04 13:27   ` [tip: sched/urgent] " tip-bot2 for Thomas Gleixner
2026-02-02  9:39 ` [patch V2 3/4] sched/mmcid: Drop per CPU CID immediately when switching to per task mode Thomas Gleixner
2026-02-04 13:27   ` [tip: sched/urgent] " tip-bot2 for Thomas Gleixner
2026-02-10  7:33   ` [patch V2 3/4] " Shinichiro Kawasaki
2026-02-10 10:44     ` Thomas Gleixner
2026-02-10 11:51       ` Shinichiro Kawasaki
2026-02-10 13:03         ` Peter Zijlstra
2026-02-10 14:15           ` Shinichiro Kawasaki
2026-02-10 13:33         ` Thomas Gleixner
2026-02-10 14:55           ` Shinichiro Kawasaki
2026-02-10 16:20             ` Thomas Gleixner [this message]
2026-02-10 16:28               ` [PATCH] sched/mmcid: Don't assume CID is CPU owned on mode switch Mathieu Desnoyers
2026-02-11 10:33               ` Takashi Iwai
2026-02-11 21:00               ` Linus Torvalds
2026-02-02  9:39 ` [patch V2 4/4] sched/mmcid: Optimize transitional CIDs when scheduling out Thomas Gleixner
2026-02-02 14:56   ` Mathieu Desnoyers
2026-02-04 13:27   ` [tip: sched/urgent] " tip-bot2 for Thomas Gleixner
2026-02-02 10:14 ` [patch V2 0/4] sched/mmcid: Cure mode transition woes Peter Zijlstra
2026-02-02 11:46   ` Mathieu Desnoyers
2026-02-02 12:54     ` Peter Zijlstra
2026-02-02 21:22       ` Mathieu Desnoyers
2026-02-04 10:53       ` 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=87tsvoa7to.ffs@tglx \
    --to=tglx@kernel.org \
    --cc=glider@google.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mjeanson@efficios.com \
    --cc=peterz@infradead.org \
    --cc=ryabinin.a.a@gmail.com \
    --cc=shinichiro.kawasaki@wdc.com \
    --cc=sshegde@linux.ibm.com \
    --cc=torvalds@linux-foundation.org \
    /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