2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* User address space access functions.
|
|
|
|
*
|
|
|
|
* Copyright 1997 Andi Kleen <ak@muc.de>
|
|
|
|
* Copyright 1997 Linus Torvalds
|
|
|
|
* Copyright 2002 Andi Kleen <ak@suse.de>
|
|
|
|
*/
|
2016-07-14 08:18:57 +08:00
|
|
|
#include <linux/export.h>
|
2016-07-15 04:22:57 +08:00
|
|
|
#include <linux/uaccess.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Zero Userspace
|
|
|
|
*/
|
|
|
|
|
|
|
|
unsigned long __clear_user(void __user *addr, unsigned long size)
|
|
|
|
{
|
|
|
|
long __d0;
|
2008-09-10 19:37:17 +08:00
|
|
|
might_fault();
|
2005-04-17 06:20:36 +08:00
|
|
|
/* no memory constraint because it doesn't change any memory gcc knows
|
|
|
|
about */
|
2012-09-22 03:43:12 +08:00
|
|
|
stac();
|
2005-04-17 06:20:36 +08:00
|
|
|
asm volatile(
|
|
|
|
" testq %[size8],%[size8]\n"
|
|
|
|
" jz 4f\n"
|
|
|
|
"0: movq %[zero],(%[dst])\n"
|
|
|
|
" addq %[eight],%[dst]\n"
|
|
|
|
" decl %%ecx ; jnz 0b\n"
|
|
|
|
"4: movq %[size1],%%rcx\n"
|
|
|
|
" testl %%ecx,%%ecx\n"
|
|
|
|
" jz 2f\n"
|
|
|
|
"1: movb %b[zero],(%[dst])\n"
|
|
|
|
" incq %[dst]\n"
|
|
|
|
" decl %%ecx ; jnz 1b\n"
|
|
|
|
"2:\n"
|
|
|
|
".section .fixup,\"ax\"\n"
|
|
|
|
"3: lea 0(%[size1],%[size8],8),%[size8]\n"
|
|
|
|
" jmp 2b\n"
|
|
|
|
".previous\n"
|
2008-02-04 23:47:57 +08:00
|
|
|
_ASM_EXTABLE(0b,3b)
|
|
|
|
_ASM_EXTABLE(1b,2b)
|
x86: use early clobbers in usercopy*.c
Impact: fix rare (but currently harmless) miscompile with certain configs and gcc versions
Hugh Dickins noticed that strncpy_from_user() was miscompiled
in some circumstances with gcc 4.3.
Thanks to Hugh's excellent analysis it was easy to track down.
Hugh writes:
> Try building an x86_64 defconfig 2.6.29-rc1 kernel tree,
> except not quite defconfig, switch CONFIG_PREEMPT_NONE=y
> and CONFIG_PREEMPT_VOLUNTARY off (because it expands a
> might_fault() there, which hides the issue): using a
> gcc 4.3.2 (I've checked both openSUSE 11.1 and Fedora 10).
>
> It generates the following:
>
> 0000000000000000 <__strncpy_from_user>:
> 0: 48 89 d1 mov %rdx,%rcx
> 3: 48 85 c9 test %rcx,%rcx
> 6: 74 0e je 16 <__strncpy_from_user+0x16>
> 8: ac lods %ds:(%rsi),%al
> 9: aa stos %al,%es:(%rdi)
> a: 84 c0 test %al,%al
> c: 74 05 je 13 <__strncpy_from_user+0x13>
> e: 48 ff c9 dec %rcx
> 11: 75 f5 jne 8 <__strncpy_from_user+0x8>
> 13: 48 29 c9 sub %rcx,%rcx
> 16: 48 89 c8 mov %rcx,%rax
> 19: c3 retq
>
> Observe that "sub %rcx,%rcx; mov %rcx,%rax", whereas gcc 4.2.1
> (and many other configs) say "sub %rcx,%rdx; mov %rdx,%rax".
> Isn't it returning 0 when it ought to be returning strlen?
The asm constraints for the strncpy_from_user() result were missing an
early clobber, which tells gcc that the last output arguments
are written before all input arguments are read.
Also add more early clobbers in the rest of the file and fix 32-bit
usercopy.c in the same way.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
[ since this API is rarely used and no in-kernel user relies on a 'len'
return value (they only rely on negative return values) this miscompile
was never noticed in the field. But it's worth fixing it nevertheless. ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-01-16 22:22:11 +08:00
|
|
|
: [size8] "=&c"(size), [dst] "=&D" (__d0)
|
2005-04-17 06:20:36 +08:00
|
|
|
: [size1] "r"(size & 7), "[size8]" (size / 8), "[dst]"(addr),
|
|
|
|
[zero] "r" (0UL), [eight] "r" (8UL));
|
2012-09-22 03:43:12 +08:00
|
|
|
clac();
|
2005-04-17 06:20:36 +08:00
|
|
|
return size;
|
|
|
|
}
|
2006-06-26 19:59:44 +08:00
|
|
|
EXPORT_SYMBOL(__clear_user);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
unsigned long clear_user(void __user *to, unsigned long n)
|
|
|
|
{
|
|
|
|
if (access_ok(VERIFY_WRITE, to, n))
|
|
|
|
return __clear_user(to, n);
|
|
|
|
return n;
|
|
|
|
}
|
2006-06-26 19:59:44 +08:00
|
|
|
EXPORT_SYMBOL(clear_user);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
unsigned long copy_in_user(void __user *to, const void __user *from, unsigned len)
|
|
|
|
{
|
|
|
|
if (access_ok(VERIFY_WRITE, to, len) && access_ok(VERIFY_READ, from, len)) {
|
|
|
|
return copy_user_generic((__force void *)to, (__force void *)from, len);
|
|
|
|
}
|
|
|
|
return len;
|
|
|
|
}
|
2006-06-26 19:59:44 +08:00
|
|
|
EXPORT_SYMBOL(copy_in_user);
|
|
|
|
|
2008-07-02 21:48:21 +08:00
|
|
|
/*
|
|
|
|
* Try to copy last bytes and clear the rest if needed.
|
|
|
|
* Since protection fault in copy_from/to_user is not a normal situation,
|
|
|
|
* it is not necessary to optimize tail handling.
|
|
|
|
*/
|
2013-08-06 06:02:43 +08:00
|
|
|
__visible unsigned long
|
2015-04-07 01:26:17 +08:00
|
|
|
copy_user_handle_tail(char *to, char *from, unsigned len)
|
2008-07-02 21:48:21 +08:00
|
|
|
{
|
2013-03-18 23:02:21 +08:00
|
|
|
for (; len; --len, to++) {
|
2015-04-07 01:26:17 +08:00
|
|
|
char c;
|
|
|
|
|
2008-07-02 21:48:21 +08:00
|
|
|
if (__get_user_nocheck(c, from++, sizeof(char)))
|
|
|
|
break;
|
2013-03-18 23:02:21 +08:00
|
|
|
if (__put_user_nocheck(c, to, sizeof(char)))
|
2008-07-02 21:48:21 +08:00
|
|
|
break;
|
|
|
|
}
|
2012-09-22 03:43:12 +08:00
|
|
|
clac();
|
2015-04-07 01:26:17 +08:00
|
|
|
|
|
|
|
/* If the destination is a kernel buffer, we always clear the end */
|
x86: fix special __probe_kernel_write() tail zeroing case
Commit cae2a173fe94 ("x86: clean up/fix 'copy_in_user()' tail zeroing")
fixed the failure case tail zeroing of one special case of the x86-64
generic user-copy routine, namely when used for the user-to-user case
("copy_in_user()").
But in the process it broke an even more unusual case: using the user
copy routine for kernel-to-kernel copying.
Now, normally kernel-kernel copies are obviously done using memcpy(),
but we have a couple of special cases when we use the user-copy
functions. One is when we pass a kernel buffer to a regular user-buffer
routine, using set_fs(KERNEL_DS). That's a "normal" case, and continued
to work fine, because it never takes any faults (with the possible
exception of a silent and successful vmalloc fault).
But Jan Beulich pointed out another, very unusual, special case: when we
use the user-copy routines not because it's a path that expects a user
pointer, but for a couple of ftrace/kgdb cases that want to do a kernel
copy, but do so using "unsafe" buffers, and use the user-copy routine to
gracefully handle faults. IOW, for probe_kernel_write().
And that broke for the case of a faulting kernel destination, because we
saw the kernel destination and wanted to try to clear the tail of the
buffer. Which doesn't work, since that's what faults.
This only triggers for things like kgdb and ftrace users (eg trying
setting a breakpoint on read-only memory), but it's definitely a bug.
The fix is to not compare against the kernel address start (TASK_SIZE),
but instead use the same limits "access_ok()" uses.
Reported-and-tested-by: Jan Beulich <jbeulich@suse.com>
Cc: stable@vger.kernel.org # 4.0
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-23 23:33:59 +08:00
|
|
|
if (!__addr_ok(to))
|
2015-04-07 01:26:17 +08:00
|
|
|
memset(to, 0, len);
|
2008-07-02 21:48:21 +08:00
|
|
|
return len;
|
|
|
|
}
|