From patchwork Fri May 20 22:22:48 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Eric W. Biederman" X-Patchwork-Id: 624650 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3rBN565MhYz9t5x for ; Sat, 21 May 2016 08:33:46 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751065AbcETWdo (ORCPT ); Fri, 20 May 2016 18:33:44 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:39644 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750782AbcETWdn (ORCPT ); Fri, 20 May 2016 18:33:43 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1b3szF-0002FV-E3; Fri, 20 May 2016 16:33:41 -0600 Received: from 97-119-107-188.omah.qwest.net ([97.119.107.188] helo=x220.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.87) (envelope-from ) id 1b3szD-0001hK-GL; Fri, 20 May 2016 16:33:41 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Hannes Frederic Sowa Cc: Daniel Borkmann , Alexei Starovoitov , "David S. Miller" , netdev@vger.kernel.org References: <87oa84wa6h.fsf@x220.int.ebiederm.org> <79e26212-3b09-1be3-0fbf-30de1b265045@stressinduktion.org> <87inybv2hv.fsf@x220.int.ebiederm.org> <573CD3D8.3030308@iogearbox.net> Date: Fri, 20 May 2016 17:22:48 -0500 In-Reply-To: (Hannes Frederic Sowa's message of "Wed, 18 May 2016 22:46:57 +0200") Message-ID: <874m9sfjyf.fsf_-_@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 X-XM-AID: U2FsdGVkX1/XZD/eyCgNd9DeZY4mos5dEvBdD4fiKGk= X-SA-Exim-Connect-IP: 97.119.107.188 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on sa04.xmission.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,TVD_RCVD_IP,T_TM2_M_HEADER_IN_MSG,XMSubLong autolearn=disabled version=3.4.0 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Hannes Frederic Sowa X-Spam-Relay-Country: X-Spam-Timing: total 1029 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 5 (0.5%), b_tie_ro: 3.6 (0.3%), parse: 1.24 (0.1%), extract_message_metadata: 23 (2.2%), get_uri_detail_list: 2.8 (0.3%), tests_pri_-1000: 7 (0.7%), tests_pri_-950: 1.11 (0.1%), tests_pri_-900: 0.89 (0.1%), tests_pri_-400: 22 (2.1%), check_bayes: 21 (2.0%), b_tokenize: 5 (0.5%), b_tok_get_all: 7 (0.7%), b_comp_prob: 1.90 (0.2%), b_tok_touch_all: 3.9 (0.4%), b_finish: 0.74 (0.1%), tests_pri_0: 444 (43.2%), check_dkim_signature: 0.45 (0.0%), check_dkim_adsp: 111 (10.8%), tests_pri_500: 521 (50.7%), poll_dns_idle: 513 (49.9%), rewrite_mail: 0.00 (0.0%) Subject: [PATCH net] bpf: Use mount_nodev not mount_ns to mount the bpf filesystem X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org While reviewing the filesystems that set FS_USERNS_MOUNT I spotted the bpf filesystem. Looking at the code I saw a broken usage of mount_ns with current->nsproxy->mnt_ns. As the code does not acquire a reference to the mount namespace it can not possibly be correct to store the mount namespace on the superblock as it does. Replace mount_ns with mount_nodev so that each mount of the bpf filesystem returns a distinct instance, and the code is not buggy. In discussion with Hannes Frederic Sowa it was reported that the use of mount_ns was an attempt to have one bpf instance per mount namespace, in an attempt to keep resources that pin resources from hiding. That intent simply does not work, the vfs is not built to allow that kind of behavior. Which means that the bpf filesystem really is buggy both semantically and in it's implemenation as it does not nor can it implement the original intent. This change is userspace visible, but my experience with similar filesystems leads me to believe nothing will break with a model of each mount of the bpf filesystem is distinct from all others. Fixes: b2197755b263 ("bpf: add support for persistent maps/progs") Cc: Hannes Frederic Sowa Acked-by: Daniel Borkmann Signed-off-by: "Eric W. Biederman" Acked-by: Hannes Frederic Sowa --- kernel/bpf/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/bpf/inode.c b/kernel/bpf/inode.c index 8f94ca1860cf..55d923688f85 100644 --- a/kernel/bpf/inode.c +++ b/kernel/bpf/inode.c @@ -378,7 +378,7 @@ static int bpf_fill_super(struct super_block *sb, void *data, int silent) static struct dentry *bpf_mount(struct file_system_type *type, int flags, const char *dev_name, void *data) { - return mount_ns(type, flags, current->nsproxy->mnt_ns, bpf_fill_super); + return mount_nodev(type, flags, data, bpf_fill_super); } static struct file_system_type bpf_fs_type = {