From: Greg KH <gregkh@linuxfoundation.org>
To: Kees Cook <keescook@chromium.org>
Cc: akpm@linux-foundation.org, cl@linux.com, iamjoonsoo.kim@lge.com,
penberg@kernel.org, rientjes@google.com, silvio.cesare@gmail.com,
stable@vger.kernel.org
Subject: Re: [PATCH][v4.19][v4.14] slub: improve bit diffusion for freelist ptr obfuscation
Date: Tue, 14 Apr 2020 10:09:08 +0200 [thread overview]
Message-ID: <20200414080908.GA4147420@kroah.com> (raw)
In-Reply-To: <202004131001.20346EB0E7@keescook>
On Mon, Apr 13, 2020 at 10:03:23AM -0700, Kees Cook wrote:
> commit 1ad53d9fa3f6168ebcf48a50e08b170432da2257 upstream.
>
> Under CONFIG_SLAB_FREELIST_HARDENED=y, the obfuscation was relatively weak
> in that the ptr and ptr address were usually so close that the first XOR
> would result in an almost entirely 0-byte value[1], leaving most of the
> "secret" number ultimately being stored after the third XOR. A single
> blind memory content exposure of the freelist was generally sufficient to
> learn the secret.
>
> Add a swab() call to mix bits a little more. This is a cheap way (1
> cycle) to make attacks need more than a single exposure to learn the
> secret (or to know _where_ the exposure is in memory).
>
> kmalloc-32 freelist walk, before:
>
> ptr ptr_addr stored value secret
> ffff90c22e019020@ffff90c22e019000 is 86528eb656b3b5bd (86528eb656b3b59d)
> ffff90c22e019040@ffff90c22e019020 is 86528eb656b3b5fd (86528eb656b3b59d)
> ffff90c22e019060@ffff90c22e019040 is 86528eb656b3b5bd (86528eb656b3b59d)
> ffff90c22e019080@ffff90c22e019060 is 86528eb656b3b57d (86528eb656b3b59d)
> ffff90c22e0190a0@ffff90c22e019080 is 86528eb656b3b5bd (86528eb656b3b59d)
> ...
>
> after:
>
> ptr ptr_addr stored value secret
> ffff9eed6e019020@ffff9eed6e019000 is 793d1135d52cda42 (86528eb656b3b59d)
> ffff9eed6e019040@ffff9eed6e019020 is 593d1135d52cda22 (86528eb656b3b59d)
> ffff9eed6e019060@ffff9eed6e019040 is 393d1135d52cda02 (86528eb656b3b59d)
> ffff9eed6e019080@ffff9eed6e019060 is 193d1135d52cdae2 (86528eb656b3b59d)
> ffff9eed6e0190a0@ffff9eed6e019080 is f93d1135d52cdac2 (86528eb656b3b59d)
>
> [1] https://blog.infosectcbr.com.au/2020/03/weaknesses-in-linux-kernel-heap.html
>
> Fixes: 2482ddec670f ("mm: add SLUB free list pointer obfuscation")
> Reported-by: Silvio Cesare <silvio.cesare@gmail.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Pekka Enberg <penberg@kernel.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Cc: <stable@vger.kernel.org>
> Link: http://lkml.kernel.org/r/202003051623.AF4F8CB@keescook
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> [kees: Backport to v4.19 which doesn't call kasan_reset_untag()]
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> This requires that commit d5767057c9a76a29f073dad66b7fa12a90e8c748 is
> also cherry-picked into -stable.
> ---
> mm/slub.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 9b7b989273d4..d8116a43a287 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -249,7 +249,7 @@ static inline void *freelist_ptr(const struct kmem_cache *s, void *ptr,
> unsigned long ptr_addr)
> {
> #ifdef CONFIG_SLAB_FREELIST_HARDENED
> - return (void *)((unsigned long)ptr ^ s->random ^ ptr_addr);
> + return (void *)((unsigned long)ptr ^ s->random ^ swab(ptr_addr));
> #else
> return ptr;
> #endif
> --
> 2.20.1
>
>
> --
Now queued up, thanks.
greg k-h
prev parent reply other threads:[~2020-04-14 8:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-13 17:03 [PATCH][v4.19][v4.14] slub: improve bit diffusion for freelist ptr obfuscation Kees Cook
2020-04-14 8:09 ` Greg KH [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200414080908.GA4147420@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=keescook@chromium.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=silvio.cesare@gmail.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.