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

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

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 Cook
Pixel Security

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.