[PATCH v4 3/3] arm64/uaccess: Add hardened usercopy check for bad stack accesses

Kees Cook keescook at chromium.org
Thu Feb 16 16:44:04 PST 2017


On Thu, Feb 16, 2017 at 10:29 AM, James Morse <james.morse at arm.com> wrote:
> lkdtm tests copy_{to,from}_user() by trying to copy an address range
> on the stack that isn't yet part of a stack frame.
>
> By the time the stack walker is invoked to check that the object being
> copied doesn't overlap stack frame, the invalid range is part of a valid
> stack frame. Discarding a constant number of frames is fragile as different
> compiler versions may make different inline choices.
>
> Instead, add a check that the object isn't between the current stack
> pointer and the end of the stack. Add this early enough that it should
> be inlined into the caller.
>
> CC: Sahara <keun-o.park at darkmatter.ae>
> Signed-off-by: James Morse <james.morse at arm.com>
> ---
>  arch/arm64/include/asm/uaccess.h | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> index 46da3ea638bb..d3494840a61c 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -356,6 +356,22 @@ do {                                                                       \
>                 -EFAULT;                                                \
>  })
>
> +static inline void check_obj_in_unused_stack(const void *obj, unsigned long len)
> +{
> +       unsigned long stack = (unsigned long)task_stack_page(current);
> +
> +       if (__builtin_constant_p(len) || !IS_ENABLED(CONFIG_HARDENED_USERCOPY) || !len)
> +               return;
> +
> +       /*
> +        * If current_stack_pointer is on the task stack, obj must not lie
> +        * between current_stack_pointer and the last stack address.
> +        */
> +       if ((current_stack_pointer & ~(THREAD_SIZE-1)) == stack)
> +               BUG_ON(stack <= (unsigned long)obj &&
> +                      (unsigned long)obj < current_stack_pointer);
> +}

It seems like this would be a valid test on all architecture, yes? I
wonder if this could be reworked so we don't have a special case for
ARM here...

-Kees

-- 
Kees Cook
Pixel Security



More information about the linux-arm-kernel mailing list