diff options
author | H.J. Lu <hjl.tools@gmail.com> | 2012-05-21 20:29:45 -0700 |
---|---|---|
committer | H. Peter Anvin <hpa@zytor.com> | 2012-06-01 13:54:21 -0700 |
commit | bad1a753d4d4deb09d4bc0bac1dd4fc3298502e9 (patch) | |
tree | 49923bb64af0c598635b9d481f7e1390bf5a5bbb /arch/x86/kernel/ptrace.c | |
parent | 0c7596621e313bfcfbacb288e768c7150f5de9e0 (diff) | |
download | linux-stable-bad1a753d4d4deb09d4bc0bac1dd4fc3298502e9.tar.gz linux-stable-bad1a753d4d4deb09d4bc0bac1dd4fc3298502e9.tar.bz2 linux-stable-bad1a753d4d4deb09d4bc0bac1dd4fc3298502e9.zip |
x86, x32, ptrace: Remove PTRACE_ARCH_PRCTL for x32
When I added x32 ptrace to 3.4 kernel, I also include PTRACE_ARCH_PRCTL
support for x32 GDB For ARCH_GET_FS/GS, it takes a pointer to int64. But
at user level, ARCH_GET_FS/GS takes a pointer to int32. So I have to add
x32 ptrace to glibc to handle it with a temporary int64 passed to kernel and
copy it back to GDB as int32. Roland suggested that PTRACE_ARCH_PRCTL
is obsolete and x32 GDB should use fs_base and gs_base fields of
user_regs_struct instead.
Accordingly, remove PTRACE_ARCH_PRCTL completely from the x32 code to
avoid possible memory overrun when pointer to int32 is passed to
kernel.
Link: http://lkml.kernel.org/r/CAMe9rOpDzHfS7NH7m1vmD9QRw8SSj4Sc%2BaNOgcWm_WJME2eRsQ@mail.gmail.com
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: <stable@vger.kernel.org> v3.4
Diffstat (limited to 'arch/x86/kernel/ptrace.c')
-rw-r--r-- | arch/x86/kernel/ptrace.c | 6 |
1 files changed, 0 insertions, 6 deletions
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index 13b1990c7c58..c4c6a5c2bf0f 100644 --- a/arch/x86/kernel/ptrace.c +++ b/arch/x86/kernel/ptrace.c @@ -1211,12 +1211,6 @@ static long x32_arch_ptrace(struct task_struct *child, 0, sizeof(struct user_i387_struct), datap); - /* normal 64bit interface to access TLS data. - Works just like arch_prctl, except that the arguments - are reversed. */ - case PTRACE_ARCH_PRCTL: - return do_arch_prctl(child, data, addr); - default: return compat_ptrace_request(child, request, addr, data); } |