From: Harry Yoo <harry.yoo@oracle.com>
To: Kees Cook <kees@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Christoph Lameter <cl@linux.com>, Miguel Ojeda <ojeda@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Marco Elver <elver@google.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-hardening@vger.kernel.org
Subject: Re: [RFC 0/5] slab: Set freed variables to NULL by default
Date: Thu, 27 Mar 2025 22:00:34 +0900 [thread overview]
Message-ID: <Z-VL8ptvIVL1A6po@harry> (raw)
In-Reply-To: <20250321202620.work.175-kees@kernel.org>
On Fri, Mar 21, 2025 at 01:40:56PM -0700, Kees Cook wrote:
> Hi!
>
> This is very much an RFC series, but I wanted to make sure it actually
> worked before I proposed it. This series seeks to give kfree() the
>` side-effect of assigning NULL to the kfree() argument when possible.
> This would make a subset of "dangling pointer" flaws turn into NULL
> derefs instead of Use-After-Free[1]. It effectively turns:
>
> kfree(var);
>
> into:
>
> kfree(var);
> var = NULL;
>
> when "var" is actually addressable. (i.e. not "kfree(get_ptrs())" etc.)
Maybe a dumb question, but if 'var' is a local variable, is it common that
a dangling pointer in a local variable to lead to a use-after-free bug?
Also, I don't expect this to have a significant performance impact, but have
you measured it and is the overhead low enough to enable it unconditionally?
> It depends on a builtin, __builtin_is_lvalue(), which is not landed in any
> compiler yet, but I do have it working in a Clang patch[2]. This should
> be essentially free (pardon the pun), so I think if folks can tolerate
> a little bit of renaming needed for when kfree is needed as a function
> and not a macro, it should be good. Please let me know what you think.
I don't have a strong opinion on the slab side, but now users of kfree
should be aware of this subtle change (e.g., when debugging code).
--
Cheers,
Harry (formerly known as Hyeonggon)
> Thanks!
>
> -Kees
>
> (Yes, I'm still working on the kmalloc_objs() series, but I needed to
> take a break from fixing all the allocation corner cases I've found there.)
>
> [1] https://github.com/KSPP/linux/issues/87
> [2] https://github.com/kees/llvm-project/commits/builtin_is_lvalue/
>
> Kees Cook (5):
> treewide: Replace kfree() casts with union members
> treewide: Prepare for kfree() to __kfree() rename
> compiler_types: Introduce __is_lvalue()
> slab: Set freed variables to NULL by default
> [DEBUG] slab: Report number of NULLings
>
> arch/mips/alchemy/common/dbdma.c | 2 +-
> include/linux/compiler_types.h | 10 ++++++++++
> include/linux/netlink.h | 1 +
> include/linux/slab.h | 33 ++++++++++++++++++++++++++++++--
> include/net/pkt_cls.h | 5 ++++-
> io_uring/futex.c | 2 +-
> io_uring/io_uring.c | 12 ++++++------
> kernel/bpf/core.c | 3 ++-
> mm/slab_common.c | 12 ++++++++----
> mm/slub.c | 6 +++---
> net/sched/ematch.c | 2 +-
> net/wireless/nl80211.c | 2 +-
> 12 files changed, 69 insertions(+), 21 deletions(-)
>
> --
> 2.34.1
>
prev parent reply other threads:[~2025-03-27 13:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-21 20:40 [RFC 0/5] slab: Set freed variables to NULL by default Kees Cook
2025-03-21 20:40 ` [PATCH 1/5] treewide: Replace kfree() casts with union members Kees Cook
2025-03-23 10:26 ` David Laight
2025-03-21 20:40 ` [PATCH 2/5] treewide: Prepare for kfree() to __kfree() rename Kees Cook
2025-03-21 20:40 ` [PATCH 3/5] compiler_types: Introduce __is_lvalue() Kees Cook
2025-03-22 3:38 ` Jann Horn
2025-03-22 7:03 ` Kees Cook
2025-03-21 20:41 ` [PATCH 4/5] slab: Set freed variables to NULL by default Kees Cook
2025-03-22 1:50 ` Jann Horn
2025-03-22 7:18 ` Kees Cook
2025-03-27 19:23 ` Jann Horn
2025-03-27 19:42 ` Matthew Wilcox
2025-03-21 20:41 ` [PATCH 5/5] [DEBUG] slab: Report number of NULLings Kees Cook
2025-03-24 16:16 ` Christoph Lameter (Ampere)
2025-03-25 19:45 ` Kees Cook
2025-03-27 13:00 ` Harry Yoo [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=Z-VL8ptvIVL1A6po@harry \
--to=harry.yoo@oracle.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=elver@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=ojeda@kernel.org \
--cc=penberg@kernel.org \
--cc=przemyslaw.kitszel@intel.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@suse.cz \
/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.