diff options
author | Eric W. Biederman <ebiederm@xmission.com> | 2016-12-14 13:24:51 +0100 |
---|---|---|
committer | Sasha Levin <alexander.levin@verizon.com> | 2016-12-23 08:56:35 -0500 |
commit | 1171afc4a34e2926e6e8e27c896cf328c8825ac3 (patch) | |
tree | 16c6e981770b3e664fcc5c5c1bd341bced63b3e5 /kernel | |
parent | 62fa696b7b435e93ed114dd6a23aa0881d7f81b9 (diff) |
mnt: Add a per mount namespace limit on the number of mounts
[ Upstream commit d29216842a85c7970c536108e093963f02714498 ]
CAI Qian <caiqian@redhat.com> pointed out that the semantics
of shared subtrees make it possible to create an exponentially
increasing number of mounts in a mount namespace.
mkdir /tmp/1 /tmp/2
mount --make-rshared /
for i in $(seq 1 20) ; do mount --bind /tmp/1 /tmp/2 ; done
Will create create 2^20 or 1048576 mounts, which is a practical problem
as some people have managed to hit this by accident.
As such CVE-2016-6213 was assigned.
Ian Kent <raven@themaw.net> described the situation for autofs users
as follows:
> The number of mounts for direct mount maps is usually not very large because of
> the way they are implemented, large direct mount maps can have performance
> problems. There can be anywhere from a few (likely case a few hundred) to less
> than 10000, plus mounts that have been triggered and not yet expired.
>
> Indirect mounts have one autofs mount at the root plus the number of mounts that
> have been triggered and not yet expired.
>
> The number of autofs indirect map entries can range from a few to the common
> case of several thousand and in rare cases up to between 30000 and 50000. I've
> not heard of people with maps larger than 50000 entries.
>
> The larger the number of map entries the greater the possibility for a large
> number of active mounts so it's not hard to expect cases of a 1000 or somewhat
> more active mounts.
So I am setting the default number of mounts allowed per mount
namespace at 100,000. This is more than enough for any use case I
know of, but small enough to quickly stop an exponential increase
in mounts. Which should be perfect to catch misconfigurations and
malfunctioning programs.
For anyone who needs a higher limit this can be changed by writing
to the new /proc/sys/fs/mount-max sysctl.
Tested-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Conflicts:
fs/namespace.c
kernel/sysctl.c
Signed-off-by: Philipp Hahn <hahn@univention.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Diffstat (limited to 'kernel')
-rw-r--r-- | kernel/sysctl.c | 9 |
1 files changed, 9 insertions, 0 deletions
diff --git a/kernel/sysctl.c b/kernel/sysctl.c index 7d4900404c94..cebbff5f34fe 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -64,6 +64,7 @@ #include <linux/binfmts.h> #include <linux/sched/sysctl.h> #include <linux/kexec.h> +#include <linux/mount.h> #include <asm/uaccess.h> #include <asm/processor.h> @@ -1709,6 +1710,14 @@ static struct ctl_table fs_table[] = { .mode = 0644, .proc_handler = proc_doulongvec_minmax, }, + { + .procname = "mount-max", + .data = &sysctl_mount_max, + .maxlen = sizeof(unsigned int), + .mode = 0644, + .proc_handler = proc_dointvec_minmax, + .extra1 = &one, + }, { } }; |