From: Denys Vlasenko <vda.linux@googlemail.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>, Tejun Heo <tj@kernel.org>,
Pedro Alves <palves@redhat.com>,
Jan Kratochvil <jan.kratochvil@redhat.com>,
linux-kernel@vger.kernel.org
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Subject: [PATCH 1/5] ptrace: don't modify flags on PTRACE_SETOPTIONS failure
Date: Fri, 10 Feb 2012 15:43:07 +0100 [thread overview]
Message-ID: <1328884991-23889-2-git-send-email-vda.linux@googlemail.com> (raw)
In-Reply-To: <1328884991-23889-1-git-send-email-vda.linux@googlemail.com>
On ptrace(PTRACE_SETOPTIONS, pid, 0, <opts>), we used to set
those option bits which are known, and then fail with -EINVAL
if there are some unknown bits in <opts>.
This in inconsistent with typical error handling, which
does not change any state if input is invalid.
This patch changes PTRACE_SETOPTIONS behavior so that
in this case, we return -EINVAL and don't change any bits
in task->ptrace.
It's very unlikely that there is userspace code in the wild which
will be affected by this change: it should have the form
ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_BOGUSOPT)
where PTRACE_O_BOGUSOPT is a constant unknown to the kernel.
But kernel headers, naturally, don't contain any
PTRACE_O_BOGUSOPTs, thus the only way userspace can use one
if it defines one itself. I can't see why anyone would do such
a thing deliberately.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Acked-by: Tejun Heo <tj@kernel.org>
---
kernel/ptrace.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 00ab2ca..273f56e 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -528,6 +528,9 @@ int ptrace_writedata(struct task_struct *tsk, char __user *src, unsigned long ds
static int ptrace_setoptions(struct task_struct *child, unsigned long data)
{
+ if (data & ~(unsigned long)PTRACE_O_MASK)
+ return -EINVAL;
+
child->ptrace &= ~PT_TRACE_MASK;
if (data & PTRACE_O_TRACESYSGOOD)
@@ -551,7 +554,7 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
if (data & PTRACE_O_TRACEEXIT)
child->ptrace |= PT_TRACE_EXIT;
- return (data & ~PTRACE_O_MASK) ? -EINVAL : 0;
+ return 0;
}
static int ptrace_getsiginfo(struct task_struct *child, siginfo_t *info)
--
1.7.7.6
next prev parent reply other threads:[~2012-02-10 14:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-10 14:43 [PATCH 0/5] ptrace tweaks Denys Vlasenko
2012-02-10 14:43 ` Denys Vlasenko [this message]
2012-02-10 14:43 ` [PATCH 2/5] ptrace: simplify PTRACE_foo constants and PTRACE_SETOPTIONS code Denys Vlasenko
2012-02-10 14:43 ` [PATCH 3/5] ptrace: make PTRACE_SEIZE set ptrace options specified in 'data' parameter Denys Vlasenko
2012-02-10 14:43 ` [PATCH 4/5] ptrace: renumber PTRACE_EVENT_STOP so that future new options and events can match Denys Vlasenko
2012-02-10 14:43 ` [PATCH 5/5] ptrace: remove PTRACE_SEIZE_DEVEL bit Denys Vlasenko
2012-02-10 17:24 ` Oleg Nesterov
2012-02-10 17:46 ` Pedro Alves
2012-02-10 17:42 ` Oleg Nesterov
2012-02-10 17:49 ` Pedro Alves
2012-02-10 19:21 ` Tejun Heo
2012-02-10 17:19 ` [PATCH 4/5] ptrace: renumber PTRACE_EVENT_STOP so that future new options and events can match Oleg Nesterov
2012-02-10 15:57 ` [PATCH 3/5] ptrace: make PTRACE_SEIZE set ptrace options specified in 'data' parameter Oleg Nesterov
2012-02-10 16:34 ` Denys Vlasenko
2012-02-10 16:36 ` [PATCH v2 " Denys Vlasenko
2012-02-10 17:20 ` Oleg Nesterov
2012-02-10 17:17 ` [PATCH 2/5] ptrace: simplify PTRACE_foo constants and PTRACE_SETOPTIONS code Oleg Nesterov
2012-02-10 17:17 ` [PATCH 1/5] ptrace: don't modify flags on PTRACE_SETOPTIONS failure Oleg Nesterov
2012-02-10 17:32 ` [PATCH 0/2] more tweaks (Was: ptrace tweaks) Oleg Nesterov
2012-02-10 17:32 ` [PATCH 1/2] ptrace: the killed tracee should not enter the syscall Oleg Nesterov
2012-02-10 17:33 ` [PATCH 2/2] ptrace: don't send SIGTRAP on exec if SEIZED Oleg Nesterov
2012-02-10 17:48 ` [PATCH 0/2] more tweaks (Was: ptrace tweaks) Pedro Alves
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=1328884991-23889-2-git-send-email-vda.linux@googlemail.com \
--to=vda.linux@googlemail.com \
--cc=akpm@linux-foundation.org \
--cc=jan.kratochvil@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=palves@redhat.com \
--cc=tj@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.