From nobody Fri Oct 2 06:58:30 2026 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 0D7C94570C7; Tue, 4 Aug 2026 08:50:54 +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=1785833455; cv=none; b=knC4PWN3wlGQ4Svs5BuAKm8cC86bY0WJCMqxds4/mBJasH7/YWLWmbkXLj1SGOc+S2bsG/wsK9KJgofyxOKbp5UZShrGZukyn0pY8eOhsFHHltvaF4vAfH126DKGP8VnADW/WZR/F0z51px7DsFWCyv+Vq18wt0tcEvb7DvZUDI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785833455; c=relaxed/simple; bh=Wg4a5GYB2+hy3rEJTPDy6EHTyRLohXwG7vmwER8t2Ps=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=lipP7ygJW96ZcbHM8OSbLT1C/2+6K3WME4hfW0oWfIw7etz0x/7Y/Ke3zEBN6LLKHLlEjEIO0C3hmzGxURrvfsrAK6dILhaRuwuQN8GjTmZWp01112xcA8zaSp+6JShZ3LAlJSby+w6ofE5Y+JkPR8aVKuZ4Q2KZ8FrIduNyrNs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=f7oii5zk; 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="f7oii5zk" Received: by smtp.kernel.org (Postfix) with ESMTPS id 8B9DDC2BCF7; Tue, 4 Aug 2026 08:50:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1785833454; bh=Wg4a5GYB2+hy3rEJTPDy6EHTyRLohXwG7vmwER8t2Ps=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=f7oii5zktCjjdWcUS97nDJCz3QoJlcSOSLdMHx7F8kFdlcDx1MzzBAKKCpsbSdD5d tHZvvGLDnf9NNMlz+KVnFuwMs185XmgGbwDmTzOyaAKzQVXa3LHvzoccDbFP1jjgAR Z0YOFHXMYpvqCaa3TNT0jc2LRNvCoMwJzJxQTrxnTiGTji41xGgy+yI5GgJgA6EnnC Csh8I/TF8uxE3ddyvpv7pFtPJpHhrquC+yEY7xHz3Lt+BtwBT4VqaYjp1dxAdfawE3 2WlMKRLh8j6JkZOx52K5SQIxMDGI9WPTWcHwOhY4wK4/+SfhtCdWr80VEqSjwI6Bi6 BwrBuM4MwZBbw== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79615C5518F; Tue, 4 Aug 2026 08:50:54 +0000 (UTC) From: Junrui Luo via B4 Relay Date: Tue, 04 Aug 2026 16:50:38 +0800 Subject: [PATCH v2 1/5] powerpc/spufs: fix spu_context leak in coredump 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="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260804-fixes-v2-1-5bfd827297f9@outlook.com> References: <20260804-fixes-v2-0-5bfd827297f9@outlook.com> In-Reply-To: <20260804-fixes-v2-0-5bfd827297f9@outlook.com> To: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Arnd Bergmann , Paul Mackerras , Al Viro Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Yuhao Jiang , stable@vger.kernel.org, Junrui Luo X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=1758; i=moonafterrain@outlook.com; h=from:subject:message-id; bh=XdWocYlkrxGjIsGC8gAbyPABgvp/vlZdqZWZhKwsHTk=; b=owJ4nJvAy8zAJVb4wiKgu++DA+NptSSGrMLlr7OeK/LPnp5999fChz+TfA179+0qld6/7q/xO ieVZTIeoYYdpSwMYlwMsmKKLMcLLn2z8N2iu8VnSzLMHFYmkCEMXJwCMJHTKxgZ9q9epFt57ONa FmvF/w99a1zkVzS0n30q9Dba+YW1/SzFJQz/Y8tOfZ3JdntNbvtHp2MM8ZbuX1+pzb4/40pz171 sc7nLHADYSE9b X-Developer-Key: i=moonafterrain@outlook.com; a=openpgp; fpr=C770D2F6384DB42DB44CB46371E838508B8EF040 X-Endpoint-Received: by B4 Relay for moonafterrain@outlook.com/default with auth_id=909 X-Original-From: Junrui Luo Reply-To: moonafterrain@outlook.com From: Junrui Luo coredump_next_context() returns a spu_context with a reference taken by get_spu_context(), which the caller must drop. spufs_coredump_extra_notes_size() does so on all of its exits, but spufs_coredump_extra_notes_write() never calls put_spu_context(), so every context dumped through elf_coredump_extra_notes_write() leaks a reference, including on the success path. Fix by dropping the reference on each of the three exits of the loop, mirroring ..._size(). Fixes: 38b407be172d ("powerpc/spufs: Rework fcheck() usage") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo --- arch/powerpc/platforms/cell/spufs/coredump.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/cell/spufs/coredump.c b/arch/powerpc/pl= atforms/cell/spufs/coredump.c index 301ee7d8b7df..f5964c9ebb3e 100644 --- a/arch/powerpc/platforms/cell/spufs/coredump.c +++ b/arch/powerpc/platforms/cell/spufs/coredump.c @@ -162,13 +162,16 @@ int spufs_coredump_extra_notes_write(struct coredump_= params *cprm) fd =3D 0; while ((ctx =3D coredump_next_context(&fd)) !=3D NULL) { rc =3D spu_acquire_saved(ctx); - if (rc) + if (rc) { + put_spu_context(ctx); return rc; + } =20 for (j =3D 0; spufs_coredump_read[j].name !=3D NULL; j++) { rc =3D spufs_arch_write_note(ctx, j, cprm, fd); if (rc) { spu_release_saved(ctx); + put_spu_context(ctx); return rc; } } @@ -177,6 +180,7 @@ int spufs_coredump_extra_notes_write(struct coredump_pa= rams *cprm) =20 /* start searching the next fd next time */ fd++; + put_spu_context(ctx); } =20 return 0; --=20 2.51.2 From nobody Fri Oct 2 06:58:30 2026 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 21D9A43E483; Tue, 4 Aug 2026 08:50:55 +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=1785833455; cv=none; b=Pd0QUQPIsd4vFI82g/8v3Y4IKsNmMmapRl8y+3cKijLV1u5wCwHuJL3N7GgCyZdCg9zc2BqT9G7xUGIw3cSyTddNIGHHDhPiXVLEwCBDwla3JQbNchodADrOoXkFra3Zm0kG+kkNLtt7vs7j7qs/U91xkgNQFHfuS6yUGzGZM4Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785833455; c=relaxed/simple; bh=ouoOtFQsDph48bmUIg1nnMKtB6spdEtljACvUOhmbI4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=QcAdFndA/JJbPLuE994dtZeXhY/VW1SpxqqRYBiVOopf311fnsqAcFW9IG1is/x0aSmIC3OYwURGYuMKQJxLuOVEWuDAdxdqjqURVe7oQ8d8woZLjsboyBhSYB0YyOXatfNzq+ks8f/PhEPjqanHWijdWPdaaljEV+T8vsVwNSo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gguxmrpl; 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="gguxmrpl" Received: by smtp.kernel.org (Postfix) with ESMTPS id A1F8AC2BCFB; Tue, 4 Aug 2026 08:50:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1785833454; bh=ouoOtFQsDph48bmUIg1nnMKtB6spdEtljACvUOhmbI4=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=gguxmrplHdHMu6GDamNp9kq6vmj2XLV+qreDsyqBBjorxNEEJeHDt6IF3DxgrQ1B2 VXEDqWcHu5yc1KWKn/ymtIlS81CVNqHsbbBeCFLaPEOfJXlvZoup7endt3l634HvxU Bmf83urhBrHpq8A+Ls3wrniDsTC8xWDqIihCfkXSs6n8PEyQ5OFeTIHuOk7R4LC5Jb YnmqOgIhT764/v/D15tstznlIOtmcAMaHz4s86mVGT3/1QUnnFL52QjVy6rFIjWtdC 8X8n7dNhgyd0sf0NmwqjQcBCrhTpDnXCrCagKSlYfEtwbksCFxh219MhouQ0ky+8dv 2fulpVgekhrpA== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90A6FC55172; Tue, 4 Aug 2026 08:50:54 +0000 (UTC) From: Junrui Luo via B4 Relay Date: Tue, 04 Aug 2026 16:50:39 +0800 Subject: [PATCH v2 2/5] powerpc/spufs: don't leak kernel stack via spu_run 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="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260804-fixes-v2-2-5bfd827297f9@outlook.com> References: <20260804-fixes-v2-0-5bfd827297f9@outlook.com> In-Reply-To: <20260804-fixes-v2-0-5bfd827297f9@outlook.com> To: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Arnd Bergmann , Paul Mackerras , Al Viro Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Yuhao Jiang , stable@vger.kernel.org, Junrui Luo X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=1592; i=moonafterrain@outlook.com; h=from:subject:message-id; bh=/mYJIr4Rrbt5tK8GuImhcqAYaBw3DdGgKByxedyucEU=; b=owJ4nJvAy8zAJVb4wiKgu++DA+NptSSGrMLlb76tSgqwj18YnOrQtpRllZ+6sNpx9hVr2ztMT 858m3mM+UhHKQuDGBeDrJgiy/GCS98sfLfobvHZkgwzh5UJZAgDF6cATERHieF/mvPSy7E9malK PlmZPR+Wzz/ROOVmBp/wilU6jdlqLCuUGBnmLxSLLDwzZcfSuzcrt6xU2XNXM03EWid2SpTa7Hm F8pN5AWe+SRo= X-Developer-Key: i=moonafterrain@outlook.com; a=openpgp; fpr=C770D2F6384DB42DB44CB46371E838508B8EF040 X-Endpoint-Received: by B4 Relay for moonafterrain@outlook.com/default with auth_id=909 X-Original-From: Junrui Luo Reply-To: moonafterrain@outlook.com From: Junrui Luo do_spu_run() hands the address of an uninitialized local to spufs_run_spu() and then copies it out unconditionally: u32 npc, status; ... ret =3D spufs_run_spu(i->i_ctx, &npc, &status); ... if (ustatus && put_user(status, ustatus)) ret =3D -EFAULT; spufs_run_spu() writes through that pointer at exactly one place, the "out:" label, and two of its exits never reach it: the interruptible acquisition of ctx->run_mutex returns -ERESTARTSYS directly, and a failed spu_acquire() jumps to "out_unlock", which sits just after the assignment. Initialize status to 0, which is what userspace would have observed had the assignment been reached anyway: spufs_run_spu() resets ctx->event_return to 0 on entry, and 0 is the "no events pending" value for this word. Fixes: 67207b9664a8 ("[PATCH] spufs: The SPU file system, base") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo --- arch/powerpc/platforms/cell/spufs/syscalls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/cell/spufs/syscalls.c b/arch/powerpc/pl= atforms/cell/spufs/syscalls.c index ea4ba1b6ce6a..549fcfbbc140 100644 --- a/arch/powerpc/platforms/cell/spufs/syscalls.c +++ b/arch/powerpc/platforms/cell/spufs/syscalls.c @@ -37,7 +37,7 @@ static long do_spu_run(struct file *filp, { long ret; struct spufs_inode_info *i; - u32 npc, status; + u32 npc, status =3D 0; =20 ret =3D -EFAULT; if (get_user(npc, unpc)) --=20 2.51.2 From nobody Fri Oct 2 06:58:30 2026 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 0CE984570C5; Tue, 4 Aug 2026 08:50:55 +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=1785833455; cv=none; b=ssJUJ/GDQT5EShZteDDcH541ZnQENr0KKynpI0zuGl3Jim0/o92mW215K61aXtfm9bjqyvD9Oj5EyLFjupbun/SV3wXLqZDRM2JwNl5z9kHBAUr2I04i/onqAqX6bXwvBTywdlH6r8Rw6gg1WWxvGOmZloRdv80OX3sgrrzh6Co= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785833455; c=relaxed/simple; bh=afJAMLbhFODoEcveLVFFRIw8h+QDoAijPxkIMhvX5Oc=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=q1rOIoo2Qdwbe1o3HcQ+jj4VKoAgU9u5OgPzNm3jJ+3JDImR65/K/gTNzDFHNEpGYmfR37oKCAQ3hpt2F26aq4zBj+ulOMTFogolbnr7nJaq3WoX2c//BEYEs2oZDxTNPt3W4XGJpaooPnDiVOw+KenAwCZLj0wT8B/3oRKDMA8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eU4dTuRI; 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="eU4dTuRI" Received: by smtp.kernel.org (Postfix) with ESMTPS id B7D39C2BCFD; Tue, 4 Aug 2026 08:50:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1785833454; bh=afJAMLbhFODoEcveLVFFRIw8h+QDoAijPxkIMhvX5Oc=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=eU4dTuRIPB4xWAu9Ya4VG5C95yTBDgyq2cEThTJGEvoWzxaI8blP/rPPPZx1tsPXA qUx5LyIX4ZvGzGUMaN42zS9TmqJ5YVTYhLz8JyEhttnja7m6dNSZACKV5rFkb8Et+z 5Ud1ioWuadi6TjLP+SuqYrEcK7fU/AOXS/MJDjdbo+PLtQjj+UZ7JTRkXfJ1H9GCq1 U+wP9fVDVBYqcqfe206tWQiTcN8gzk/IJLMMfsQ2i9OHCcd/9AtYC+Pm5YfuEJ/XAx NGXxTFnjOwXudiphSsTNR0x09cvaiIMenlxh2anYjzxPpQ0uwUh1YCYoxwQeEA4jUT TCell6G3Nke9w== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id A55DEC55ABA; Tue, 4 Aug 2026 08:50:54 +0000 (UTC) From: Junrui Luo via B4 Relay Date: Tue, 04 Aug 2026 16:50:40 +0800 Subject: [PATCH v2 3/5] powerpc/spufs: check permissions in spufs_setattr() 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="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260804-fixes-v2-3-5bfd827297f9@outlook.com> References: <20260804-fixes-v2-0-5bfd827297f9@outlook.com> In-Reply-To: <20260804-fixes-v2-0-5bfd827297f9@outlook.com> To: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Arnd Bergmann , Paul Mackerras , Al Viro Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Yuhao Jiang , stable@vger.kernel.org, Junrui Luo X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=1714; i=moonafterrain@outlook.com; h=from:subject:message-id; bh=dffeiU9SuIG2crRu8M1hNRxZHn/iEzt/PMyihiDEjKQ=; b=owJ4nJvAy8zAJVb4wiKgu++DA+NptSSGrMLlbxTVjPNSXmaeOhL321xIPc/iZOt5vyTxgAsyW xgYFVrab3eUsjCIcTHIiimyHC+49M3Cd4vuFp8tyTBzWJlAhjBwcQrARJScGBkeBFrNO/D0QJBQ //p0rZh1Xe/62jdz7osUfpo4W4BxVdcmRob9zxY7Pl1XmXm4LKPmtcy9NE23/HCHklOHvq/d6bh B8z4fAOdOSp8= X-Developer-Key: i=moonafterrain@outlook.com; a=openpgp; fpr=C770D2F6384DB42DB44CB46371E838508B8EF040 X-Endpoint-Received: by B4 Relay for moonafterrain@outlook.com/default with auth_id=909 X-Original-From: Junrui Luo Reply-To: moonafterrain@outlook.com From: Junrui Luo spufs_setattr() applies the caller's attributes with setattr_copy() but never calls setattr_prepare(). notify_change() leaves that to the filesystem: it runs only may_setattr(), while inode_owner_or_capable() and the CAP_CHOWN test live inside setattr_prepare(). setattr_copy() performs no checking of its own. The handler is installed for every regular spufs file, so mode and ownership of another user's context files can be changed without the usual authorization. Call setattr_prepare() before setattr_copy(). The existing ATTR_SIZE test stays ahead of it so that resizing a spufs file keeps returning -EINVAL. &nop_mnt_idmap matches the adjacent setattr_copy() call. Fixes: 67207b9664a8 ("[PATCH] spufs: The SPU file system, base") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo --- arch/powerpc/platforms/cell/spufs/inode.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platf= orms/cell/spufs/inode.c index 2b54afb31529..c2b15c30f7c0 100644 --- a/arch/powerpc/platforms/cell/spufs/inode.c +++ b/arch/powerpc/platforms/cell/spufs/inode.c @@ -96,10 +96,14 @@ spufs_setattr(struct mnt_idmap *idmap, struct dentry *d= entry, struct iattr *attr) { struct inode *inode =3D d_inode(dentry); + int ret; =20 if ((attr->ia_valid & ATTR_SIZE) && (attr->ia_size !=3D inode->i_size)) return -EINVAL; + ret =3D setattr_prepare(&nop_mnt_idmap, dentry, attr); + if (ret) + return ret; setattr_copy(&nop_mnt_idmap, inode, attr); mark_inode_dirty(inode); return 0; --=20 2.51.2 From nobody Fri Oct 2 06:58:30 2026 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 21E494570C9; Tue, 4 Aug 2026 08:50:55 +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=1785833455; cv=none; b=MkUAX7RgB9IB/Ki8+atqRchHIrgOPS9lLKopipQsHYYkx9aU7ufeIQBQJkN1GpHsq2VGtSxuslck+6O1WAqDs3XeeXp1lFoT8txERa6meEMBMdLmnQbhwwqNk/xIc/ham6cp1w08GR5OmX5enW/Uhs99q2l7ziEca+DxQECGVek= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785833455; c=relaxed/simple; bh=GhANxRpAyu/KCkIgpDUCIepXUdGoiRJbd1x17Sr/Kvs=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=X4ozn099MIFSDYsxha7A4O7GWcu8qiY+2nStwUY6qiH6W5T6VbIKkcOJNXKKUC21mprIcZkC2bOy7+4zGt5Cf1h91Jm2nxdl3KxEdeDfff6Kp/4u44M7bgbBeOtgCSiBIOW/b5g33/AU1d8dsMPy2Iz/Pfg86RtLvXx/ltzpsPw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ESKSqjXX; 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="ESKSqjXX" Received: by smtp.kernel.org (Postfix) with ESMTPS id CC29AC32781; Tue, 4 Aug 2026 08:50:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1785833454; bh=GhANxRpAyu/KCkIgpDUCIepXUdGoiRJbd1x17Sr/Kvs=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=ESKSqjXXa/wn/WkDXS6jeQObwDt3s3LJL2VCNJtAq+gbamyvwb91t4WesJ6a0MkuF u6z8UADaF7/oyby9sJLP/sudQIhzgqv2G/h+sEvwpu8CJpE5oUI2XFB/FZsNVEmHlV laV3cnpTU6Ru/6Cj8djZKLQZEWa4nlX8gRMz+v+m7/Xw5oy/KLb16wvHdNHJKdK7mo L9AerNX+KEWbfBbuzkok7ptVIHqfIh3sPaeB6Sq4JFRSRajhwTYsAUhebyD4HxQERX 9stg7Ibc0oo2vPFSO2ZGZNbB+qKyBroWRdt6GiQrdrPzhDt6BRgC6an0XRFk0daZ8c cnV9UqiitqlDg== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id B96FEC55184; Tue, 4 Aug 2026 08:50:54 +0000 (UTC) From: Junrui Luo via B4 Relay Date: Tue, 04 Aug 2026 16:50:41 +0800 Subject: [PATCH v2 4/5] powerpc/spufs: fix deadlock on gang creation failure 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="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260804-fixes-v2-4-5bfd827297f9@outlook.com> References: <20260804-fixes-v2-0-5bfd827297f9@outlook.com> In-Reply-To: <20260804-fixes-v2-0-5bfd827297f9@outlook.com> To: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Arnd Bergmann , Paul Mackerras , Al Viro Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Yuhao Jiang , stable@vger.kernel.org, Junrui Luo X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=3038; i=moonafterrain@outlook.com; h=from:subject:message-id; bh=Cj2YqlgaZpS5pzQnZtV4Ucl3WQDjefs7reGQ8GjrlS8=; b=owJ4nJvAy8zAJVb4wiKgu++DA+NptSSGrMLlb6z8KpX3rjeYmVNQWXmXr2Xh382Xyje/KLY+2 nnSZjNXTHJHKQuDGBeDrJgiy/GCS98sfLfobvHZkgwzh5UJZAgDF6cATET+C8P/jOTkSPaFHw5L OU67oNHz4MRr8YNf2Pv/vnI1YN/4yDSBm5Hh+b7oApZtpxPcZ/qdOWIkHVpfw7Jnd0M8z7Qpv6W cdfZwAgCYhkxU X-Developer-Key: i=moonafterrain@outlook.com; a=openpgp; fpr=C770D2F6384DB42DB44CB46371E838508B8EF040 X-Endpoint-Received: by B4 Relay for moonafterrain@outlook.com/default with auth_id=909 X-Original-From: Junrui Luo Reply-To: moonafterrain@outlook.com From: Junrui Luo do_spu_create() enters spufs with the parent directory's i_rwsem held for write, taken as I_MUTEX_PARENT by start_creating_user_path() and dropped only by end_creating_path(). When spufs_gang_open() fails inside that window, spufs_create_gang() cleans up by calling unuse_gang(). The gang was just created, so gang->alive drops to 0 and unuse_gang() proceeds to simple_recursive_removal(), which takes the parent inode's i_rwsem as I_MUTEX_CHILD. This leads to the task blocking on an rwsem it already holds, leaving the spufs directory write-locked. The other two callers of unuse_gang() do not hold the parent lock: spufs_gang_close() runs from ->release, and spufs_dir_close() drops the parent lock first. Tell unuse_gang() which context it is called from, and use locked_recursive_removal() when the parent is already held. This matches spufs_rmdir(), which spufs_create_context() already uses for the same cleanup under the same lock. Fixes: c134deabf478 ("spufs: fix gang directory lifetimes") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo --- arch/powerpc/platforms/cell/spufs/inode.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platf= orms/cell/spufs/inode.c index c2b15c30f7c0..998512409552 100644 --- a/arch/powerpc/platforms/cell/spufs/inode.c +++ b/arch/powerpc/platforms/cell/spufs/inode.c @@ -175,7 +175,8 @@ static int spufs_fill_dir(struct dentry *dir, return 0; } =20 -static void unuse_gang(struct dentry *dir) +/* @parent_locked: caller holds dir->d_parent's i_rwsem as I_MUTEX_PARENT = */ +static void unuse_gang(struct dentry *dir, bool parent_locked) { struct inode *inode =3D dir->d_inode; struct spu_gang *gang =3D SPUFS_I(inode)->i_gang; @@ -187,8 +188,12 @@ static void unuse_gang(struct dentry *dir) dead =3D !--gang->alive; inode_unlock(inode); =20 - if (dead) - simple_recursive_removal(dir, NULL); + if (dead) { + if (parent_locked) + locked_recursive_removal(dir, NULL); + else + simple_recursive_removal(dir, NULL); + } } } =20 @@ -204,7 +209,7 @@ static int spufs_dir_close(struct inode *inode, struct = file *file) spufs_rmdir(parent, dir); inode_unlock(parent); =20 - unuse_gang(dir->d_parent); + unuse_gang(dir->d_parent, false); return dcache_dir_close(inode, file); } =20 @@ -483,7 +488,7 @@ spufs_mkgang(struct inode *dir, struct dentry *dentry, = umode_t mode) =20 static int spufs_gang_close(struct inode *inode, struct file *file) { - unuse_gang(file->f_path.dentry); + unuse_gang(file->f_path.dentry, false); return dcache_dir_close(inode, file); } =20 @@ -520,7 +525,7 @@ static int spufs_create_gang(struct inode *inode, if (!ret) { ret =3D spufs_gang_open(&path); if (ret < 0) - unuse_gang(dentry); + unuse_gang(dentry, true); } return ret; } --=20 2.51.2 From nobody Fri Oct 2 06:58:30 2026 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 52F094570D4 for ; Tue, 4 Aug 2026 08:50:55 +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=1785833455; cv=none; b=ubrT3y5BHcO5JiSHCfOJWVldi6exCO4lSbWbbHYF33ZPCx+l1sZeBEVlJVU3UxvL2VrrTERKe+dLhBYJ5FR3RPPrW9BjA9ROAqNm1UW8Qz+N1iPlmGyK+7ellU5SQCUMcW3F910D/DmVAlbw/pRxG7C2OZFezA4cC12/4Ckh8w8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785833455; c=relaxed/simple; bh=ZtasH00Gtaye4COuWzJy5xkppQxUaxhZHuqL8IELU2k=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=JSX/LYG6hPd3BCmFsBpXD6svKDPwyTCri1RAR3eAobOdxSGyDsagJ63PRbyPlPp2E/e9qtcASOL3Ziyx1cESNP7NOciBgTXDpaetAiR8CDdzZgoDHC2icS/N97KLhSMMtpIh4WoqEyhNa35+hYMiCDYMbLXN3xDyYHkcgeKDqnE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=P19dTpF7; 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="P19dTpF7" Received: by smtp.kernel.org (Postfix) with ESMTPS id E6633C4AF0B; Tue, 4 Aug 2026 08:50:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1785833454; bh=ZtasH00Gtaye4COuWzJy5xkppQxUaxhZHuqL8IELU2k=; h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From; b=P19dTpF7mG9EBb0xjFnTTHMB2aaC+L7oaIAlFAN18QkFPqaCLB6hQQwBIuF7MJOEm 3Us7m/CEjeIUDLTTOSl7odszxI7wWiuJlLQLcZ9wEb9XEWgyKz9Crx+tXMxPHM7g4i CfHaENDIYJtjmG9C6SIt0k8vea+anxq460I1FjW4zof49JnMIoAM7bNfsHJFjO5fG9 dIg75ZBzJl1pttY1aHxqy7h7GxNNMB9oqYJctO5idhaDGUItWvMxKeI7gJTHW6Q1PR jOQ6vgvyM7uPgTc/FZY8kagR+cAYXdyln3Z7BfecdEG3Qp6SWg2z9zaElJ7KJS8mol H9RR8TNc1SShA== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id D46AFC5518F; Tue, 4 Aug 2026 08:50:54 +0000 (UTC) From: Junrui Luo via B4 Relay Date: Tue, 04 Aug 2026 16:50:42 +0800 Subject: [PATCH v2 5/5] powerpc/spufs: don't hold state_mutex during user access 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="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260804-fixes-v2-5-5bfd827297f9@outlook.com> References: <20260804-fixes-v2-0-5bfd827297f9@outlook.com> In-Reply-To: <20260804-fixes-v2-0-5bfd827297f9@outlook.com> To: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Arnd Bergmann , Paul Mackerras , Al Viro Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Yuhao Jiang , Junrui Luo X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=4105; i=moonafterrain@outlook.com; h=from:subject:message-id; bh=KVNqgEF0+C48K+PWMOxfS0uXgoSuZZMWuvz93e4utzw=; b=owJ4nJvAy8zAJVb4wiKgu++DA+NptSSGrMLlb6bXFGww1mD9ovLjdb0VZ+ON3WvjZ53b3SEpX W/vPO166beOUhYGMS4GWTFFluMFl75Z+G7R3eKzJRlmDisTyBAGLk4BmMipRkaGk8dilnY+3yn6 k3OurXqRd4RVwOqfksvaF2j82SdzU6CqlpFh7beF5s5RSafO/lj8pNOgNu+csZmB0eJv37WtD95 PO2PGBgB+bE2s X-Developer-Key: i=moonafterrain@outlook.com; a=openpgp; fpr=C770D2F6384DB42DB44CB46371E838508B8EF040 X-Endpoint-Received: by B4 Relay for moonafterrain@outlook.com/default with auth_id=909 X-Original-From: Junrui Luo Reply-To: moonafterrain@outlook.com From: Junrui Luo spufs_mbox_read(), spufs_ibox_read() and spufs_wbox_write() take the context state_mutex with spu_acquire() and only drop it once their transfer loop has finished, so every put_user()/get_user() in those loops runs with the mutex held. The faulting address comes from userspace, so the fault can be made to take arbitrarily long via userfaultfd region or a FUSE-backed mapping. Drop the mutex around the user accesses: acquire it per mailbox element, just long enough for the ctx->ops mailbox operation, and release it before touching the user buffer. spufs_switch_log_read() has the same problem but its loop needs the lock for more than just the copy. Fixes: cdcc89bb1c6e ("[POWERPC] spufs: make mailbox functions handle multip= le elements") Reported-by: Yuhao Jiang Assisted-by: Claude:claude-opus-5 Signed-off-by: Junrui Luo --- arch/powerpc/platforms/cell/spufs/file.c | 52 ++++++++++++++++++----------= ---- 1 file changed, 29 insertions(+), 23 deletions(-) diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platfo= rms/cell/spufs/file.c index de7494748fec..c8c3b6e8affb 100644 --- a/arch/powerpc/platforms/cell/spufs/file.c +++ b/arch/powerpc/platforms/cell/spufs/file.c @@ -602,13 +602,17 @@ static ssize_t spufs_mbox_read(struct file *file, cha= r __user *buf, if (len < 4) return -EINVAL; =20 - count =3D spu_acquire(ctx); - if (count) - return count; - for (count =3D 0; (count + 4) <=3D len; count +=3D 4, udata++) { int ret; + + ret =3D spu_acquire(ctx); + if (ret) { + if (!count) + count =3D ret; + break; + } ret =3D ctx->ops->mbox_read(ctx, &mbox_data); + spu_release(ctx); if (ret =3D=3D 0) break; =20 @@ -624,7 +628,6 @@ static ssize_t spufs_mbox_read(struct file *file, char = __user *buf, break; } } - spu_release(ctx); =20 if (!count) count =3D -EAGAIN; @@ -705,29 +708,34 @@ static ssize_t spufs_ibox_read(struct file *file, cha= r __user *buf, =20 count =3D spu_acquire(ctx); if (count) - goto out; + return count; =20 /* wait only for the first element */ - count =3D 0; if (file->f_flags & O_NONBLOCK) { if (!spu_ibox_read(ctx, &ibox_data)) { - count =3D -EAGAIN; - goto out_unlock; + spu_release(ctx); + return -EAGAIN; } } else { count =3D spufs_wait(ctx->ibox_wq, spu_ibox_read(ctx, &ibox_data)); if (count) - goto out; + return count; } + spu_release(ctx); =20 /* if we can't write at all, return -EFAULT */ count =3D put_user(ibox_data, udata); if (count) - goto out_unlock; + return count; =20 for (count =3D 4, udata++; (count + 4) <=3D len; count +=3D 4, udata++) { int ret; + + ret =3D spu_acquire(ctx); + if (ret) + break; ret =3D ctx->ops->ibox_read(ctx, &ibox_data); + spu_release(ctx); if (ret =3D=3D 0) break; /* @@ -740,9 +748,6 @@ static ssize_t spufs_ibox_read(struct file *file, char = __user *buf, break; } =20 -out_unlock: - spu_release(ctx); -out: return count; } =20 @@ -839,40 +844,41 @@ static ssize_t spufs_wbox_write(struct file *file, co= nst char __user *buf, =20 count =3D spu_acquire(ctx); if (count) - goto out; + return count; =20 /* * make sure we can at least write one element, by waiting * in case of !O_NONBLOCK */ - count =3D 0; if (file->f_flags & O_NONBLOCK) { if (!spu_wbox_write(ctx, wbox_data)) { - count =3D -EAGAIN; - goto out_unlock; + spu_release(ctx); + return -EAGAIN; } } else { count =3D spufs_wait(ctx->wbox_wq, spu_wbox_write(ctx, wbox_data)); if (count) - goto out; + return count; } - + spu_release(ctx); =20 /* write as much as possible */ for (count =3D 4, udata++; (count + 4) <=3D len; count +=3D 4, udata++) { int ret; + ret =3D get_user(wbox_data, udata); if (ret) break; =20 + ret =3D spu_acquire(ctx); + if (ret) + break; ret =3D spu_wbox_write(ctx, wbox_data); + spu_release(ctx); if (ret =3D=3D 0) break; } =20 -out_unlock: - spu_release(ctx); -out: return count; } =20 --=20 2.51.2