lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <79e26212-3b09-1be3-0fbf-30de1b265045@stressinduktion.org>
Date:	Wed, 18 May 2016 12:48:27 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Daniel Borkmann <daniel@...earbox.net>
Cc:	Alexei Starovoitov <ast@...nel.org>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [RFC][PATCH net] bpf: Use mount_nodev not mount_ns to mount the
 bpf filesystem

On 18.05.2016 01:12, 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 utterly
> broken.
> 
> Fixes: b2197755b263 ("bpf: add support for persistent maps/progs")
> Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.com>
> ---
> 
> No one should care about this change, as userspace typically only mounts
> things once and does not depend on things in one mount do not showing up
> in another.  Can someone who actually uses the bpf filesystem please
> verify this.
> 
> This needs to be fixed as the existing code is broken beyond words that
> I know how to express.

The idea is to have the bpf filesystem as a singeleton per mnt-namespace
to prevent endless instances being created and kernel resources being
hogged by pinning them to hard to discover bpf mounts.

Do you see any problem with adding appropriate reference counts?

Bye,
Hannes

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