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 sure the pointer is within the usable
>
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
> setsockopt uses copy_fr
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 tai
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 Michael's fix does, so I'll
>>> include it in the next version.
>>
>> Actual
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.
>
> Actually, after some offline chats, I thin
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 checking that it was within the slub
>>
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 it above base aft
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).
check_valid_pointe
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? :)
>
> Me.
>
> s-
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 objec
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 subtle race conditions which is the usual :)
>>
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 grsecurity.
>>
>> Signed-off-by: Kees Cook
>
>> di
12 matches
Mail list logo
