Message ID | 20250321202620.work.175-kees@kernel.org (mailing list archive) |
---|---|
Headers | show |
Series | slab: Set freed variables to NULL by default | expand |
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).