All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Thomas Hellstrom <thellstrom@vmware.com>,
	Andi Kleen <ak@linux.intel.com>,
	Daniel Micay <danielmicay@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH v2] kref: Avoid null pointer dereference after WARN
Date: Tue, 27 Jun 2017 12:00:02 -0700	[thread overview]
Message-ID: <20170627190001.GA7811@beast> (raw)

From: Daniel Micay <danielmicay@gmail.com>

The WARN_ON() checking for a NULL release pointer was (sensibly)
removed in commit ec48c940da6c ("kref: remove WARN_ON for NULL release
functions") since it offered no protection at all about calling a NULL
release pointer. However, it should instead be a BUG() since continuing
with a NULL release pointer will lead to a NULL pointer execution
anyway. Systems with an incorrectly set mmap_min_addr and no PXN/SMEP
protection would be left open to executing userspace memory.

The kref_put() case is extracted from PaX, and Kees Cook noted it should
be extended to the other two cases.

Comparison of my build with WARN, with nothing, and with BUG:

   text            data    bss         dec       hex     filename
  11300251        5586597 13955072    30841920  1d69c40 vmlinux.warn
  11298136        5586597 13955072    30839805  1d693fd vmlinux.none
  11300062        5586629 13955072    30841763  1d69ba3 vmlinux.bug

Signed-off-by: Daniel Micay <danielmicay@gmail.com>
[kees: clarify commit log, refreshed diff, moved into if statement]
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 include/linux/kref.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/kref.h b/include/linux/kref.h
index 29220724bf1c..651a12d2425f 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -67,6 +67,7 @@ static inline void kref_get(struct kref *kref)
 static inline int kref_put(struct kref *kref, void (*release)(struct kref *kref))
 {
 	if (refcount_dec_and_test(&kref->refcount)) {
+		BUG_ON(release == NULL);
 		release(kref);
 		return 1;
 	}
@@ -78,6 +79,7 @@ static inline int kref_put_mutex(struct kref *kref,
 				 struct mutex *lock)
 {
 	if (refcount_dec_and_mutex_lock(&kref->refcount, lock)) {
+		BUG_ON(release == NULL);
 		release(kref);
 		return 1;
 	}
@@ -89,6 +91,7 @@ static inline int kref_put_lock(struct kref *kref,
 				spinlock_t *lock)
 {
 	if (refcount_dec_and_lock(&kref->refcount, lock)) {
+		BUG_ON(release == NULL);
 		release(kref);
 		return 1;
 	}
-- 
2.7.4


-- 
Kees Cook
Pixel Security

             reply	other threads:[~2017-06-27 19:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-27 19:00 Kees Cook [this message]
2017-06-27 19:15 ` [PATCH v2] kref: Avoid null pointer dereference after WARN Jason A. Donenfeld
2017-06-27 19:22 ` Andi Kleen
2017-06-27 19:26   ` Jason A. Donenfeld
2017-06-27 19:34     ` Kees Cook
2017-06-27 19:48       ` Andi Kleen
2017-06-27 20:16       ` Daniel Micay

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=20170627190001.GA7811@beast \
    --to=keescook@chromium.org \
    --cc=Jason@zx2c4.com \
    --cc=ak@linux.intel.com \
    --cc=danielmicay@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=thellstrom@vmware.com \
    /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.