Date: Wed, 22 Nov 2017 09:31:14 -0800 From: Kees Cook <keescook@...omium.org> To: zerons <zeronsaxm@...il.com> Cc: kernel-hardening@...ts.openwall.com, Alexander Popov <alex.popov@...ux.com> Subject: Re: a part of SLAB_FREELIST_HARDENED feature doesn't work well On Wed, Nov 22, 2017 at 6:33 AM, zerons <zeronsaxm@...il.com> wrote: > (commit-webpage)[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce6fa91b93630396ca220c33dd38ffc62686d499] > > 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 -- 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.