All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: "Maciej W. Rozycki" <macro@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	James Hogan <james.hogan@mips.com>,
	Paul Burton <Paul.Burton@mips.com>,
	Alex Smith <alex@alex-smith.me.uk>,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH 4/5] MIPS: Execute any partial write of the last register with PTRACE_SETREGSET
Date: Thu, 30 Nov 2017 17:28:40 +0000	[thread overview]
Message-ID: <20171130172839.GQ22781@e103592.cambridge.arm.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1711291226320.31156@tp.orcam.me.uk>

On Wed, Nov 29, 2017 at 03:21:14PM +0000, Maciej W. Rozycki wrote:
> Fix a commit d614fd58a283 ("mips/ptrace: Preserve previous registers for 
> short regset write") bug and allow the last register requested with a 
> ptrace(2) PTRACE_SETREGSET call to be partially written if supplied this 
> way by the caller, like with other register sets.
> 
> Cc: stable@vger.kernel.org # v4.11+
> Fixes: d614fd58a283 ("mips/ptrace: Preserve previous registers for short regset write")
> Signed-off-by: Maciej W. Rozycki <macro@mips.com>
> ---
>  arch/mips/kernel/ptrace.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> linux-mips-nt-prfpreg-count.diff
> Index: linux-sfr-test/arch/mips/kernel/ptrace.c
> ===================================================================
> --- linux-sfr-test.orig/arch/mips/kernel/ptrace.c	2017-11-21 22:12:00.000000000 +0000
> +++ linux-sfr-test/arch/mips/kernel/ptrace.c	2017-11-21 22:13:13.471970000 +0000
> @@ -484,7 +484,7 @@ static int fpr_set_msa(struct task_struc
>  	int err;
>  
>  	BUILD_BUG_ON(sizeof(fpr_val) != sizeof(elf_fpreg_t));
> -	for (i = 0; i < NUM_FPU_REGS && *count >= sizeof(elf_fpreg_t); i++) {
> +	for (i = 0; i < NUM_FPU_REGS && *count > 0; i++) {
> 
>  		err = user_regset_copyin(pos, count, kbuf, ubuf,
>  					 &fpr_val, i * sizeof(elf_fpreg_t),
>  					 (i + 1) * sizeof(elf_fpreg_t));

But mips*_regsets[REGSET_FPR].size == sizeof(elf_fpreg_t),
linux/kernel/regset.c:ptrace_regset() polices
iov_len % regset->size == 0, and each user_regset_copyout() call here
transfers sizeof(elf_fpreg_t) bytes, decrementing *count by that
amount unless something goest wrong in which case we return.

So how do we end up with *count > 0 && *count < sizeof(elf_fpreg_t)
here?

If we can't end up with that, then this patch doesn't change ABI-
observable behaviour, unless I've missed something.

If we can end up with that somehow, then this patch reintroduces the
issue d614fd58a283 aims to fix, whereby fpr_val can contain
uninitialised kernel stack which userspace can then obtain via
PTRACE_GETREGSET.

Cheers
---Dave

  reply	other threads:[~2017-11-30 17:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-29 15:17 [PATCH 0/5] MIPS: NT_PRFPREG regset handling fixes Maciej W. Rozycki
2017-11-29 15:17 ` Maciej W. Rozycki
2017-11-29 15:17 ` [PATCH 1/5] MIPS: Factor out NT_PRFPREG regset access helpers Maciej W. Rozycki
2017-11-29 15:17   ` Maciej W. Rozycki
2017-11-29 15:19 ` [PATCH 2/5] MIPS: Fix an FCSR access API regression with NT_PRFPREG and MSA Maciej W. Rozycki
2017-11-29 15:19   ` Maciej W. Rozycki
2017-11-29 15:20 ` [PATCH 3/5] MIPS: Also verify sizeof `elf_fpreg_t' with PTRACE_SETREGSET Maciej W. Rozycki
2017-11-29 15:20   ` Maciej W. Rozycki
2017-11-29 15:21 ` [PATCH 4/5] MIPS: Execute any partial write of the last register " Maciej W. Rozycki
2017-11-29 15:21   ` Maciej W. Rozycki
2017-11-30 17:28   ` Dave Martin [this message]
2017-11-30 19:38     ` Maciej W. Rozycki
2017-12-01 12:23       ` Dave Martin
2017-12-06 19:24         ` Maciej W. Rozycki
2017-12-11 17:25           ` Maciej W. Rozycki
2017-12-01 12:35       ` Dave Martin
2017-12-06 18:32         ` Maciej W. Rozycki
2017-11-29 15:22 ` [PATCH 5/5] MIPS: Disallow outsized PTRACE_SETREGSET NT_PRFPREG regset accesses Maciej W. Rozycki
2017-11-29 15:22   ` Maciej W. Rozycki

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=20171130172839.GQ22781@e103592.cambridge.arm.com \
    --to=dave.martin@arm.com \
    --cc=Paul.Burton@mips.com \
    --cc=alex@alex-smith.me.uk \
    --cc=james.hogan@mips.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@mips.com \
    --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 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.