[PATCH] arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems

[PATCH] arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems

[Mark Rutland]

When system_supports_sme() is true but system_supports_sve() is false,
restoring a specifically crafted SVE signal context can result in the
task erroneously having non-streaming SVE state. Subsequent attempts to
manipulate the task's FPSIMD/SVE/SME state can result in a variety of
problems, including fatal EL1 UNDEFs.

In such configurations, the kernel always creates an SVE signal context
when delivering a signal, and this can only be in one of two states:

(1) SVE_SIG_FLAG_SM is set, and an SVE payload is present containing
    streaming mode SVE state. The recorded VL is the task's live
    streaming VL.

(2) SVE_SIG_FLAG_SM is clear, and an SVE payload is not present. The
    FPSIMD context contains the non-streaming mode FPSIMD state. The
    recorded VL is 0.

Currently restore_sve_fpsimd_context() correctly rejects cases where
SVE_SIG_FLAG_SM is set and an SVE payload is not present, but fails to
reject cases where SVE_SIG_FLAG_SM is clear and an SVE payload is
present. Consequently, restore_sve_fpsimd_context() can place the task
in a state where it has non-streaming SVE state even when this is not
supported by HW.

For example, this can cause a later EL1 UNDEF when the kernel attempts to
restore the task's ZCR_EL1 value:

