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 B0D2C1A9F85 for ; Fri, 6 Feb 2026 20:04:58 +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=1770408299; cv=none; b=FOVJy/kRQ1om7Rkd7hr9ehEqrTZT93X9VB/gJIp/+RFNXtjq0kyS4tziyRzQCyvfYUGmuJZfARYJNiKUfYAiP/I11b9GVhtwgzX/NjPn6MV5fEwWa+MWgti2ZzvV1FnTfPUiJB31hIBqq+ZqVKZHaVjPOwoTkTHvrriVqF3zGW8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770408299; c=relaxed/simple; bh=bFwL7hmv1u1PI7IRa1YTNhhzF8tpdQ0TiZHeKDflxu8=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=VoQvvDMTwGSyWeam/pXOaTKPNvouPtllOyIuNkxzLav0EO2if4jxRugbWzaQi1pknGE3TQuGS90t/IXis0P3b85hhRR6j5yNI0KzXgIiU1lFjguGtTLmCGE58mjM3b8PkmeNUO2B0NQBhvc43VViN+bTPEQihKozoKrIIaQ/eCo= 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=WUZ89JiY; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=pHL3U29Y; 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="WUZ89JiY"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="pHL3U29Y" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770408297; 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=CVzRirf5XaErG6vghkd96u/UVATWDd6WInoiZjFSHEI=; b=WUZ89JiYFlP9MECm26ufVd2lfixF4JVvb1YViAJhfsENVI49qeptDbgwKRREAoVlvM6uGJ 5rcgzkbgTGiLcJQjBvF/02/Mh/4M1EtliGKcA4QGFvBPrS+pJ5ZOssvmLSSpYEuzDLloBm AzfGy25hgSS9G+pzhFI+iNocX8lI4r8= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-29-aYaQvYDpPvKEMtxe-9ifKA-1; Fri, 06 Feb 2026 15:04:56 -0500 X-MC-Unique: aYaQvYDpPvKEMtxe-9ifKA-1 X-Mimecast-MFC-AGG-ID: aYaQvYDpPvKEMtxe-9ifKA_1770408296 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-5032e68560dso34869611cf.3 for ; Fri, 06 Feb 2026 12:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770408296; x=1771013096; 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=CVzRirf5XaErG6vghkd96u/UVATWDd6WInoiZjFSHEI=; b=pHL3U29Yj43FrfwVDPkE2XpyKDUc/TcJeW7Cwu9ZUE+S0hhvUs/cy01LSi/aOI9SF2 lXcMm7oj8XaS+KX2TZPYfKemDcRC9g9zroFFvGfVyDwF68FTUuNRn8i4A+cIe6VxSGpN wv30opIJExlX3oJ3p03iVOMXVkx1OE3rDjQ+ztxaumFRDsnAZMznOw5LhHoMh1kyGtVG ti0C6fAHoSe0/039oeBU5h9FOuH2podyph02RTO8m4cBF2J7iiLnlq7vzZloWYhG/sY0 RdNS3shl6gdP+4KfLImjhrEtM8hXWrtcboIeSgCQ1mAkpXzLAn8jdaKlJA+rU2uzbfZQ mouA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770408296; x=1771013096; 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=CVzRirf5XaErG6vghkd96u/UVATWDd6WInoiZjFSHEI=; b=pEVsORtW5VLLjzJycklQLPy4tN8JTZDxtiXLyLxvi0+LvdpmIbDD3ccFGfq6SyjC2B 9bMua0ivYgfnYL4koNsiZT3R61/2t0cK1CCG16EK1sCZ9y3Omt1ddP8cpy/gXwPMFff4 UWi+oR6IsPwoZBQUqto0uwEwbW98GucdFjZ03osP4TUDZsnCObL7OySHmXidHa1voa/e N2BRjfaxaSoF4oinBs4Q68wcnMjXATsKesDPnLrReNOrA1b3mog4sGKLLMStRprWFVfz zqOgnlIoORF6sDhuU00ZUGigsVY2EMD5Vy5UdFJwWcQ+SytWYZzaRmOqOsYQaI7k5fop F1ww== X-Forwarded-Encrypted: i=1; AJvYcCWpxtGlY4AUZMyhPXb4Nfi4dlG7Ua/w3/ZP68EWV4l7FBETtE8e3o5q15qyuTddJmy886UsFycyXcYXrqw=@vger.kernel.org X-Gm-Message-State: AOJu0YzpyaZjApLAcELFJc6jFuoEDE4wqVwpsAu7/tJnoGUzxhNdNYcU 8cmDFPNamMLuFqgMgsKvH9xokTlJit2fhwEZpUMm7DTRJCVYUnpKU3omF3dU0Ktcpz0n6gnmOjO RL5gN/ol3Vn1eX2KdqWIWrJzLCVMbxt9e12sVTz5dfVOMmm/Iz75ryWaPvvgdq4Xj7A== X-Gm-Gg: AZuq6aIEmCQ0GjcoBmGXHUlPmlaPjBRRCkTNbRzO8t4rp+KgQoxc/c3XbRFKKgDDLd1 ghXxCLTY+VR5sjakqI5+AyiZ61I0tQjP52n2jfxGy7YHyVx5S2y9Axv2vV6oB5wvfTWREsNx+R8 +PlmtrBV1Ymwdw7LfHZ9eHQrEKuXGrXTLf2kV9QpO9VrlAvBhRV+Kh7C10gZkKEbEJneTlBfVkd 4yim99zcZP9LTTzJ+KvbGEt6a5rbGPC+/FdAUWDVXubHXuwfalsFB46/Jobyc+ec4hpOe9F5hJH ypPJ2cYIcgzrhOxDo938Lp7yyg1/UIjfcdwOx/6eATIbNbG65Et1gFQrni1rxW6TWN2mPUU5tQo I5GWLhBX9AByZqqvwVqyuzDQ9IC+moihMHlc/fwnQq0Cgnuos71yOFfha X-Received: by 2002:ac8:5a44:0:b0:502:ba2c:b492 with SMTP id d75a77b69052e-50639a2b22emr53041541cf.77.1770408295870; Fri, 06 Feb 2026 12:04:55 -0800 (PST) X-Received: by 2002:ac8:5a44:0:b0:502:ba2c:b492 with SMTP id d75a77b69052e-50639a2b22emr53040891cf.77.1770408295255; Fri, 06 Feb 2026 12:04:55 -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 6a1803df08f44-89546b09f87sm8021606d6.34.2026.02.06.12.04.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Feb 2026 12:04:54 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <5cb07c57-9dca-4086-af88-f866f765c7fb@redhat.com> Date: Fri, 6 Feb 2026 15:04:53 -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 v2] audit: Avoid excessive dput/dget in audit_context setup and reset paths To: Waiman Long , Al Viro Cc: Paul Moore , Eric Paris , Christian Brauner , linux-kernel@vger.kernel.org, audit@vger.kernel.org, Richard Guy Briggs , Ricardo Robaina References: <20260203232634.GJ3183987@ZenIV> <6661f966-5235-49ca-bf1f-d1ae2ae32f0d@redhat.com> <20260204062614.GK3183987@ZenIV> <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> Content-Language: en-US In-Reply-To: <9bc83901-3819-4cf1-a1ba-cc2f52f53504@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/6/26 2:16 PM, Waiman Long wrote: > On 2/6/26 12:22 AM, Al Viro wrote: >> On Thu, Feb 05, 2026 at 11:11:51PM -0500, Waiman Long wrote: >> >>> __latent_entropy >>> struct mnt_namespace *copy_mnt_ns(u64 flags, struct mnt_namespace *ns, >>>                  struct user_namespace *user_ns, struct fs_struct >>> *new_fs) >>> { >>>    : >>>                  if (new_fs) { >>>                          if (&p->mnt == new_fs->root.mnt) { >>>                                  new_fs->root.mnt = mntget(&q->mnt); >>>                                  rootmnt = &p->mnt; >>>                          } >>>                          if (&p->mnt == new_fs->pwd.mnt) { >>>                                  new_fs->pwd.mnt = mntget(&q->mnt); >>>                                  pwdmnt = &p->mnt; >>>                          } >>>                  } >>> >>> It is replacing the fs->pwd.mnt with a new one while pwd_refs is 1. >>> I can >>> make this work with the new fs_struct field. I do have one question >>> though. >>> Do we need to acquire write_seqlock(&new_fs->seq) if we are changing >>> root or >>> pwd here or if the new_fs are in such a state that it will never >>> change when >>> this copying operation is in progress? >> In all cases when we get to that point, new_fs is always a freshly >> created private copy of current->fs, not reachable from anywhere >> other than stack frames of the callers, but the proof is not pretty. >> copy_mnt_ns() is called only by create_new_namespaces() and it gets to >> copying anything if and only if CLONE_NEWNS is in the flags.  So far, >> so good.  The call in create_new_namespaces() is >>     new_nsp->mnt_ns = copy_mnt_ns(flags, tsk->nsproxy->mnt_ns, >> user_ns, new_fs); > > Thanks for the detailed explanation. After further investigation as to > while the pwd_refs is set, I found out the code path leading to this > situation is the unshare syscall. > > __x64_sys_unshare() >  => ksys_unshare() >   => unshare_fs(unshare_flags, &new_fs) >   => unshare_nsproxy_namespaces(unshare_flags, &new_nsproxy, >                                          new_cred, new_fs); >    => create_new_namespaces(unshare_flags, current, user_ns, >                                          new_fs ? new_fs : current->fs); > > Here, CLONE_FS isn't set in unshare_flags. So new_fs is NULL and > current->fs is passed down to create_new_namespaces(). That is why > pwd_refs can be set in this case. So it looks like the comment in > copy_mnt_ns() saying that the fs_struct is private is no longer true, > at least in this case. So changing fs_struct without taking the lock > can lead to unexpected result. > > Should we add locking to make it safe? I guess if private means fs->users == 1, the condition could still be true. Cheers, Longman