This is a note to let you know that I've just added the patch titled userns: Rename id_map_mutex to userns_state_mutex to the 3.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: userns-rename-id_map_mutex-to-userns_state_mutex.patch and it can be found in the queue-3.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable@xxxxxxxxxxxxxxx> know about it. >From f0d62aec931e4ae3333c797d346dc4f188f454ba Mon Sep 17 00:00:00 2001 From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> Date: Tue, 9 Dec 2014 14:03:14 -0600 Subject: userns: Rename id_map_mutex to userns_state_mutex From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> commit f0d62aec931e4ae3333c797d346dc4f188f454ba upstream. Generalize id_map_mutex so it can be used for more state of a user namespace. Reviewed-by: Andy Lutomirski <luto@xxxxxxxxxxxxxx> Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> --- kernel/user_namespace.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) --- a/kernel/user_namespace.c +++ b/kernel/user_namespace.c @@ -24,6 +24,7 @@ #include <linux/fs_struct.h> static struct kmem_cache *user_ns_cachep __read_mostly; +static DEFINE_MUTEX(userns_state_mutex); static bool new_idmap_permitted(const struct file *file, struct user_namespace *ns, int cap_setid, @@ -581,9 +582,6 @@ static bool mappings_overlap(struct uid_ return false; } - -static DEFINE_MUTEX(id_map_mutex); - static ssize_t map_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos, int cap_setid, @@ -600,7 +598,7 @@ static ssize_t map_write(struct file *fi ssize_t ret = -EINVAL; /* - * The id_map_mutex serializes all writes to any given map. + * The userns_state_mutex serializes all writes to any given map. * * Any map is only ever written once. * @@ -618,7 +616,7 @@ static ssize_t map_write(struct file *fi * order and smp_rmb() is guaranteed that we don't have crazy * architectures returning stale data. */ - mutex_lock(&id_map_mutex); + mutex_lock(&userns_state_mutex); ret = -EPERM; /* Only allow one successful write to the map */ @@ -745,7 +743,7 @@ static ssize_t map_write(struct file *fi *ppos = count; ret = count; out: - mutex_unlock(&id_map_mutex); + mutex_unlock(&userns_state_mutex); if (page) free_page(page); return ret; @@ -837,12 +835,12 @@ bool userns_may_setgroups(const struct u { bool allowed; - mutex_lock(&id_map_mutex); + mutex_lock(&userns_state_mutex); /* It is not safe to use setgroups until a gid mapping in * the user namespace has been established. */ allowed = ns->gid_map.nr_extents != 0; - mutex_unlock(&id_map_mutex); + mutex_unlock(&userns_state_mutex); return allowed; } Patches currently in stable-queue which might be from ebiederm@xxxxxxxxxxxx are queue-3.14/mnt-update-unprivileged-remount-test.patch queue-3.14/mnt-fix-a-memory-stomp-in-umount.patch queue-3.14/userns-check-euid-no-fsuid-when-establishing-an-unprivileged-uid-mapping.patch queue-3.14/mnt-implicitly-add-mnt_nodev-on-remount-when-it-was-implicitly-added-by-mount.patch queue-3.14/userns-don-t-allow-unprivileged-creation-of-gid-mappings.patch queue-3.14/userns-rename-id_map_mutex-to-userns_state_mutex.patch queue-3.14/userns-add-a-knob-to-disable-setgroups-on-a-per-user-namespace-basis.patch queue-3.14/userns-allow-setting-gid_maps-without-privilege-when-setgroups-is-disabled.patch queue-3.14/userns-don-t-allow-setgroups-until-a-gid-mapping-has-been-setablished.patch queue-3.14/groups-consolidate-the-setgroups-permission-checks.patch queue-3.14/userns-only-allow-the-creator-of-the-userns-unprivileged-mappings.patch queue-3.14/userns-document-what-the-invariant-required-for-safe-unprivileged-mappings.patch queue-3.14/umount-disallow-unprivileged-mount-force.patch queue-3.14/userns-unbreak-the-unprivileged-remount-tests.patch -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html