Re: [PATCH v6 1/3] mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options
From: Kees Cook <hidden>
Date: 2019-06-21 01:37:35
Also in:
linux-mm
From: Kees Cook <hidden>
Date: 2019-06-21 01:37:35
Also in:
linux-mm
On Fri, Jun 07, 2019 at 08:42:27AM -0700, Kees Cook wrote:
On Thu, Jun 06, 2019 at 06:48:43PM +0200, Alexander Potapenko wrote:quoted
[...]diff --git a/mm/slub.c b/mm/slub.c index cd04dbd2b5d0..9c4a8b9a955c 100644 --- a/mm/slub.c +++ b/mm/slub.c[...]@@ -2741,8 +2758,14 @@ static __always_inline void *slab_alloc_node(struct kmem_cache *s, prefetch_freepointer(s, next_object); stat(s, ALLOC_FASTPATH); } + /* + * If the object has been wiped upon free, make sure it's fully + * initialized by zeroing out freelist pointer. + */ + if (unlikely(slab_want_init_on_free(s)) && object) + *(void **)object = NULL;
In looking at metadata again, I noticed that I don't think this is correct, as it needs to be using s->offset to find the location of the freelist pointer: memset(object + s->offset, 0, sizeof(void *));
quoted
- if (unlikely(gfpflags & __GFP_ZERO) && object) + if (unlikely(slab_want_init_on_alloc(gfpflags, s)) && object) memset(object, 0, s->object_size);
init_on_alloc is using "object_size" but init_on_free is using "size". I assume the "alloc" wipe is smaller because metadata was just written for the allocation? -- Kees Cook