From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752849AbbHESUA (ORCPT ); Wed, 5 Aug 2015 14:20:00 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:40769 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751861AbbHEST6 (ORCPT ); Wed, 5 Aug 2015 14:19:58 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Kees Cook Cc: Ricky Zhou , Oleg Nesterov , David Howells , LKML , Andrew Morton , Peter Zijlstra , Ingo Molnar , "Kirill A. Shutemov" , Rik van Riel , Vladimir Davydov , Julien Tinnes References: <20150728171500.GA2871@www.outflux.net> <87d1zcm9iz.fsf@x220.int.ebiederm.org> Date: Wed, 05 Aug 2015 13:13:15 -0500 In-Reply-To: (Kees Cook's message of "Tue, 28 Jul 2015 14:01:58 -0700") Message-ID: <878u9psix0.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX18mKY4vccAJRvLBVIxbFAzahhVdshUaPhM= X-SA-Exim-Connect-IP: 97.119.22.40 X-SA-Exim-Mail-From: ebiederm@xmission.com 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 * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Kees Cook X-Spam-Relay-Country: X-Spam-Timing: total 375 ms - load_scoreonly_sql: 0.07 (0.0%), signal_user_changed: 4.0 (1.1%), b_tie_ro: 2.7 (0.7%), parse: 0.76 (0.2%), extract_message_metadata: 18 (4.8%), get_uri_detail_list: 2.2 (0.6%), tests_pri_-1000: 8 (2.1%), tests_pri_-950: 1.37 (0.4%), tests_pri_-900: 1.10 (0.3%), tests_pri_-400: 27 (7.1%), check_bayes: 25 (6.7%), b_tokenize: 8 (2.1%), b_tok_get_all: 9 (2.4%), b_comp_prob: 2.6 (0.7%), b_tok_touch_all: 3.0 (0.8%), b_finish: 0.82 (0.2%), tests_pri_0: 306 (81.6%), tests_pri_500: 6 (1.5%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] user_ns: use correct check for single-threadedness X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Kees Cook writes: > On Tue, Jul 28, 2015 at 1:55 PM, Ricky Zhou wrote: >> On Tue, Jul 28, 2015 at 11:17 AM, Eric W. Biederman >> wrote: >>> Kees Cook writes: >>> >>>> From: Ricky Zhou >>>> >>>> Checking mm_users > 1 does not mean a process is multithreaded. For >>>> example, reading /proc/PID/maps temporarily increments mm_users, allowing >>>> other processes to (accidentally) interfere with unshare() calls. >>>> >>>> This fixes observed failures of unshare(CLONE_NEWUSER) incorrectly >>>> returning EINVAL if another processes happened to be simultaneously >>>> reading the maps file. >>>> >>>> Signed-off-by: Ricky Zhou >>>> Signed-off-by: Kees Cook >>>> Cc: stable@vger.kernel.org >>> >>> This looks like a good fix. Any chance you can drudge up the commit where >>> this hack came in so that Greg & Company know how far to back port this? >> >> userns_install in user_namespace.c (affects setns of a user >> namespace): cde1975bc242f3e1072bde623ef378e547b73f91. >> >> The check in check_unshare_flags is a little more complex. The >> incorrect check was added in >> cf2e340f4249b781b3d2beb41e891d08581f0e10 but I don't think it would >> have triggered under any supported combination of flags at that point. >> >> From 50804fe3737ca6a5942fdc2057a18a8141d00141 until >> 6e556ce209b09528dbf1931cbfd5d323e1345926, the bug affected >> unshare(CLONE_NEWPID). > > That's back to v3.8, so this goes quite a way, it seems. This patch was marked as CC' stable. The question I am asking is this problem bad enough that backporting this change to stable makes sense? And even more if this patch can wait for the merge window to be merged or if there this needs to be expidited, and get in before 4.2 -final. It sounds like this is one of those rare bugs someone hit once or twice, just often enough for this to be tracked down, and the important thing is that this fix get into the kernel's code base. So unless I am otherwise informed I will assume that this is a change that can stand to wait until the merge window to be merged (so it has a full development cycle of review and discussion). But that is worth backporting after that because it actually causes problems that people actually hit. Eric