Re: [kernel-hardening] Re: [PATCH 9/9] mm: SLUB hardened usercopy support

On Fri, Jul 08, 2016 at 04:48:38PM -0400, Kees Cook wrote: > On Fri, Jul 8, 2016 at 1:41 PM, Kees Cook wrote: > > On Fri, Jul 8, 2016 at 12:20 PM, Christoph Lameter wrote: > >> On Fri, 8 Jul 2016, Kees Cook wrote: > >> > >>> Is check_valid_pointer() making

Re: [kernel-hardening] Re: [PATCH 9/9] mm: SLUB hardened usercopy support

On Fri, Jul 8, 2016 at 11:17 PM, wrote: > Yeah, 'ping' dies with a similar traceback going to rawv6_setsockopt(), > and 'trinity' dies a horrid death during initialization because it creates > some sctp sockets to fool around with. The problem in all these cases is that

Re: [kernel-hardening] Re: [PATCH 9/9] mm: SLUB hardened usercopy support

On Sat, 09 Jul 2016 15:58:20 +1000, Michael Ellerman said: > I then get two hits, which may or may not be valid: > > [2.309556] usercopy: kernel memory overwrite attempt detected to > d3510028 (kernfs_node_cache) (64 bytes) > [2.309995] CPU: 7 PID: 2241 Comm: wait-for-root Not

Re: [kernel-hardening] Re: [PATCH 9/9] mm: SLUB hardened usercopy support

Michael Ellerman writes: > Kees Cook writes: > >> On Fri, Jul 8, 2016 at 1:41 PM, Kees Cook wrote: >>> So, as found already, the position in the usercopy check needs to be >>> bumped down by red_left_pad, which is what

Re: [kernel-hardening] Re: [PATCH 9/9] mm: SLUB hardened usercopy support

Kees Cook writes: > On Fri, Jul 8, 2016 at 1:41 PM, Kees Cook wrote: >> So, as found already, the position in the usercopy check needs to be >> bumped down by red_left_pad, which is what Michael's fix does, so I'll >> include it in the next version.

Re: [kernel-hardening] Re: [PATCH 9/9] mm: SLUB hardened usercopy support

On Fri, Jul 8, 2016 at 1:41 PM, Kees Cook wrote: > On Fri, Jul 8, 2016 at 12:20 PM, Christoph Lameter wrote: >> On Fri, 8 Jul 2016, Kees Cook wrote: >> >>> Is check_valid_pointer() making sure the pointer is within the usable >>> size? It seemed like it was

Re: [kernel-hardening] Re: [PATCH 9/9] mm: SLUB hardened usercopy support

On Fri, Jul 8, 2016 at 12:20 PM, Christoph Lameter wrote: > On Fri, 8 Jul 2016, Kees Cook wrote: > >> Is check_valid_pointer() making sure the pointer is within the usable >> size? It seemed like it was checking that it was within the slub >> object (checks against s->size, wants

Re: [kernel-hardening] Re: [PATCH 9/9] mm: SLUB hardened usercopy support

On Fri, 8 Jul 2016, Kees Cook wrote: > Is check_valid_pointer() making sure the pointer is within the usable > size? It seemed like it was checking that it was within the slub > object (checks against s->size, wants it above base after moving > pointer to include redzone, etc).

Re: [kernel-hardening] Re: [PATCH 9/9] mm: SLUB hardened usercopy support

On Fri, Jul 8, 2016 at 9:45 AM, Christoph Lameter wrote: > On Fri, 8 Jul 2016, Michael Ellerman wrote: > >> > I wonder if this code should be using size_from_object() instead of >> > s->size? BTW, I can't reproduce this on x86 yet... >> >> Hmm, not sure. Who's SLUB maintainer?

Re: [kernel-hardening] Re: [PATCH 9/9] mm: SLUB hardened usercopy support

On Fri, 8 Jul 2016, Michael Ellerman wrote: > > I wonder if this code should be using size_from_object() instead of s->size? > > Hmm, not sure. Who's SLUB maintainer? :) Me. s->size is the size of the whole object including debugging info etc. ksize() gives you the actual usable size of an

Re: [kernel-hardening] Re: [PATCH 9/9] mm: SLUB hardened usercopy support

Kees Cook writes: > On Thu, Jul 7, 2016 at 12:35 AM, Michael Ellerman wrote: >> I gave this a quick spin on powerpc, it blew up immediately :) > > Wheee :) This series is rather easy to test: blows up REALLY quickly > if it's wrong. ;) Better than

Re: [kernel-hardening] Re: [PATCH 9/9] mm: SLUB hardened usercopy support

On Thu, Jul 7, 2016 at 12:35 AM, Michael Ellerman wrote: > Kees Cook writes: > >> Under CONFIG_HARDENED_USERCOPY, this adds object size checking to the >> SLUB allocator to catch any copies that may span objects. >> >> Based on code from PaX and