Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 30 Nov 2017 12:00:44 +0800
From: zerons <>
To: Kees Cook <>
 Alexander Popov <>
Subject: Re: a part of SLAB_FREELIST_HARDENED feature
 doesn't work well

On 11/23/2017 01:31 AM, Kees Cook wrote:
> On Wed, Nov 22, 2017 at 6:33 AM, zerons <> wrote:
>> (commit-webpage)[]
>> Test it on kernel 4.14.0.
>> When something goes like
>> kfree(a);
>> kfree(a);
>> then `insmod` crashed 'Segment Fault'
>> kfree(a);kfree(b);kfree(a);
>> Got nothing.
>> I add another kernel thread, just free some objects
>> very close to the target object_a;
>> kfree(a);
>>                 another thread does some kfree(...)
>> kfree(a);
>> nothing happened, this patch didn't crash the `insmod` operation.
> Yup, that's expected and that's why it's called "naive". It's a very
> cheap check for a somewhat common condition, but it is not designed to
> catch all double-free conditions. If you want that, try booting with
> "slub_debug=FZP" (this is slower, but should catch a lot of bad
> cases).
> One thing to note is that the naive check works within a single cache,
> which means that kmalloc()/kfree() will be less likely to be protected
> by this due to the many concurrent users. Specific caches (via
> kmem_cache_alloc()kmem_cache_free()) may be more well protected by
> this since there may be less contention.
> -Kees
After a few days of testing, I found that SLAB_FREELIST_HARDENED could
do well in defending double-free-flaws-exploit, with xor obfuscation and
`prefetch_freepointer` which would check the next-next freelist valid if
the next object is not NULL.

Now, I wonder if it's possible that a thread does `kfree(a) kfree(a)` and
another thread does `kmalloc` and get `a` returned just before the second


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.