From: "Maciej W. Rozycki" <macro@mips.com>
To: James Hogan <james.hogan@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, <linux-mips@linux-mips.org>,
<linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
Subject: [PATCH] MIPS: Fix ptrace(2) PTRACE_PEEKUSR and PTRACE_POKEUSR accesses to o32 FGRs
Date: Mon, 14 May 2018 16:49:43 +0100 [thread overview]
Message-ID: <alpine.DEB.2.00.1805141537210.10896@tp.orcam.me.uk> (raw)
Check the TIF_32BIT_FPREGS task setting of the tracee rather than the
tracer in determining the layout of floating-point general registers in
the floating-point context, correcting access to odd-numbered registers
for o32 tracees where the setting disagrees between the two processes.
Cc: stable@vger.kernel.org # 3.14+
Fixes: 597ce1723e0f ("MIPS: Support for 64-bit FP with O32 binaries")
Signed-off-by: Maciej W. Rozycki <macro@mips.com>
---
Hi,
These are not the usual requests used by GDB to access the floating-point
context, which is likely why it went unnoticed so long. They are only
used as a fallback in the case where PTRACE_GETFPREGS and PTRACE_SETFPREGS
requests are not supported, i.e. with ancient kernels.
However to verify an unrelated GDB bug fix I have tweaked GDB to always
use PTRACE_PEEKUSR and PTRACE_POKEUSR, and then discovered this issue in
native GDB regression testing, as it showed regressions from corrupt FGR
contents across numerous tests compared to the usual results. This fix
removed those regressions then.
Not being typically used does not mean we ought to keep the interface
broken. Therefore please apply.
Maciej
---
arch/mips/kernel/ptrace.c | 4 ++--
arch/mips/kernel/ptrace32.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
linux-mips-ptrace-test-thread-flag.diff
Index: linux/arch/mips/kernel/ptrace.c
===================================================================
--- linux.orig/arch/mips/kernel/ptrace.c 2018-05-12 22:52:19.000000000 +0100
+++ linux/arch/mips/kernel/ptrace.c 2018-05-12 22:56:07.893993000 +0100
@@ -1059,7 +1059,7 @@ long arch_ptrace(struct task_struct *chi
fregs = get_fpu_regs(child);
#ifdef CONFIG_32BIT
- if (test_thread_flag(TIF_32BIT_FPREGS)) {
+ if (test_tsk_thread_flag(child, TIF_32BIT_FPREGS)) {
/*
* The odd registers are actually the high
* order bits of the values stored in the even
@@ -1154,7 +1154,7 @@ long arch_ptrace(struct task_struct *chi
init_fp_ctx(child);
#ifdef CONFIG_32BIT
- if (test_thread_flag(TIF_32BIT_FPREGS)) {
+ if (test_tsk_thread_flag(child, TIF_32BIT_FPREGS)) {
/*
* The odd registers are actually the high
* order bits of the values stored in the even
Index: linux-mipsswbrd038/arch/mips/kernel/ptrace32.c
===================================================================
--- linux-mipsswbrd038.orig/arch/mips/kernel/ptrace32.c 2018-05-12 22:52:19.000000000 +0100
+++ linux-mipsswbrd038/arch/mips/kernel/ptrace32.c 2018-05-12 22:55:20.906637000 +0100
@@ -99,7 +99,7 @@ long compat_arch_ptrace(struct task_stru
break;
}
fregs = get_fpu_regs(child);
- if (test_thread_flag(TIF_32BIT_FPREGS)) {
+ if (test_tsk_thread_flag(child, TIF_32BIT_FPREGS)) {
/*
* The odd registers are actually the high
* order bits of the values stored in the even
@@ -212,7 +212,7 @@ long compat_arch_ptrace(struct task_stru
sizeof(child->thread.fpu));
child->thread.fpu.fcr31 = 0;
}
- if (test_thread_flag(TIF_32BIT_FPREGS)) {
+ if (test_tsk_thread_flag(child, TIF_32BIT_FPREGS)) {
/*
* The odd registers are actually the high
* order bits of the values stored in the even
next reply other threads:[~2018-05-14 15:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-14 15:49 Maciej W. Rozycki [this message]
2018-05-14 22:37 ` [PATCH] MIPS: Fix ptrace(2) PTRACE_PEEKUSR and PTRACE_POKEUSR accesses to o32 FGRs James Hogan
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=alpine.DEB.2.00.1805141537210.10896@tp.orcam.me.uk \
--to=macro@mips.com \
--cc=james.hogan@mips.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).