From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EA7DC3CEB8C for ; Fri, 15 May 2026 03:28:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778815711; cv=none; b=kXj6ilh7EHRNtLmpCGBYnCwjbTDMwTBS98xTUcPpk0rcgt9MEfQFIej1wQZ9ZYudDNmC7N5fBx5mlt9QVUa5k29jtb6OqBfIBOsUCwIdEnDPINLG8+efWtl+9jWQ+xNEYbVmeROs8/2BkuHN3Fz5RJDq9Uqlyt+MpeglZD95WIg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778815711; c=relaxed/simple; bh=aZe0vz7dMgcelCnHuG+sWvZYMBhv4jJwFd/DNlUrY3c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QPrgNevBuPXPUqFuoHMbYbFCuY7kHsa/jb0PSKRVo/TnTJLxMC9r/MrByTvdzPxvFdkBpmm1mJSUShSZjIYVUSSzGPoHCF5o0MpOYHUxhSXjKHqASp0jpECZI4tdOfrESIRZFyYgeXlMNKNkWoXSUoTMnVACqvsIoZ9PO78J4dc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=S22FrXsq; arc=none smtp.client-ip=209.85.210.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="S22FrXsq" Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-839dc688d6cso3559913b3a.2 for ; Thu, 14 May 2026 20:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778815709; x=1779420509; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ol/PaD6xXPeH1cz3x0IVMh0FYdd5XYNZgnuzZiE8wVw=; b=S22FrXsqht3WLu41eIQaHUYPrsDJSpr4CloPAhH8fFoPqedeIadNq/t87qatT9oYpF aKOENkttvhmo3fV8sEfDngi19YtkiG6LG5LKBQCDCkX+So7zUO66kB6jcWv9F2HkbIoA kvsoueDQy7AM+mWr8dH3/Q8KE5wA9y7M/AXNr8pLU0bJwmSGSe7eEu+Vvl3SV4CrLLGH 6pba/Jo4yXYc0CMEEOlFnioG46bOdyA9iv2WAxjrr4V9boBKQgLsFidVWnVTTBrBjqC4 x7RpV3NZzKp8zD+vQl6Lw9jJccuEDf31FMiASv9FLAj2d9tktoaEzAf5gZ+Ln/4niJAo yNfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778815709; x=1779420509; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ol/PaD6xXPeH1cz3x0IVMh0FYdd5XYNZgnuzZiE8wVw=; b=LbAmY+3Y2OCgJeMF2NGdHg5hVc/I04p889dRqNhkFhrYDL5UlAycKKqF9ebD7M+KCK tpcqPkivNFtWzC3xMb4MIDhY9whkYqV5ZHNuNbQgNaL0X2N97DR5IP4zqgKskAUfdC1k 60m9CxHZ83C+rg7eOuVmr8JKtifV6Zo6tTmR8MIGW0bhonnKiNJB6TWQslLbVKkIsPGP VAtmZmw05rK4fY03krMFOp5jiS8jdG+9Vkj30ftC3vdVhaGAgSb3Que9qywMe8N+JX68 gMqxQi1v4LBeSMzBZGe76Tn5K4GkR7khAKPa0TSQ1EsRTZmdvRqkDuDTsxj+QzIP02c+ w8sQ== X-Gm-Message-State: AOJu0Yx0QYEbWJTAu7XyOxKDsME04YY5Q+PEJcuxddvTSPSuR1UlsIEQ wV2UiWzMa/oNXshh4KwG7MsqIU79QD7CK6s6MNt6d15u7U8PqIyqge0V X-Gm-Gg: Acq92OECHcN3/xnzsF3PELUp8HgZRG+2UOw6eZcZbMx4InRUsW85clEWGMecDocd3cM DV9k3BCimh2GDCWIgRXqf2aqpLOFodEUwSbYddaglzSJa1/rfFvY3WiAlwxzZazzshW98qFjaqp O3o3le3a8JrYJJog+lpqHUavH//tkKams4CahenXeAFaMrzML8FiGaV2CXI5ZSk0pJevYYTiyJ3 8X3NmOF7Z1q1cL4/SzjGNX+ALMlgELj2mGRMjbaUj3LGfK+8gCOJ8BlwBDaDTMaZNNK9LA2hNNM tgLeFZE7DeSL0Ukl+y6NnPdlpdj5DP6+SRN14XHky+/cUAsQdVprwyexOBERAe9byw8WNLr5XjC XcTutWTKzC141aT0l7ra0XG+/Uqysri2btyg3xroS1PUAaMfyuawP9mnY4/ptxRY0J63KTOOvf5 aQPakWlR9OVph9gtiUNY7WwqjieUU/SHkDrhFgsSVaKfM= X-Received: by 2002:a05:6a00:240e:b0:835:cc47:6fe8 with SMTP id d2e1a72fcca58-83f33dae668mr2576158b3a.46.1778815709089; Thu, 14 May 2026 20:28:29 -0700 (PDT) Received: from v4bel ([58.123.110.97]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-83f19c5c045sm5254784b3a.37.2026.05.14.20.28.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 May 2026 20:28:28 -0700 (PDT) Date: Fri, 15 May 2026 12:28:24 +0900 From: Hyunwoo Kim To: oleg@redhat.com, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, torvalds@linux-foundation.org, qsa@qualys.com, kees@kernel.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, imv4bel@gmail.com Subject: Re: [PATCH v2] exec: mirror set_dumpable() to thread-group siblings' user_dumpable Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, May 15, 2026 at 11:05:06AM +0900, Hyunwoo Kim wrote: > task_still_dumpable() reads task->user_dumpable when task->mm is NULL. > That cache is written exactly once in exit_mm(): a single > get_dumpable(mm) load taken just before task->mm is cleared. > > The load is not ordered against set_dumpable() writes performed by > CLONE_VM siblings, either via commit_creds() (an euid/egid/fsuid/fsgid > change or a capability gain - !cred_cap_issubset(old, new)) or via > prctl(PR_SET_DUMPABLE). If a sibling stores SUID_DUMP_DISABLE after > the exiting thread observed SUID_DUMP_USER, the live shared mm and the > cached value diverge with no later refresh, so task_still_dumpable() > keeps returning SUID_DUMP_USER for the exiting task. > > In set_dumpable(), after the atomic update to mm->flags, walk every > thread in current's thread group under rcu_read_lock() and mirror the > new SUID_DUMP_USER bit into each task's user_dumpable cache. All > in-tree callers of set_dumpable() pass current->mm (commit_creds(), > prctl(PR_SET_DUMPABLE), begin_new_exec()), so for_each_thread(current) > covers exactly the CLONE_VM thread group whose mm was just updated. > > The mirror takes task_lock(t) around each per-task write to serialize > with exit_mm()'s own user_dumpable RMW: the bit-field shares a word > with neighbor fields, and without serialization a race-window expansion > between the mirror's store and exit_mm()'s store on the same word can > lose the mirror's update. > > This keeps the cache in sync with the latest set_dumpable() result > even after every thread in the group has passed exit_mm(). > > Fixes: 31e62c2ebbfd ("ptrace: slightly saner 'get_dumpable()' logic") > Signed-off-by: Hyunwoo Kim > --- > Changes in v2: > - Move the update from a read-side sibling walk in task_still_dumpable() > to a write-side mirror in set_dumpable(); v1 left the cache stale > when no live sibling mm remained. > - v1: https://lore.kernel.org/all/agZjJdaIGCvf0z_1@v4bel/ > --- > fs/exec.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/fs/exec.c b/fs/exec.c > index ba12b4c466f6..9732b38b727f 100644 > --- a/fs/exec.c > +++ b/fs/exec.c > @@ -1910,10 +1910,26 @@ EXPORT_SYMBOL(set_binfmt); > */ > void set_dumpable(struct mm_struct *mm, int value) > { > + struct task_struct *t; > + bool user; > + > if (WARN_ON((unsigned)value > SUID_DUMP_ROOT)) > return; > > __mm_flags_set_mask_dumpable(mm, value); > + > + /* > + * Mirror to every sibling's user_dumpable cache, serialized with > + * exit_mm()'s write via task_lock(t) to avoid bit-field RMW races. > + */ > + user = (value == SUID_DUMP_USER); > + rcu_read_lock(); > + for_each_thread(current, t) { > + task_lock(t); > + t->user_dumpable = user; > + task_unlock(t); > + } > + rcu_read_unlock(); > } > > static inline struct user_arg_ptr native_arg(const char __user *const __user *p) > -- > 2.43.0 > Withdrawing this patch. On re-checking, it only fires in a contrived (meaningless) scenario; real binary flows are blocked by 31e62c2ebbfd. Best regards, Hyunwoo Kim