From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752133AbdF0HGi (ORCPT ); Tue, 27 Jun 2017 03:06:38 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:46494 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751492AbdF0HGd (ORCPT ); Tue, 27 Jun 2017 03:06:33 -0400 Date: Tue, 27 Jun 2017 09:06:26 +0200 From: Greg Kroah-Hartman To: Kees Cook Cc: Ingo Molnar , Peter Zijlstra , "Jason A. Donenfeld" , Thomas Hellstrom , Andi Kleen , Daniel Micay , linux-kernel@vger.kernel.org Subject: Re: [PATCH] kref: Avoid null pointer dereference after WARN Message-ID: <20170627070626.GH29909@kroah.com> References: <20170627035215.GA132342@beast> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170627035215.GA132342@beast> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 26, 2017 at 08:52:15PM -0700, Kees Cook wrote: > From: Daniel Micay > > The WARN_ON() checking for a NULL release pointer should be a BUG() > since continuing with a NULL release pointer will lead to a NULL > pointer dereference anyway. > > The kref_put() case is extracted from PaX, and Kees Cook noted it should > be extended to the other two cases. > > Signed-off-by: Daniel Micay > [kees: clarify commit log] > Signed-off-by: Kees Cook > --- > include/linux/kref.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/linux/kref.h b/include/linux/kref.h > index f4156f88f557..82a2c225eae3 100644 > --- a/include/linux/kref.h > +++ b/include/linux/kref.h > @@ -66,7 +66,7 @@ static inline void kref_get(struct kref *kref) > */ > static inline int kref_put(struct kref *kref, void (*release)(struct kref *kref)) > { > - WARN_ON(release == NULL); > + BUG_ON(release == NULL); I remember one complaint was that WARN_ON was "huge" and this bloated the kernel code a lot. But then that got fixed up. Is BUG_ON going to cause the same complaint again? thanks, greg k-h