From nobody Thu Apr 9 16:20:43 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.2]) (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 1EE07364EA5; Tue, 3 Mar 2026 01:51:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772502689; cv=none; b=PnbOXGj/ISLk9ooxzgiRnVXXRkPsndlp78frH8Si9+E6b2/3qQcdt00mPtcBnMqAJN9qGYS9PtdeYepMbCAaGQbbMfDCZIgSVlXh55NtyuScpYRd9aiGOQoaLWEoJcWcAvCjL2HV5XstX1s8IcmRP9MgKXUf7kl6oNGUNmPH3Pw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772502689; c=relaxed/simple; bh=SrM78CwYmsi7NLly+zHTpsqAUqXmMmeX6ryp1zEhTfs=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=piNN1MLID+4fcETca/qZ41jZX6Tl1Oae5IldEmG9hKB8Qv72pzuJFgp+du1XCgYskjrEgqSV2GgPhsaKeKH6yulphi9UlQPXwecKp6cRMonkTkkq8NWHoZ14cwvG+ZM9Bx3A9Hoc6IIdZ8lPET9GOgrAVZmSJE5cdQdgPJZK0FA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=SETiF0PA; arc=none smtp.client-ip=220.197.31.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="SETiF0PA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=XG FqIj6YZfW1vO9tfInL0Hqq+SBbiSTcDvtPlDVfVTs=; b=SETiF0PA/7QxTWYq+f oNxEix/ogwG70x+0DjA2gJJUyw+R1UV2kYeG8wuoTeesDv37nMmDK1+av9nosAEA DvNmLOzXfRULeisJCMScXD2zAP8LER0gxFCLb8Xk7JRwOb8PVgssdrsk74QQoJfv foBsqVPE1cqAvON/x8oK2GkoY= Received: from pek-lpg-core6.wrs.com (unknown []) by gzga-smtp-mtada-g1-3 (Coremail) with SMTP id _____wCnhCODPqZp1ezIOw--.34317S3; Tue, 03 Mar 2026 09:51:00 +0800 (CST) From: Rahul Sharma To: gregkh@linuxfoundation.org, stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Mark Rutland , Catalin Marinas , Marc Zyngier , Mark Brown , Will Deacon , Rahul Sharma Subject: [PATCH 6.12.y 1/2] arm64/fpsimd: signal: Mandate SVE payload for streaming-mode state Date: Tue, 3 Mar 2026 09:50:46 +0800 Message-Id: <20260303015047.2014999-2-black.hawk@163.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260303015047.2014999-1-black.hawk@163.com> References: <20260303015047.2014999-1-black.hawk@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: _____wCnhCODPqZp1ezIOw--.34317S3 X-Coremail-Antispam: 1Uf129KBjvJXoWxCry8AF4DtFyxJF18Wr4Uurg_yoW5ZFWrpr W7Kw1Yyr1UGF1fAa90vF4F9a95W34ft3W5WF93Ga48ZrW5JrZ8urnYyayqqryUGr93GryY qFyjqr40gayDt37anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0pR-AwxUUUUU= X-CM-SenderInfo: 5eoduy4okd4yi6rwjhhfrp/xtbC+QW0TmmmPoU7cgAA37 Content-Type: text/plain; charset="utf-8" From: Mark Rutland [ Upstream commit b465ace42620970e840c7aeb2c44a6e3b1002fec ] Non-streaming SVE state may be preserved without an SVE payload, in which case the SVE context only has a header with VL=3D=3D0, and all state can be restored from the FPSIMD context. Streaming SVE state is always preserved with an SVE payload, where the SVE context header has VL!=3D0, and the SVE_SIG_FLAG_SM flag is set. The kernel never preserves an SVE context where SVE_SIG_FLAG_SM is set without an SVE payload. However, restore_sve_fpsimd_context() doesn't forbid restoring such a context, and will handle this case by clearing PSTATE.SM and restoring the FPSIMD context into non-streaming mode, which isn't consistent with the SVE_SIG_FLAG_SM flag. Forbid this case, and mandate an SVE payload when the SVE_SIG_FLAG_SM flag is set. This avoids an awkward ABI quirk and reduces the risk that later rework to this code permits configuring a task with PSTATE.SM=3D=3D1 and fp_type=3D=3DFP_STATE_FPSIMD. I've marked this as a fix given that we never intended to support this case, and we don't want anyone to start relying upon the old behaviour once we re-enable SME. Fixes: 85ed24dad290 ("arm64/sme: Implement streaming SVE signal handling") Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Marc Zyngier Cc: Mark Brown Cc: Will Deacon Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20250508132644.1395904-4-mark.rutland@arm.c= om Signed-off-by: Will Deacon Signed-off-by: Rahul Sharma --- arch/arm64/kernel/signal.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c index f7b05267a76b..2ff6af928426 100644 --- a/arch/arm64/kernel/signal.c +++ b/arch/arm64/kernel/signal.c @@ -391,6 +391,7 @@ static int restore_sve_fpsimd_context(struct user_ctxs = *user) unsigned int vl, vq; struct user_fpsimd_state fpsimd; u16 user_vl, flags; + bool sm; =20 if (user->sve_size < sizeof(*user->sve)) return -EINVAL; @@ -400,7 +401,8 @@ static int restore_sve_fpsimd_context(struct user_ctxs = *user) if (err) return err; =20 - if (flags & SVE_SIG_FLAG_SM) { + sm =3D flags & SVE_SIG_FLAG_SM; + if (sm) { if (!system_supports_sme()) return -EINVAL; =20 @@ -420,7 +422,16 @@ static int restore_sve_fpsimd_context(struct user_ctxs= *user) if (user_vl !=3D vl) return -EINVAL; =20 - if (user->sve_size =3D=3D sizeof(*user->sve)) { + /* + * Non-streaming SVE state may be preserved without an SVE payload, in + * which case the SVE context only has a header with VL=3D=3D0, and all + * state can be restored from the FPSIMD context. + * + * Streaming SVE state is always preserved with an SVE payload. For + * consistency and robustness, reject restoring streaming SVE state + * without an SVE payload. + */ + if (!sm && user->sve_size =3D=3D sizeof(*user->sve)) { clear_thread_flag(TIF_SVE); current->thread.svcr &=3D ~SVCR_SM_MASK; current->thread.fp_type =3D FP_STATE_FPSIMD; --=20 2.34.1 From nobody Thu Apr 9 16:20:43 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.4]) (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 18681373C07; Tue, 3 Mar 2026 01:51:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.4 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772502690; cv=none; b=JCCl4DW2W/tr+CVbO84Zj9s6ZQOOKHzPCzJjHb1KBF7/HsECiopLsVtzTOhlWWc2fVFNVD4jMWF7rUE10U0/oW6Kvo12m4JsevKeYAd7wgH6FB30bCN4kNjI429/ncins7QA7x8JYUARRgrL/6vpK2D4a6nZ33j7FXYOvc0NOVU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772502690; c=relaxed/simple; bh=ADUESCLJaX4eiR/SFBXL5hM188k4g7qBP6XOzvTrKvc=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=uR5RYb89ivxW+C5sGNSIYVmd44pAcX1Ztcu3pE5AQoGoFk7I8pJPgAOm844K8FFXQtzOmhvd/EikhnLR8Bro6rZTzPEjiRtlS14yjQUnh9j692XmdRHmWKk7SN6+vysooYWCUetARkH5U4Qnuw39KR2Lz9eBngYifKTcXh/E+LA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=aiJy2aeR; arc=none smtp.client-ip=220.197.31.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="aiJy2aeR" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=LN TFCOu8QjlEE/BFJC2VrkXT/oeVq90OquaCypbjHZ0=; b=aiJy2aeRR2oIUj2hZB sWUZchjLaQr9X5GvVk2KURuBH8hA74eOdDIU6/JBjILxZC0Lkr8OHvn0pg2rU56d 0Ic/dQWFd6Zf5/QAIWOhN02EVW7jazBu88ngtesl7M2cLVWBiKe4yLU9HJXTm1IY SadCSgvX81izjLtoBSxNJw1fI= Received: from pek-lpg-core6.wrs.com (unknown []) by gzga-smtp-mtada-g1-3 (Coremail) with SMTP id _____wCnhCODPqZp1ezIOw--.34317S4; Tue, 03 Mar 2026 09:51:02 +0800 (CST) From: Rahul Sharma To: gregkh@linuxfoundation.org, stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Mark Rutland , Mark Brown , Will Deacon , Catalin Marinas , Rahul Sharma Subject: [PATCH 6.12.y 2/2] arm64/fpsimd: signal: Fix restoration of SVE context Date: Tue, 3 Mar 2026 09:50:47 +0800 Message-Id: <20260303015047.2014999-3-black.hawk@163.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260303015047.2014999-1-black.hawk@163.com> References: <20260303015047.2014999-1-black.hawk@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: _____wCnhCODPqZp1ezIOw--.34317S4 X-Coremail-Antispam: 1Uf129KBjvJXoW3JFyUtw1rKrW8tw4fGFWfZrb_yoW7tr43pr WfGry3Kr4DJF1Iyr1Sqw4q9F95G3s5Jr45Gr9xK34rCFy5Cr9Ygr47tFyjqF43CrZ5WF4j qrWjqFykWa1DKaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zMT5lUUUUUU= X-CM-SenderInfo: 5eoduy4okd4yi6rwjhhfrp/xtbC3ga0TmmmPoYChwAA3Q Content-Type: text/plain; charset="utf-8" From: Mark Rutland [ Upstream commit d2907cbe9ea0a54cbe078076f9d089240ee1e2d9 ] When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL. (1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL. This can only occur in unusual (but legitimate) cases where the SVE signal context has either been modified by userspace or was saved in the context of another task (e.g. as with CRIU), as otherwise the presence of an SVE signal context with SVE_SIG_FLAG_SM implies that TIF_SME is already set. While in this state, task_fpsimd_load() will NOT configure SMCR_ELx (leaving some arbitrary value configured in hardware) before restoring SVCR and attempting to restore the streaming mode SVE registers from memory via sve_load_state(). As the value of SMCR_ELx.LEN may be larger than the task's streaming SVE vector length, this may read memory outside of the task's allocated sve_state, reading unrelated data and/or triggering a fault. While this can result in secrets being loaded into streaming SVE registers, these values are never exposed. As TIF_SME is clear, fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0 accesses to streaming mode SVE registers, so these cannot be accessed directly at EL0. As fpsimd_save_user_state() verifies the live vector length before saving (S)SVE state to memory, no secret values can be saved back to memory (and hence cannot be observed via ptrace, signals, etc). When the live vector length doesn't match the expected vector length for the task, fpsimd_save_user_state() will send a fatal SIGKILL signal to the task. Hence the task may be killed after executing userspace for some period of time. (2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV. This can only occur in unusual (but legitimate) cases where ptrace has been used to set SVCR.SM after entry to the sigreturn syscall, as syscall entry clears SVCR.SM. In these cases, the the provided SVE register data will be loaded into the task's sve_state using the non-streaming SVE vector length and the FPSIMD registers will be merged into this using the streaming SVE vector length. Fix (1) by setting TIF_SME when setting SVCR.SM. This also requires ensuring that the task's sme_state has been allocated, but as this could contain live ZA state, it should not be zeroed. Fix (2) by clearing SVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear. For consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME, and fp_type earlier, immediately after the allocation of sve_state/sme_state, before the restore of the actual register state. This makes it easier to ensure that these are always modified consistently, even if a fault is taken while reading the register data from the signal context. I do not expect any software to depend on the exact state restored when a fault is taken while reading the context. Fixes: 85ed24dad290 ("arm64/sme: Implement streaming SVE signal handling") Signed-off-by: Mark Rutland Cc: Cc: Mark Brown Cc: Will Deacon Reviewed-by: Mark Brown Signed-off-by: Catalin Marinas [ The context change is due to the commit 929fa99b1215 ("arm64/fpsimd: signal: Always save+flush state early") and the commit be625d803c3b ("arm64/fpsimd: signal: Consistently read FPSIMD context") in v6.16 which are irrelevant to the logic of this patch. ] Signed-off-by: Rahul Sharma --- arch/arm64/kernel/signal.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c index 2ff6af928426..65f4e5841ea8 100644 --- a/arch/arm64/kernel/signal.c +++ b/arch/arm64/kernel/signal.c @@ -452,6 +452,11 @@ static int restore_sve_fpsimd_context(struct user_ctxs= *user) =20 fpsimd_flush_task_state(current); /* From now, fpsimd_thread_switch() won't touch thread.sve_state */ + if (sm) { + sme_alloc(current, false); + if (!current->thread.sme_state) + return -ENOMEM; + } =20 sve_alloc(current, true); if (!current->thread.sve_state) { @@ -459,6 +464,16 @@ static int restore_sve_fpsimd_context(struct user_ctxs= *user) return -ENOMEM; } =20 + if (sm) { + current->thread.svcr |=3D SVCR_SM_MASK; + set_thread_flag(TIF_SME); + } else { + current->thread.svcr &=3D ~SVCR_SM_MASK; + set_thread_flag(TIF_SVE); + } + + current->thread.fp_type =3D FP_STATE_SVE; + err =3D __copy_from_user(current->thread.sve_state, (char __user const *)user->sve + SVE_SIG_REGS_OFFSET, @@ -466,12 +481,6 @@ static int restore_sve_fpsimd_context(struct user_ctxs= *user) if (err) return -EFAULT; =20 - if (flags & SVE_SIG_FLAG_SM) - current->thread.svcr |=3D SVCR_SM_MASK; - else - set_thread_flag(TIF_SVE); - current->thread.fp_type =3D FP_STATE_SVE; - fpsimd_only: /* copy the FP and status/control registers */ /* restore_sigframe() already checked that user->fpsimd !=3D NULL. */ --=20 2.34.1