| # ./sme-sigcontext-to-sve
| Internal error: Oops - Undefined instruction: 0000000002000000 [#1]  SMP
| Modules linked in:
| CPU: 0 UID: 0 PID: 131 Comm: sme-sigcontext- Not tainted 7.3.0-rc1 #1 PREEMPT
| Hardware name: linux,dummy-virt (DT)
| pstate: 61402009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
| pc : fpsimd_restore_current_state+0x258/0x458
| lr : exit_to_user_mode_loop+0xb8/0x188
| sp : ffff80008056be40
| x29: ffff80008056be40 x28: fff00000c1670000 x27: 0000000000000000
| x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
| x23: ffff80008056bec0 x22: 0000000000000008 x21: 0000000000000040
| x20: 0000000000000081 x19: 0000000008800010 x18: 0000000000000000
| x17: 0000fffffd412570 x16: 0000000000001000 x15: 0000fffffd4123b0
| x14: 0000fffffd412780 x13: 0000fffffd412be8 x12: 0000000047435300
| x11: 0000fffffd412570 x10: 0000000000000000 x9 : 0000000045585401
| x8 : fff00000c18a6c44 x7 : 0000000000000000 x6 : 0000000000000002
| x5 : 0000000000000002 x4 : ffff800080568000 x3 : 0000000000000001
| x2 : 0000000008800010 x1 : fff00000c1670000 x0 : 0000000008800000
| Call trace:
|  fpsimd_restore_current_state+0x258/0x458 (P)
|  exit_to_user_mode_loop+0xb8/0x188
|  el0_svc+0x1cc/0x1d0
|  el0t_64_sync_handler+0xa0/0xe4
|  el0t_64_sync+0x198/0x19c
| Code: d5384101 f9400020 53175c03 36b80de0 (d5381202)
| ---[ end trace 0000000000000000 ]---
| Kernel panic - not syncing: Oops - Undefined instruction: Fatal exception in interrupt
| Kernel Offset: 0x291fb1000000 from 0xffff800080000000
| PHYS_OFFSET: 0x40000000
| CPU features: 0x0,00000000,0052802f,ffb88f43,3afcf73f
| Memory Limit: none

Rework restore_sve_fpsimd_context() to reject cases where
SVE_SIG_FLAG_SM is clear and an SVE payload is not present. As
parse_user_sigframe() rejects SVE signal frames when neither SVE nor SME
are supported, it isn't necessary for restore_sve_fpsimd_context() to
handle the case where neither are supported.

Fixes: 7dde62f0687c  ("arm64/signal: Always accept SVE signal frames on SME only systems")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>
Cc: stable@vger.kernel.org
---
 arch/arm64/kernel/signal.c | 34 ++++++++++++++++++++--------------
 1 file changed, 20 insertions(+), 14 deletions(-)

I've given this a spin on a model atop v7.3-rc1, in all combinations of
SVE and/or SME being supported, running the fpsimd and signal kselftests.

Regardless of this patch, the kselftests themselves are broken for
SME-only configurations. The signal tests have been broken for at least
3 years (since the kernel started creating SVE contexts on SME-only
systems), so evidently such configurations are not being tested. I have
some local fixes for the kselftests that I will send out soon.

Mark.

diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 38e6fa204c17b..6a06a4e352b1d 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -433,6 +433,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 fpsimd_only;
 	bool sm;
 
 	if (user->sve_size < sizeof(*user->sve))
@@ -443,19 +444,33 @@ static int restore_sve_fpsimd_context(struct user_ctxs *user)
 	if (err)
 		return err;
 
+	fpsimd_only = (user->sve_size == sizeof(*user->sve));
 	sm = flags & SVE_SIG_FLAG_SM;
+
 	if (sm) {
 		if (!system_supports_sme())
 			return -EINVAL;
 
+		/*
+		 * Streaming SVE state is always preserved with an SVE payload.
+		 * Only accept streaming state which has an SVE payload.
+		 */
+		if (fpsimd_only)
+			return -EINVAL;
+
 		vl = task_get_sme_vl(current);
 	} else {
 		/*
-		 * A SME only system use SVE for streaming mode so can
-		 * have a SVE formatted context with a zero VL and no
-		 * payload data.
+		 * Non-streaming SVE state may be preserved without an SVE
+		 * payload, in which case all state is saved in the FPSIMD
+		 * context.
+		 *
+		 * On SME-only systems, non-streaming (FPSIMD-only) state is
+		 * always preserved without an SVE payload, and with VL==0. On
+		 * such systems, only accept non-streaming state without an SVE
+		 * payload.
 		 */
-		if (!system_supports_sve() && !system_supports_sme())
+		if (!system_supports_sve() && !fpsimd_only)
 			return -EINVAL;
 
 		vl = task_get_sve_vl(current);
@@ -464,16 +479,7 @@ static int restore_sve_fpsimd_context(struct user_ctxs *user)
 	if (user_vl != vl)
 		return -EINVAL;
 
-	/*
-	 * Non-streaming SVE state may be preserved without an SVE payload, in
-	 * which case the SVE context only has a header with VL==0, 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 == sizeof(*user->sve))
+	if (fpsimd_only)
 		return restore_fpsimd_context(user);
 
 	vq = sve_vq_from_vl(vl);
-- 
2.30.2

Re: [PATCH] arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

On Thu, Oct 01, 2026 at 02:08:36PM +0100, Mark Rutland wrote:

> Regardless of this patch, the kselftests themselves are broken for
> SME-only configurations. The signal tests have been broken for at least
> 3 years (since the kernel started creating SVE contexts on SME-only
> systems), so evidently such configurations are not being tested. I have
> some local fixes for the kselftests that I will send out soon.

I do have some coverage set up but it's set up in such a way that it'll
only notice new failures so things that have never worked won't be
visible.

> @@ -443,19 +444,33 @@ static int restore_sve_fpsimd_context(struct user_ctxs *user)

>  	} else {
>  		/*
> -		 * A SME only system use SVE for streaming mode so can
> -		 * have a SVE formatted context with a zero VL and no
> -		 * payload data.
> +		 * Non-streaming SVE state may be preserved without an SVE
> +		 * payload, in which case all state is saved in the FPSIMD
> +		 * context.
> +		 *
> +		 * On SME-only systems, non-streaming (FPSIMD-only) state is
> +		 * always preserved without an SVE payload, and with VL==0. On
> +		 * such systems, only accept non-streaming state without an SVE
> +		 * payload.
>  		 */
> -		if (!system_supports_sve() && !system_supports_sme())
> +		if (!system_supports_sve() && !fpsimd_only)
>  			return -EINVAL;

This means that this function will now accept a FPSIMD only SVE context
on systems with neither SVE nor SME, but that check was redundant since
we already reject anything with SVE magic in parse_user_sigframe() on
such systems and should never get here anyway.

Reviewed-by: Mark Brown <broonie@kernel.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems

[Mark Rutland]

On Thu, Oct 01, 2026 at 03:25:03PM +0100, Mark Brown wrote:
> On Thu, Oct 01, 2026 at 02:08:36PM +0100, Mark Rutland wrote:
> > @@ -443,19 +444,33 @@ static int restore_sve_fpsimd_context(struct user_ctxs *user)
> 
> >  	} else {
> >  		/*
> > -		 * A SME only system use SVE for streaming mode so can
> > -		 * have a SVE formatted context with a zero VL and no
> > -		 * payload data.
> > +		 * Non-streaming SVE state may be preserved without an SVE
> > +		 * payload, in which case all state is saved in the FPSIMD
> > +		 * context.
> > +		 *
> > +		 * On SME-only systems, non-streaming (FPSIMD-only) state is
> > +		 * always preserved without an SVE payload, and with VL==0. On
> > +		 * such systems, only accept non-streaming state without an SVE
> > +		 * payload.
> >  		 */
> > -		if (!system_supports_sve() && !system_supports_sme())
> > +		if (!system_supports_sve() && !fpsimd_only)
> >  			return -EINVAL;
> 
> This means that this function will now accept a FPSIMD only SVE context
> on systems with neither SVE nor SME, but that check was redundant since
> we already reject anything with SVE magic in parse_user_sigframe() on
> such systems and should never get here anyway.

Yes. The commit message explained that:

  As parse_user_sigframe() rejects SVE signal frames when neither SVE
  nor SME are supported, it isn't necessary for
  restore_sve_fpsimd_context() to handle the case where neither are
  supported.

> Reviewed-by: Mark Brown <broonie@kernel.org>

Thanks.

Mark.

Re: [PATCH] arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems

[Will Deacon]

On Thu, 01 Oct 2026 14:08:36 +0100, Mark Rutland wrote:
> When system_supports_sme() is true but system_supports_sve() is false,
> restoring a specifically crafted SVE signal context can result in the
> task erroneously having non-streaming SVE state. Subsequent attempts to
> manipulate the task's FPSIMD/SVE/SME state can result in a variety of
> problems, including fatal EL1 UNDEFs.
> 
> In such configurations, the kernel always creates an SVE signal context
> when delivering a signal, and this can only be in one of two states:
> 
> [...]

Applied to arm64 (for-next/fixes), thanks!

[1/1] arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems
      https://git.kernel.org/arm64/c/e060d9069b49

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev