From: <gregkh@linuxfoundation.org>
To: ebiederm@xmission.com, alexander.levin@microsoft.com,
gregkh@linuxfoundation.org, rmk@flint.arm.linux.org.uk
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "signal/arm: Document conflicts with SI_USER and SIGFPE" has been added to the 4.4-stable tree
Date: Tue, 10 Apr 2018 11:06:23 +0200 [thread overview]
Message-ID: <152335118380102@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
signal/arm: Document conflicts with SI_USER and SIGFPE
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
signal-arm-document-conflicts-with-si_user-and-sigfpe.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 10:31:53 CEST 2018
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Thu, 17 Aug 2017 17:07:46 -0500
Subject: signal/arm: Document conflicts with SI_USER and SIGFPE
From: "Eric W. Biederman" <ebiederm@xmission.com>
[ Upstream commit 7771c66457004977b616bab785209f49d164f527 ]
Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER. Posix and common sense requires
that SI_USER not be a signal specific si_code. As such this use of 0
for the si_code is a pretty horribly broken ABI.
Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design. Making this a very
flakey implementation.
Utilizing FPE_FIXME, siginfo_layout will now return SIL_FAULT and the
appropriate fields will be reliably copied.
Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Russell King <rmk@flint.arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Ref: 451436b7bbb2 ("[ARM] Add support code for ARM hardware vector floating point")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/include/uapi/asm/siginfo.h | 13 +++++++++++++
arch/arm/vfp/vfpmodule.c | 2 +-
2 files changed, 14 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/uapi/asm/siginfo.h
--- /dev/null
+++ b/arch/arm/include/uapi/asm/siginfo.h
@@ -0,0 +1,13 @@
+#ifndef __ASM_SIGINFO_H
+#define __ASM_SIGINFO_H
+
+#include <asm-generic/siginfo.h>
+
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+#endif
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -261,7 +261,7 @@ static void vfp_raise_exceptions(u32 exc
if (exceptions == VFP_EXCEPTION_ERROR) {
vfp_panic("unhandled bounce", inst);
- vfp_raise_sigfpe(0, regs);
+ vfp_raise_sigfpe(FPE_FIXME, regs);
return;
}
Patches currently in stable-queue which might be from ebiederm@xmission.com are
queue-4.4/signal-metag-document-a-conflict-with-si_user-with-sigfpe.patch
queue-4.4/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch
queue-4.4/signal-arm-document-conflicts-with-si_user-and-sigfpe.patch
queue-4.4/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch
next reply other threads:[~2018-04-10 9:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-10 9:06 gregkh [this message]
2018-04-10 18:41 ` Patch "signal/arm: Document conflicts with SI_USER and SIGFPE" has been added to the 4.4-stable tree Amit Pundir
2018-04-10 21:15 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=152335118380102@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alexander.levin@microsoft.com \
--cc=ebiederm@xmission.com \
--cc=rmk@flint.arm.linux.org.uk \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.