Commit 6d502b6ba1b2 ("arm64: signal: nofpsimd: Handle fp/simd context for
signal frames") introduced saving the fp/simd context for signal handling
only when support is available. But setup_sigframe_layout() always
reserves memory for fp/simd context. The additional memory is not touched
because preserve_fpsimd_context() is not called and thus the magic is
invalid.

This may lead to an error when parse_user_sigframe() checks the fp/simd
area and does not find a valid magic number.

Signed-off-by: David Engraf <david.engraf@sysgo.com>
---
 arch/arm64/kernel/signal.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index d8aaf4b6f432..3d66fba69016 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -577,10 +577,12 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
 {
 	int err;
 
-	err = sigframe_alloc(user, &user->fpsimd_offset,
-			     sizeof(struct fpsimd_context));
-	if (err)
-		return err;
+	if (system_supports_fpsimd()) {
+		err = sigframe_alloc(user, &user->fpsimd_offset,
+				     sizeof(struct fpsimd_context));
+		if (err)
+			return err;
+	}
 
 	/* fault information, if valid */
 	if (add_all || current->thread.fault_code) {
-- 
2.25.1

On Fri, Feb 25, 2022 at 11:40:08AM +0100, David Engraf wrote:
> Commit 6d502b6ba1b2 ("arm64: signal: nofpsimd: Handle fp/simd context for
> signal frames") introduced saving the fp/simd context for signal handling
> only when support is available. But setup_sigframe_layout() always
> reserves memory for fp/simd context. The additional memory is not touched
> because preserve_fpsimd_context() is not called and thus the magic is
> invalid.
> 
> This may lead to an error when parse_user_sigframe() checks the fp/simd
> area and does not find a valid magic number.

How did you spot this - do you have a system that can reproduce this?
It'd be good to have coverage if there's testing but there's no easily
obtainable userspace that I'm aware of.

On 25.02.22 18:57, Mark Brown wrote:
> On Fri, Feb 25, 2022 at 11:40:08AM +0100, David Engraf wrote:
>> Commit 6d502b6ba1b2 ("arm64: signal: nofpsimd: Handle fp/simd context for
>> signal frames") introduced saving the fp/simd context for signal handling
>> only when support is available. But setup_sigframe_layout() always
>> reserves memory for fp/simd context. The additional memory is not touched
>> because preserve_fpsimd_context() is not called and thus the magic is
>> invalid.
>>
>> This may lead to an error when parse_user_sigframe() checks the fp/simd
>> area and does not find a valid magic number.
> 
> How did you spot this - do you have a system that can reproduce this?
> It'd be good to have coverage if there's testing but there's no easily
> obtainable userspace that I'm aware of.

I'm using a hypervisor which reports no fp/simd support. The user space 
was a busybox with init and shell. The shell gets a SIGSEGV because 
parse_user_sigframe() returns -EINVAL (bad magic).

user->sigframe in get_sigframe() uses the user stack pointer and the 
area was not zeroed. Thus the magic at fpsimd_offset is invalid.

Best regards
- David

On Fri, Feb 25, 2022 at 11:40:08AM +0100, David Engraf wrote:
> Commit 6d502b6ba1b2 ("arm64: signal: nofpsimd: Handle fp/simd context for
> signal frames") introduced saving the fp/simd context for signal handling
> only when support is available. But setup_sigframe_layout() always
> reserves memory for fp/simd context. The additional memory is not touched
> because preserve_fpsimd_context() is not called and thus the magic is
> invalid.

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

On Fri, Feb 25, 2022 at 11:40:08AM +0100, David Engraf wrote:
> Commit 6d502b6ba1b2 ("arm64: signal: nofpsimd: Handle fp/simd context for
> signal frames") introduced saving the fp/simd context for signal handling
> only when support is available. But setup_sigframe_layout() always
> reserves memory for fp/simd context. The additional memory is not touched
> because preserve_fpsimd_context() is not called and thus the magic is
> invalid.
> 
> This may lead to an error when parse_user_sigframe() checks the fp/simd
> area and does not find a valid magic number.
> 
> Signed-off-by: David Engraf <david.engraf@sysgo.com>

Given that it's not a regression, I wouldn't push it at -rc7. But if
Will picks it up for 5.18, I think it's worth adding:

Fixes: 6d502b6ba1b2 ("arm64: signal: nofpsimd: Handle fp/simd context for signal frames")
Cc: <stable@vger.kernel.org> # 5.6.x

With that:

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

On Fri, 25 Feb 2022 11:40:08 +0100, David Engraf wrote:
> Commit 6d502b6ba1b2 ("arm64: signal: nofpsimd: Handle fp/simd context for
> signal frames") introduced saving the fp/simd context for signal handling
> only when support is available. But setup_sigframe_layout() always
> reserves memory for fp/simd context. The additional memory is not touched
> because preserve_fpsimd_context() is not called and thus the magic is
> invalid.
> 
> [...]

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

[1/1] arm64: signal: nofpsimd: Do not allocate fp/simd context when not available
      https://git.kernel.org/arm64/c/0a32c88ddb9a

Cheers,
-- 
Will

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