[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87poq78ova.fsf@@concordia.ellerman.id.au>
Date: Thu, 21 Jul 2016 16:52:09 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org
Cc: Kees Cook <keescook@...omium.org>, Balbir Singh <bsingharora@...il.com>, Daniel Micay <danielmicay@...il.com>, Josh Poimboeuf <jpoimboe@...hat.com>, Rik van Riel <riel@...hat.com>, Casey Schaufler <casey@...aufler-ca.com>, PaX Team <pageexec@...email.hu>, Brad Spengler <spender@...ecurity.net>, Russell King <linux@...linux.org.uk>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Tony Luck <tony.luck@...el.com>, Fenghua Yu <fenghua.yu@...el.com>, "David S. Miller" <davem@...emloft.net>, x86@...nel.org, Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>, Joonsoo Kim <iamjoonsoo.kim@....com>, Andrew Morton <akpm@...ux-foundation.org>, Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...e.de>, Mathias Krause <minipli@...glemail.com>, Jan Kara <jack@...e.cz>, Vitaly Wool <vitalywool@...il.com>, Andrea
Arcangeli <aarcange@...hat.com>, Dmitry Vyukov <dvyukov@...gle.com>, Laura Abbott <labbott@...oraproject.org>, linux-arm-kernel@...ts.infradead.org, linux-ia64@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org, sparclinux@...r.kernel.org, linux-arch@...r.kernel.org, linux-mm@...ck.org, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v3 02/11] mm: Hardened usercopy
Kees Cook <keescook@...omium.org> writes:
> diff --git a/mm/usercopy.c b/mm/usercopy.c
> new file mode 100644
> index 000000000000..e4bf4e7ccdf6
> --- /dev/null
> +++ b/mm/usercopy.c
> @@ -0,0 +1,234 @@
...
> +
> +/*
> + * Checks if a given pointer and length is contained by the current
> + * stack frame (if possible).
> + *
> + * 0: not at all on the stack
> + * 1: fully within a valid stack frame
> + * 2: fully on the stack (when can't do frame-checking)
> + * -1: error condition (invalid stack position or bad stack frame)
> + */
> +static noinline int check_stack_object(const void *obj, unsigned long len)
> +{
> + const void * const stack = task_stack_page(current);
> + const void * const stackend = stack + THREAD_SIZE;
That allows access to the entire stack, including the struct thread_info,
is that what we want - it seems dangerous? Or did I miss a check
somewhere else?
We have end_of_stack() which computes the end of the stack taking
thread_info into account (end being the opposite of your end above).
cheers
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
