From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 5398117D6 for ; Wed, 7 Jan 2026 18:00:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767808846; cv=none; b=BK/vuTHH++g28kyx/ni/qhrrWB/WTWwoHXoVVGbvioAWJCW9rkOn+XVPINuRrxWc6NLKnPbRUiuviWNwLJVUASO+dZcA/Eu/mBIyf1RctlfpZ+RTyAJ71gOyKSwB7WVGlvAuIxvPRAJezH2nl0DhYCgoE34nfLC2m3tZ7s8sqM4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767808846; c=relaxed/simple; bh=TBM7uTcwQ1bhgJzbH2jTgWdePSHHKs1m1qnQD6LGWns=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CDI46v3MJN62a8qLn1Fj2oVXtRsvXhDMbzfSdXwWpI99h1jKSquDlpCii4Se+ueeWVAmzV+E3iJAIWKSHS+vIluTeXmX/lJEIM6YhsUTmPPR8VSdzKk9v5KQX7/ErucxGZ0tRf7KG4pkzEFt2w5s8816FDEv3FR1/C7ovsZpp6k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PAu/TE4I; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PAu/TE4I" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78D78C4CEF1; Wed, 7 Jan 2026 18:00:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767808845; bh=TBM7uTcwQ1bhgJzbH2jTgWdePSHHKs1m1qnQD6LGWns=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PAu/TE4ILh6N8g9bSsktYm4sw6QrLDxCar0UKmD4uOKaLzDitGTvt2Mrw8WkIaEHh DRCrhHif5y6xpMiNhMsFnHWKzEMpUCFPUbkAcr3ZlFPt9ujiklvdes5DRhB+7IWhAz 2ETFj7YDASUyI/vMbzXkZ1zbBy62WDyNHyZhoMV2aow/LZuR2f0aD3aSy4tVr4NdKF j59Nzcou5rbmYdq+9Ri4S5627kCEXomePjqaM2faTFPfLUC2jV0bBj7R7Y0HIFV/oy l/vgBgmeXlKdbeBj4jJ4qqsA6BIwDITjlqEJJ4HgXr7ZESGhT4CIOyL5j1sS9/10cp uNwKzwCx2OJnA== Date: Wed, 7 Jan 2026 18:00:41 +0000 From: Will Deacon To: Cong Wang Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, mathieu.desnoyers@efficios.com, Cong Wang , Thomas Gleixner Subject: Re: [PATCH] sched: Fix NULL mm dereference in sched_mm_cid_after_execve() Message-ID: References: <20251223215113.639686-1-xiyou.wangcong@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251223215113.639686-1-xiyou.wangcong@gmail.com> On Tue, Dec 23, 2025 at 01:51:13PM -0800, Cong Wang wrote: > From: Cong Wang > > sched_mm_cid_after_execve() is called in bprm_execve()'s cleanup path > even when exec_binprm() fails. For the init task's first execve, this > causes a problem: > > 1. current->mm is NULL (kernel threads don't have an mm) > 2. sched_mm_cid_before_execve() exits early because mm is NULL > 3. exec_binprm() fails (e.g., ENOENT for missing script interpreter) > 4. sched_mm_cid_after_execve() is called with mm still NULL > 5. sched_mm_cid_fork() is called unconditionally, triggering WARN_ON > > This is easily reproduced by booting with an init that is a shell script > (#!/bin/sh) where the interpreter doesn't exist in the initramfs. > > Fix this by checking if t->mm is NULL before calling sched_mm_cid_fork(), > matching the behavior of sched_mm_cid_before_execve() which already > handles this case via sched_mm_cid_exit()'s early return. > > Fixes: b0c3d51b54f8 ("sched/mmcid: Provide precomputed maximal value") > Cc: Thomas Gleixner > Signed-off-by: Cong Wang > --- > kernel/sched/core.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 41ba0be16911..60afadb6eede 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -10694,10 +10694,11 @@ void sched_mm_cid_before_execve(struct task_struct *t) > sched_mm_cid_exit(t); > } > > -/* Reactivate MM CID after successful execve() */ > +/* Reactivate MM CID after execve() */ > void sched_mm_cid_after_execve(struct task_struct *t) > { > - sched_mm_cid_fork(t); > + if (t->mm) > + sched_mm_cid_fork(t); > } > > static void mm_cid_work_fn(struct work_struct *work) This addresses a panic reported on arm64 when trying to execute x86 binaries using TCG on an Apple device: https://lore.kernel.org/all/20251226192506.88593-1-za4emsu@gmail.com/ so: Acked-by: Will Deacon Please can we land this for 6.19? Cheers, Will