From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DEB3E20010C for ; Sat, 7 Feb 2026 23:06:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770505590; cv=none; b=FAgODIX+oZSWIOHaL+w3ykTEh2zjiIGDBgdU6x6YjOZw0KgDXGwx5QCE8SD8ojoSS1viBz7CATjRpN1bXeI4C0PqCMzbzTR5yliYlk4/miLdMIX33dB4urxuQ0SgpIyi4/rtqaZ97I49hrlokXe9RnhJ9thBdJGqn3WdVonCQ+U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770505590; c=relaxed/simple; bh=YrgypsXzAoSsRO2hW4cxzJfApzUgTJCsmqDOoFH1Hkc=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=L9huQg1OC2G/0nsgdl3p73JaZFniz83zzMcwTHwaEb07m6/07DxsziTx1BqrYXG3UPthx3GNFdw9W42ljdyFAMt39P9WhNxXbXWyJfyETq5Nyu0wuMh8L8i2P2CrpiRJUU1Y86YmUnx1tAt3kh9z5niPQL0U5OzX0RGeX/IH7xo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=afcKPA2i; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=DrnHRWao; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="afcKPA2i"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="DrnHRWao" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770505588; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HjFu2j4cSqbQw4phkd9l7dLJra+Vd47iY+6CBQEX8r0=; b=afcKPA2iH/foYnURisx2Nt61YNeMuuFPDBsII2En9H1m1LY9oSIw55g35AGSx3YyxJEjHE rgkKX/9taKIiXm23DuxpO6uyfKEwXdvQFAK4d6IYuhRPbAnj2at0Tg0oZiNO/3rQweJbTk 0hDE2DH+WbH5YLIbRwcAN4w+9QqZ0/M= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-611-73aKbK3FOqWIX-ed2p7zkQ-1; Sat, 07 Feb 2026 18:06:27 -0500 X-MC-Unique: 73aKbK3FOqWIX-ed2p7zkQ-1 X-Mimecast-MFC-AGG-ID: 73aKbK3FOqWIX-ed2p7zkQ_1770505587 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-8c6ae763d03so358481585a.3 for ; Sat, 07 Feb 2026 15:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770505587; x=1771110387; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:from:to :cc:subject:date:message-id:reply-to; bh=HjFu2j4cSqbQw4phkd9l7dLJra+Vd47iY+6CBQEX8r0=; b=DrnHRWaozYBiApFIUJUiPJwsRLs9+/cKsyx49trmCjkzenq7VkQbkKOFN2aGCWu8w+ kzm1OODfNlvjBl5PvzZvRhyhIx4vj4JkErBewiFwG3XKU7Peyi70a/FoP2tS0qWzpP2L 9UUwNTo5d77TorTylMT5FEOpO4u5HVoZUkv0Fllz2N5IgFi5uaea5qDYVvwYsStmHpaJ A8RLJ7Yub0veqyxIHVUEulOQzTC+1pLTmMArvilMu2RemcOLU1L2nIEPnn++71LfORHU u/Uc+O3aSRwFbHgyKX5n0neQdX+gqCbs4WlrpRKJnRSIljoUMaA+wVsA6K5ppypS6UBT Kypw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770505587; x=1771110387; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HjFu2j4cSqbQw4phkd9l7dLJra+Vd47iY+6CBQEX8r0=; b=P05p+O4Pk2HsLEpFilgbu8fRjlX8kbF8IT6p3F/jlDyxNiB7uc8oJzCEKz8z6chU6n LvumOoQn5wgr6xmC8IBACpKTZjDc9eo/Pcuc8GeZZ9Umdrtyi2iEBWxjA/843CTgRcRw GwVDqu5H7sKYQvN/WFRzVll16ZoYlb1KRRfuzYfK9TU4mrkX5bYTWMIy+2Nph1Rc8YyJ x4e24qeXhtTgewt3qQcghnEWfMT5ugb7JjvFYoQobHzq9cNoz0rx7k4M1Y6MdJm9IApZ me/3swOjPvmM0i9LsH44HDT6Ty1DYZG8GudCF+/Oxig+mbl52ycjbAck97K+UCLii9Cb 6NOQ== X-Forwarded-Encrypted: i=1; AJvYcCVhJSVFAXzD83sZzhsLD6sEfW3Se2R9hg2485DrhX8/Z4P4E5aN0YJ8KFqLWmIceDZQ091xin0Fgv9OAlI=@vger.kernel.org X-Gm-Message-State: AOJu0YwvWcHQczZlVqnCBI7eEMhGCducAZh6XctQoZlftX3Yl3tc6NAM 7iypGSi3deqtvg84nNPbG9QubgdEbyhaEpyAdLY3ZczP7RFrzy79vOeItC6cMi8/0XO+tkn8gKT VovOTFEp+dZ3lQlGPt3dCpqSmqlbJ1ONAfvnRo6k4Uk8kEVDQm12c63NAAOTAyq8Z0g== X-Gm-Gg: AZuq6aLDCqN+cEDFSgwAfHKKQQgULpW7lvW5xnlEoC7LyqSAsHEAsFLRshOrkdmOBU+ sOffsH5GfjhDqEza8+ekx9OjTvBRBrAMIcdYW141SO05mGbAq5n2bzGzkiu/sAnfzAt7FXK+9zy V/5wHCKmscyhuX0jfa62/tA1LXVCOrP1F0tObiFXZtwMHucmkdlo/nlY5OLDnNhiuXFen5uyvdJ 2m45ophIlCbZUKe5/U/BnNdI53S6J1lra9/VOwoOZEJdMyebqS2rNmgdi7x92033Md39He6hQvB IgoVPcY5PCROY+YnKkXHXCT5xbjBCOywqPh0TbXAvtVYQbRHS/RDaHxD+18hirVyDpoiduE2OWj yBUdAO8pknhEADNtaA4ub0/iHrWe/deNBs+0cDnE8B+nKHbYtcr02hpTU X-Received: by 2002:a05:620a:7081:b0:8c3:7e51:94c6 with SMTP id af79cd13be357-8caf0f2c066mr882533985a.60.1770505587015; Sat, 07 Feb 2026 15:06:27 -0800 (PST) X-Received: by 2002:a05:620a:7081:b0:8c3:7e51:94c6 with SMTP id af79cd13be357-8caf0f2c066mr882532885a.60.1770505586595; Sat, 07 Feb 2026 15:06:26 -0800 (PST) Received: from ?IPV6:2601:188:c102:b180:1f8b:71d0:77b1:1f6e? ([2601:188:c102:b180:1f8b:71d0:77b1:1f6e]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8caf79f7dc3sm478722385a.13.2026.02.07.15.06.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Feb 2026 15:06:25 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: Date: Sat, 7 Feb 2026 18:06:24 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH][RFC] bug in unshare(2) failure recovery To: Al Viro , Linus Torvalds Cc: Paul Moore , Eric Paris , Christian Brauner , linux-kernel@vger.kernel.org, audit@vger.kernel.org, Richard Guy Briggs , Ricardo Robaina , Waiman Long References: <46d5c480-87d0-4f6a-bcc2-6c936c87e216@redhat.com> <20260204201815.GP3183987@ZenIV> <50054d23-0a89-41ec-b28b-b1ed77d93b00@redhat.com> <20260205235351.GU3183987@ZenIV> <8a456257-6f7e-4d0a-b38d-3c2aefee76bb@redhat.com> <3a5f84fc-5c4e-4ce1-b2dd-6e07b109ce78@redhat.com> <20260206052218.GV3183987@ZenIV> <9bc83901-3819-4cf1-a1ba-cc2f52f53504@redhat.com> <5cb07c57-9dca-4086-af88-f866f765c7fb@redhat.com> <20260207082524.GE3183987@ZenIV> Content-Language: en-US In-Reply-To: <20260207082524.GE3183987@ZenIV> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/7/26 3:25 AM, Al Viro wrote: > On Fri, Feb 06, 2026 at 03:04:53PM -0500, Waiman Long wrote: > > [summary of subthread: there's an unpleasant corner case in unshare(2), > when we have a CLONE_NEWNS in flags and current->fs hadn't been shared > at all; in that case copy_mnt_ns() gets passed current->fs instead of > a private copy, which causes interesting warts in proof of correctness] > >> I guess if private means fs->users == 1, the condition could still be true. > Unfortunately, it's worse than just a convoluted proof of correctness. > Consider the case when we have CLONE_NEWCGROUP in addition to CLONE_NEWNS > (and current->fs->users == 1). > > We pass current->fs to copy_mnt_ns(), all right. Suppose it succeeds and > flips current->fs->{pwd,root} to corresponding locations in the new namespace. > Now we proceed to copy_cgroup_ns(), which fails (e.g. with -ENOMEM). > We call put_mnt_ns() on the namespace created by copy_mnt_ns(), it's > destroyed and its mount tree is dissolved, but... current->fs->root and > current->fs->pwd are both left pointing to now detached mounts. > > They are pinning those, so it's not a UAF, but it leaves the calling > process with unshare(2) failing with -ENOMEM _and_ leaving it with > pwd and root on detached isolated mounts. The last part is clearly a bug. > > There is other fun related to that mess (races with pivot_root(), including > the one between pivot_root() and fork(), of all things), but this one > is easy to isolate and fix - treat CLONE_NEWNS as "allocate a new > fs_struct even if it hadn't been shared in the first place". Sure, we could > go for something like "if both CLONE_NEWNS *and* one of the things that might > end up failing after copy_mnt_ns() call in create_new_namespaces() are set, > force allocation of new fs_struct", but let's keep it simple - the cost > of copy_fs_struct() is trivial. > > Another benefit is that copy_mnt_ns() with CLONE_NEWNS *always* gets > a freshly allocated fs_struct, yet to be attached to anything. That > seriously simplifies the analysis... > > FWIW, that bug had been there since the introduction of unshare(2) ;-/ > > Signed-off-by: Al Viro > --- > diff --git a/kernel/fork.c b/kernel/fork.c > index b1f3915d5f8e..68ccbaea7398 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -3082,7 +3082,7 @@ static int unshare_fs(unsigned long unshare_flags, struct fs_struct **new_fsp) > return 0; > > /* don't need lock here; in the worst case we'll do useless copy */ > - if (fs->users == 1) > + if (!(unshare_flags & CLONE_NEWNS) && fs->users == 1) > return 0; > > *new_fsp = copy_fs_struct(fs); > After booting up a vanilla 6.19.0-rc8 kernel, I found that copy_mnt_ns() was called 13 times during the bootup process with current->fs passed down to it. After applying this patch, the count dropped to 0. Tested-by: Waiman Long