Message ID | 874m9sfjyf.fsf_-_@x220.int.ebiederm.org |
---|---|
State | Accepted, archived |
Delegated to: | David Miller |
Headers | show |
On 21.05.2016 00:22, Eric W. Biederman wrote: > > 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 <hannes@stressinduktion.org> > Acked-by: Daniel Borkmann <daniel@iogearbox.net> > Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Thanks Eric!
From: ebiederm@xmission.com (Eric W. Biederman) Date: Fri, 20 May 2016 17:22:48 -0500 > > 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 <hannes@stressinduktion.org> > Acked-by: Daniel Borkmann <daniel@iogearbox.net> > Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Applied and queued up for -stable, thanks everyone.
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 = {