Received: by 2002:ac2:464d:0:0:0:0:0 with SMTP id s13csp191548lfo; Tue, 17 May 2022 21:53:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwzfd/QHFdFCGgZhMeWJ0+IdBhxUMgMvTe2OtFCkUrtNJ+wcMXyteSieRbvQsei8iSDyrjb X-Received: by 2002:a17:902:d507:b0:15e:afc4:85b5 with SMTP id b7-20020a170902d50700b0015eafc485b5mr25611508plg.52.1652849599758; Tue, 17 May 2022 21:53:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652849599; cv=none; d=google.com; s=arc-20160816; b=Dvrk70/fF2lTOMpIrTCjAjZUvpLmW343Tqv+4fJageTKA7cDrpSPHeZ7oWizUXIbh9 gUD6SoAOlQStzGLbchjiPaYikHX8MQbBq2IVzd3jwxzKVgKtPv9NXVoD/XevP5WPn5eM ep4pYFU8nn66Vro7nEgbJ2th11NrzBu0u2fXNcJ7iKrSbFjeu5FmWTnB4hIWr3bv2jw6 aEswGgsF/JNkHnsNlV6uUpVyQOptP9sWfQ7LcfzexnZijLs0V3k1FoO4skcv1cbWm3Bv nBYQCwu7lAM5Zqm4tlj5LWrzhxafAxAlkx9DuZo6XjiUIj4MUO2466rDLURS2BRiMewJ RtNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=3MN9R0ncE8uUAxzrbD9D9kHBacmiEBQxp8Szamm8Dr4=; b=b7c03gLhkC0HygjNgDrdcxeGbxiJZI21DWm1dG4JjMeadNjihvOyTyzQBn7OBFCaKX Fg7I3ZsRu7R3It5iYAzagPrfJGhMGqOldhO/Jtnf68KvC5heMiS+P/TMLOuLwInCP85m S7TbXxlYATdPNS/RZSaKaE+7JCf8Pc5NFeQrGyIdV8wevv43N/5JuGIB2ibviwTi6w+U wEdAaTL4W2qB6eZBoTX4eVz2or1KgHkStrTy8f6iThTfGLm7kRwh4cEhl1LK4cLn5SSK W7Xn9lSkW9WZWMvhhRWw+Fe/EuuGDjVp/Hfglwo2nsI6Sz9WleuyvvSmtejQ+KYnACPp 32lA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.org.uk header.s=zeniv-20220401 header.b=pWFJRn3N; 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=NONE sp=NONE dis=NONE) header.from=zeniv.linux.org.uk Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id z7-20020a170902834700b0015f1b3ab3a7si1413133pln.79.2022.05.17.21.53.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 May 2022 21:53:19 -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=@linux.org.uk header.s=zeniv-20220401 header.b=pWFJRn3N; 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=NONE sp=NONE dis=NONE) header.from=zeniv.linux.org.uk Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4978313C1E1; Tue, 17 May 2022 21:02:42 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229560AbiEQVoF (ORCPT + 99 others); Tue, 17 May 2022 17:44:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbiEQVnu (ORCPT ); Tue, 17 May 2022 17:43:50 -0400 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AAF1F50441; Tue, 17 May 2022 14:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=3MN9R0ncE8uUAxzrbD9D9kHBacmiEBQxp8Szamm8Dr4=; b=pWFJRn3NyAvA7NK+RkLv0kJiJs VBDQ6yEpt4u26gcaTk1U+5+K+FS8UZ8Voegl441DMsSZd1IY56qTPhXIaXeZ6I71rJH4jaKD93DiZ 9Nx1X9TxTEwJ7ZAZQsD+l8bA2AZeTjy5ywW811CBhaiTqo/9rjnlGr8aoR86lAeBKYOC8te19VqNO zMtRn1TL8STcuT/cym0BXOz//P3q0x4JRwpuzhuGn/veX7GUSCr+wD3ajPINs9BcYQgWHr+wXZ8fu jiCNIyE+PYhgokvcfbFabgyXuX3ws3CCMtR9PTDJP16HSHBWJVVXPGzWBkPFi/ssLdOYET7Rvz+9l Zihc79yw==; Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nr4yg-00FqGx-3D; Tue, 17 May 2022 21:43:38 +0000 Date: Tue, 17 May 2022 21:43:38 +0000 From: Al Viro To: Yongzhi Liu Cc: serge@hallyn.com, jmorris@namei.org, dhowells@redhat.com, ebiederm@xmission.com, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] commoncap: check return value to avoid null pointer dereference Message-ID: References: <1652722802-66170-1-git-send-email-lyz_cs@pku.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1652722802-66170-1-git-send-email-lyz_cs@pku.edu.cn> Sender: Al Viro X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE 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 Mon, May 16, 2022 at 10:40:02AM -0700, Yongzhi Liu wrote: > The pointer inode is dereferenced before a null pointer > check on inode, hence if inode is actually null we will > get a null pointer dereference. Fix this by only dereferencing > inode after the null pointer check on inode. > > Fixes: c6f493d631c ("VFS: security/: d_backing_inode() annotations") > Fixes: 8db6c34 ("Introduce v3 namespaced file capabilities") > > Signed-off-by: Yongzhi Liu > --- > security/commoncap.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/security/commoncap.c b/security/commoncap.c > index 5fc8986..978f011 100644 > --- a/security/commoncap.c > +++ b/security/commoncap.c > @@ -298,6 +298,8 @@ int cap_inode_need_killpriv(struct dentry *dentry) > struct inode *inode = d_backing_inode(dentry); > int error; > > + if (!inode) > + return 0; > error = __vfs_getxattr(dentry, inode, XATTR_NAME_CAPS, NULL, 0); > return error > 0; > } Huh? AFAICS, that has all of two callers - notify_change() and dentry_needs_remove_privs(). Both of them should never be called on negative dentries and both would have blown up well before the call of security_inode_need_killpriv(). > @@ -545,11 +547,13 @@ int cap_convert_nscap(struct user_namespace *mnt_userns, struct dentry *dentry, > const struct vfs_cap_data *cap = *ivalue; > __u32 magic, nsmagic; > struct inode *inode = d_backing_inode(dentry); > - struct user_namespace *task_ns = current_user_ns(), > - *fs_ns = inode->i_sb->s_user_ns; > + struct user_namespace *task_ns = current_user_ns(), *fs_ns; > kuid_t rootid; > size_t newsize; > > + if (!inode) > + return -EINVAL; > + fs_ns = inode->i_sb->s_user_ns; > if (!*ivalue) > return -EINVAL; > if (!validheader(size, cap)) ... and that one come from vfs_setxattr(). Again, calling that on a negative dentry is an oopsable bug. If you have any reproducers, please post the stack traces so it would be possible to deal with the underlying problem.