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 <[email protected]>
---
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 <[email protected]>
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 <[email protected]>
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: <[email protected]> # 5.6.x
With that:
Reviewed-by: Catalin Marinas <[email protected]>
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