Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4424149ioa; Wed, 27 Apr 2022 03:40:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzmxut7aTjRS5zinV5XJS/QJHpLXI0Slk4bdqnHDcT9wh4WJ037mO6j7rlEf5o8eUzcp4TC X-Received: by 2002:a17:90a:1944:b0:1d9:7cf8:5457 with SMTP id 4-20020a17090a194400b001d97cf85457mr16018820pjh.112.1651056009528; Wed, 27 Apr 2022 03:40:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651056009; cv=none; d=google.com; s=arc-20160816; b=chwPO6nSXuI/hnYZLvhtUKO68LLxz00w/9qd6x4vQ9DDgB2wtqXzY6RzdQsfWWlU8b uCgejCAqDPrZqGGI1JbdLgdDPCw+BAJZBRT4LQhr6QhS+GdkiZl6+OrI1giMd8FSqPC5 +LX8hpCzFL2zkZAlvz9Jukc1fyE8yhQHRIZ8SgPJHPVmyVrktwhQa8ktwIsT59QiXRjE 6UpNwI7M5eBfHAREcMNmYHghlX+3b4hEzo+Hj1SjCOZ8770KBh5AQZ3lFLcnpH3L1Yuq COhVOl+Vda7Bs34kFg9x3Pca13iWMUmxE+ze+kWwvAoXUv4sGHTsXzAWHCOw4YkRcQJe eqEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=MeaX4XdIMOSF04IoR3Cab+z51sfQuXXpK7U3HQj8e9Y=; b=XNY+4zFeu6jLOZ60IU11rcfTZt0/GyFnLhza5uPA43eyo7v6HITvrXV1CHrhm+nUcN EtIByFASynx5pObBvF/+YTJjARogNrgq5/dYqSRnvcqBfxVlVwCluZ0CIuqbwtOgA/tW ZD1DvToilGSOq6JWbU9BF+BWCHEQYsU8Bjt4bAFGFmnOvog1ioLrweQVSQmq+VmmBFrf sOzxp//DjyZ3bU7MrcvnY3dAn1YJTKW1Eb9+6cUbUthHlkhw/vw85anFR7MzK06vX9yD BZ5yuez8xthtlKDtaMBdP4IIE1V2XB7z3KIP4rye/aNyd/8M8qdgnt3C+G3R3AHnG575 K2Rg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=hrx36cVw; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id z2-20020a63b042000000b003aa3662bf20si1053277pgo.879.2022.04.27.03.40.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 03:40:09 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=hrx36cVw; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 36BC423EE29; Wed, 27 Apr 2022 02:50:58 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358891AbiD0Hhm (ORCPT + 99 others); Wed, 27 Apr 2022 03:37:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358880AbiD0Hhk (ORCPT ); Wed, 27 Apr 2022 03:37:40 -0400 Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D69F48D6B7 for ; Wed, 27 Apr 2022 00:34:29 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id w17so1790052ybh.9 for ; Wed, 27 Apr 2022 00:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MeaX4XdIMOSF04IoR3Cab+z51sfQuXXpK7U3HQj8e9Y=; b=hrx36cVw/CY8EF92h5eVbLNh7vWB+J2wMLxiihlJLMVIrB09HKNrVpmudoLr6cBTkF dTD6fYbQbe//a0D1xDVLTbodu6ak07ePMkofE2pde60ZH/ukdZz5XN8c6kU2mc3qEZo5 IGs0I08RMsWPfVww55ImcBBESzBwMpqhQDuPMQcURMIlO243HR8YWJ4VVm95ZBkByJNn 5Jw/jgkylrTeEs743xCSQYs9OOVwUqaThcN3etmD+rUK/H6GAaplb9PN9xKPUTvs+8ws Z1aFBFXccngNPA6LZWxQe3E77+EM2vY7X3Ec8JdBjBlCh+VatF138DxaOSrj/cUGcUa+ qPeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MeaX4XdIMOSF04IoR3Cab+z51sfQuXXpK7U3HQj8e9Y=; b=yjU17KBVcHVas6SJg+vptMuD2nn74h2iGWsUkMDDREWseyX8YOdcF08Xn7nK97Y2mb LwbaRzvKN6H9S6CDbLN15PJB923EtrDnNSYUkg4T/tK9luc0E7RwwEERzOHwiriAmBoe ZBVrKE7L6sTk02cN9w74MYEV7xYAhveJEbvgPStmk2PaDrGDhPysAghp8YbCcCK9wsdX aPIImC7JK9etrel+dkZQrimK5VU2OCzjq4zbixwU/coklJPQ3YpJ5AvmZVYg5WL2NQLu WyDIAiLsFzhof07wHktjtv/beJvJ+/1If2R/XGHxH8Of30YXZPVCzzikEVJ3orugTgUA MKZg== X-Gm-Message-State: AOAM531Sn+jTg5Vt57mlfU37c8sNd0y1b97yDZm8F/t6Kw3w/5B4bUwh IqSD7iXpDq4c+NsKw99AxClks7Ai8vrsaRbqWZr8/A== X-Received: by 2002:a25:cc0b:0:b0:648:4590:6cb6 with SMTP id l11-20020a25cc0b000000b0064845906cb6mr15972505ybf.87.1651044868807; Wed, 27 Apr 2022 00:34:28 -0700 (PDT) MIME-Version: 1.0 References: <20220427071100.3844081-1-xu.xin16@zte.com.cn> In-Reply-To: <20220427071100.3844081-1-xu.xin16@zte.com.cn> From: Marco Elver Date: Wed, 27 Apr 2022 09:33:52 +0200 Message-ID: Subject: Re: [PATCH] mm/kfence: fix a potential NULL pointer dereference To: cgel.zte@gmail.com Cc: glider@google.com, akpm@linux-foundation.org, dvyukov@google.com, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, xu xin , Zeal Robot Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 27 Apr 2022 at 09:11, wrote: > > From: xu xin > > In __kfence_free(), the returned 'meta' from addr_to_metadata() > might be NULL just as the implementation of addr_to_metadata() > shows. > > Let's add a check of the pointer 'meta' to avoid NULL pointer > dereference. The patch brings three changes: > > 1. Add checks in both kfence_free() and __kfence_free(); > 2. kfence_free is not inline function any longer and new inline > function '__try_free_kfence_meta' is introduced. This is very bad for performance (see below). > 3. The check of is_kfence_address() is not required for > __kfence_free() now because __kfence_free has done the check in > addr_to_metadata(); > > Reported-by: Zeal Robot Is this a static analysis robot? Please show a real stack trace with an actual NULL-deref. Nack - please see: https://lore.kernel.org/all/CANpmjNO5-o1B9r2eYS_482RBVJSyPoHSnV2t+M8fJdFzBf6d2A@mail.gmail.com/ > Signed-off-by: xu xin > --- > include/linux/kfence.h | 10 ++-------- > mm/kfence/core.c | 30 +++++++++++++++++++++++++++--- > 2 files changed, 29 insertions(+), 11 deletions(-) > > diff --git a/include/linux/kfence.h b/include/linux/kfence.h > index 726857a4b680..fbf6391ab53c 100644 > --- a/include/linux/kfence.h > +++ b/include/linux/kfence.h > @@ -160,7 +160,7 @@ void *kfence_object_start(const void *addr); > * __kfence_free() - release a KFENCE heap object to KFENCE pool > * @addr: object to be freed > * > - * Requires: is_kfence_address(addr) > + * Requires: is_kfence_address(addr), but now it's unnecessary (As an aside, something can't be required and be unnecessary at the same time.) There's a reason it was designed this way - is_kfence_address() is much cheaper than a full call. > * Release a KFENCE object and mark it as freed. > */ > @@ -179,13 +179,7 @@ void __kfence_free(void *addr); > * allocator's free codepath. The allocator must check the return value to > * determine if it was a KFENCE object or not. > */ > -static __always_inline __must_check bool kfence_free(void *addr) > -{ > - if (!is_kfence_address(addr)) > - return false; > - __kfence_free(addr); > - return true; > -} > +bool __must_check kfence_free(void *addr); There's a reason is_kfence_address() is inline here, because this function is actually called in relatively hot paths, and a simple load+cmp is much cheaper than a call! > /** > * kfence_handle_page_fault() - perform page fault handling for KFENCE pages > diff --git a/mm/kfence/core.c b/mm/kfence/core.c > index 6e69986c3f0d..1405585369b3 100644 > --- a/mm/kfence/core.c > +++ b/mm/kfence/core.c > @@ -1048,10 +1048,10 @@ void *kfence_object_start(const void *addr) > return meta ? (void *)meta->addr : NULL; > } > > -void __kfence_free(void *addr) > -{ > - struct kfence_metadata *meta = addr_to_metadata((unsigned long)addr); > > +/* Require: meta is not NULL*/ > +static __always_inline void __try_free_kfence_meta(struct kfence_metadata *meta) > +{ > #ifdef CONFIG_MEMCG > KFENCE_WARN_ON(meta->objcg); > #endif > @@ -1067,6 +1067,30 @@ void __kfence_free(void *addr) > kfence_guarded_free(addr, meta, false); > } > > +void __kfence_free(void *addr) > +{ > + struct kfence_metadata *meta = addr_to_metadata((unsigned long)addr); > + > + if (!meta) { > + kfence_report_error(addr, false, NULL, NULL, KFENCE_ERROR_INVALID); > + return; > + } > + > + __try_free_kfence_meta(meta); > +} > + > +bool __must_check kfence_free(void *addr) > +{ > + struct kfence_metadata *meta = addr_to_metadata((unsigned long)addr); > + > + if (!meta) > + return false; > + > + __try_free_kfence_meta(meta); > + > + return true; > +} > + > bool kfence_handle_page_fault(unsigned long addr, bool is_write, struct pt_regs *regs) > { > const int page_index = (addr - (unsigned long)__kfence_pool) / PAGE_SIZE; > -- > 2.25.1 >