Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5136409yba; Wed, 10 Apr 2019 12:09:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqxlkFYpmvIFDJCgD1Z/WDay8nPnXu3CCojfQ85QWnIDSNgqwHIW/hGSY273pUOAlamfe2Re X-Received: by 2002:a63:100e:: with SMTP id f14mr9783494pgl.192.1554923380506; Wed, 10 Apr 2019 12:09:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554923380; cv=none; d=google.com; s=arc-20160816; b=YOkB3HaFLiAVumGzdWd1CqBZEWkgUwLfA+zXd1CKGfTq/PMXoZeW/XIJDNo15I3oPR 9aYy2LuIEQVuZDfRoZYufoiOgxl6w4eeItU+FtHIKvbhW/1f8tE5Ndax9OTuY6RlFFZ0 a70/bVjJArN/QugEGr1Lxq2z3qHIa8yAUiaCbBl+T6RfQfFWM7B6VLAy4YEzFgurBHtO Iz3gwsTxbldemel5Jm4xob3toDYnrTiM+Dd0VcFSdH001rfURyeCXUcq63d2JtN2wNM0 KGuVJpg6F0mWnSZUbGZBrYhgmeVdFa+mpOobTLQEY4Wm3NEq1sCt92IdBo6LubgrOiP5 Yifw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=085rd0Mgc0sODbokeBPYQRzHa85LLJfsDNyGADXV+hw=; b=RQGA0/h2n+6KOOvtl7g9Zeca0P5d/2Qaay9OxmopyVx9FacZAkAcs+IiGGxWKXK27L JETZLciEqs6BWOkZW+dHa85HrX1W1CtmcBfhOlBcfk3CFGv+0KQ8u5jZwaomrN3t7Aoo sZ44rF/0W2o0oWJdh/7b1j2NToZ2bjhR9BnJd5k15YTZ5xvSoNhWLy9aoaC2GNXwqV/i G7GY6hwpqVWquKOnJoZMqrdC3WrWjNved3xHwDM+VZw7LerQ0pV48CephbASdXqZVUji XgR7ZBBVwAHcvXGXXoKbU8lFK7VTSUysF2wWfcK4cwZqqN66umXTR+znPTpe9AS+PAwh V0Wg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z23si33201010plo.40.2019.04.10.12.09.24; Wed, 10 Apr 2019 12:09:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731078AbfDJSCL (ORCPT + 99 others); Wed, 10 Apr 2019 14:02:11 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:40800 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728749AbfDJSCK (ORCPT ); Wed, 10 Apr 2019 14:02:10 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92 #3 (Red Hat Linux)) id 1hEHXp-0008Fj-1d; Wed, 10 Apr 2019 18:01:57 +0000 Date: Wed, 10 Apr 2019 19:01:57 +0100 From: Al Viro To: James Morris Cc: Kangjie Lu , pakki001@umn.edu, "Serge E. Hallyn" , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] security: inode: fix a missing check for securityfs_create_file Message-ID: <20190410180156.GZ2217@ZenIV.linux.org.uk> References: <20190315210025.17832-1-kjlu@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 11, 2019 at 03:34:43AM +1000, James Morris wrote: > On Fri, 15 Mar 2019, Kangjie Lu wrote: > > > securityfs_create_file may fail. The fix checks its status and > > returns the error code upstream if it fails. > > > > Signed-off-by: Kangjie Lu > > > > Applied to > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general > > > --- > > Return the exact error code upstream. > > --- > > security/inode.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/security/inode.c b/security/inode.c > > index b7772a9b315e..667f8b15027d 100644 > > --- a/security/inode.c > > +++ b/security/inode.c > > @@ -339,6 +339,11 @@ static int __init securityfs_init(void) > > #ifdef CONFIG_SECURITY > > lsm_dentry = securityfs_create_file("lsm", 0444, NULL, NULL, > > &lsm_ops); > > + if (IS_ERR(lsm_dentry)) { > > + unregister_filesystem(&fs_type); > > + sysfs_remove_mount_point(kernel_kobj, "security"); > > + return PTR_ERR(lsm_dentry); > > + } Rather bad way to do it - generally, register_filesystem() should be the last thing done by initialization. Any modular code that does unregister_filesystem() on failure exit is flat-out broken; here it's not instantly FUBAR, but it's a bloody bad example. What's more, why not let simple_fill_super() do it? Just static int fill_super(struct super_block *sb, void *data, int silent) { static const struct tree_descr files[] = { #ifdef CONFIG_SECURITY {"lsm", &lsm_ops, 0444}, #endif {""} }; and to hell with that call of securityfs_create_file() and all its failure handling...