From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753275AbdF0SeU (ORCPT ); Tue, 27 Jun 2017 14:34:20 -0400 Received: from mail-io0-f173.google.com ([209.85.223.173]:34602 "EHLO mail-io0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752316AbdF0SeO (ORCPT ); Tue, 27 Jun 2017 14:34:14 -0400 MIME-Version: 1.0 In-Reply-To: <20170627070626.GH29909@kroah.com> References: <20170627035215.GA132342@beast> <20170627070626.GH29909@kroah.com> From: Kees Cook Date: Tue, 27 Jun 2017 11:34:12 -0700 X-Google-Sender-Auth: EfbF4Vnp7sWTswnw4wOGO0fdr1g Message-ID: Subject: Re: [PATCH] kref: Avoid null pointer dereference after WARN To: Greg Kroah-Hartman Cc: Ingo Molnar , Peter Zijlstra , "Jason A. Donenfeld" , Thomas Hellstrom , Andi Kleen , Daniel Micay , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 27, 2017 at 12:06 AM, Greg Kroah-Hartman wrote: > 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? It used to be that WARN was much larger than BUG, but Peter Z fixed[1] that recently. BUG is very small (on x86 a single instruction). I'll send a v2 with the .text comparison. -Kees [1] 9a93848fe787 ("x86/debug: Implement __WARN() using UD0") -- Kees Cook Pixel Security