From nobody Fri Jun 12 12:46:29 2026 Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) (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 769712580CF for ; Fri, 15 May 2026 02:05:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.176 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778810712; cv=none; b=GdoA10jyNtE3B7GvpYRwE6CkuroqV3rLsKfnJjq8+FJ2DIh0xxoTCmguKJg5swuuenX9U+sLMDcXu6BP0jE5mWsrQ+y4u0bw7jMjFy1k/77EjoT3QD5ugZj2162bqZ86M4G+AmmOy3l1ro2quAxNSO9jxLMxCEuba9byU9Y+eew= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778810712; c=relaxed/simple; bh=k2fkAXrvFEi3HpX9TFZ05YwgbzHTXMaHaWaW2updoc0=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=qfT7xrOkhRMR7vtPbuJuYcbKb62AcdIoM2ubpX934YA303TDzbtK6qbjpA/8APptjJeK8V+IQSa1pOF72VFXDuGrc38ql6y4xgI+sG66eJZXwYnkzwZQwbv0kuoSuiZThe8q/mLKCtCC09d0TCMEGb88OiuXwxwdMe6rqzM3Cew= 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=gxn35jjN; arc=none smtp.client-ip=209.85.210.176 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="gxn35jjN" Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-83659d38e38so3773680b3a.1 for ; Thu, 14 May 2026 19:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778810711; x=1779415511; darn=vger.kernel.org; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=SBIorJYDy2JphtLdFCSFt8OFwBCOyFtM6YXCh5ThwQA=; b=gxn35jjNAxqrg3dmRVv7C+UcNBJqq3GC0nmefJdo1BFteTJjwmL4d7hLSte6mTs0Wm YJLXS77NW4niLsmpb0cYVv/9i3hsPmLw39KTc0SlSF5i1XKtJ5zYltlBCLfvZ4rlTDEO /TiABvntGNbLhJMyvhKtdVArKzbBx5z3+IXYlzJrrX7bX9Hk4lS5bRyvtvSMZfO9APps nwGtp0DkQQATwoWgUeqE0mzT6Zq5AiGzbfyPKEZEpnQIJ9iAcUkHdEcZQkDgNsVTOEJ9 CFrlKEFAX9pbjdvpefAL9s00nji5srlfhZSiu8PD3zhrLyVUz4NkXHqH6dVDbSGUBepu 1vMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778810711; x=1779415511; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SBIorJYDy2JphtLdFCSFt8OFwBCOyFtM6YXCh5ThwQA=; b=BAt7lMjGKRvtfA1sMet2SX8CQU59FNSQFP39IqDwX8f8bMIXaIk55xzTjS7g/ovktU uXX6gsUdHNIKF5b9mt1jGqX6EwBB/kuUE1DRlZzlEXCUC5d0LbdCYEGKTN1539hgE0PP Sw7gXGwQGLrKDhW64OXz3YwQUaf8rzdyAQN4ve1SVt1OZNoIcd7po5ySWmQEGyVf2JUW ec7j3qeTbhGggC03RKH+DzuMVB2WTCNVTr4rAJ6fHUk0kuV3F7LKfh/zrMsDh75cLIwI WtSPbCkbcAhkn2+vQD6bHIDDaeiIVRMJ1oj1Mfbl3mkcylMGv52dJDA08kz5VPlLibxX 47zw== X-Gm-Message-State: AOJu0Yy9wsHtbshRFiRoqZJKGPpmH3kC11ElpzdpiL7xutlMS15A42fO 0B2TN+EgdbXHJONus5WJRAqP8j3x867L29Yr5y4YuIAnq2PoNNbQici1 X-Gm-Gg: Acq92OHLea8F3M1Pc8MDQJiBUxz8vJ2bBQc7l7NnJCeC/k9/Ht3vKBOOVS6D3ULER9l MvX7TN1mGW9HwrMpC0GwnPO/40NZfI95pm92v3bmVSJ3WVivskRjo/vl4d9Xg/gJukZ/U/SuZf9 VGfTskatJkTP11FM36+tGF70Ors8gHPwhk0UMxrOuOxoC6YnI+EgkA8rHodhBuPPg5PUXg/K2ED 23uQTB2ghzToTCpScFeHtYcXBCp2oV7OMi/+7jiXHj8KyjzTf+r2B4KYpJnF/qBzGpXK9xd7Z53 swS9cB4Bah0CgMaItm1+E4qPAiZC/2RHEN9FTAu3Fg6h6ZeoFII08itfbYGXvw/nF/9+XQLo/mj 9XpsZ1LsUJ6q3lUfYyLMzHx+jQ0mm7fpneaam4jD5gd6SAVYo0WNpPaKU0gVfMBHdh4eijLuNUu pJq7ClnIkQ9Hab3p0VtijkNY7+UZnWuRkuLmAwV0hJO3U= X-Received: by 2002:a05:6a00:2382:b0:82f:8332:4933 with SMTP id d2e1a72fcca58-83f33ab666amr2162641b3a.3.1778810710605; Thu, 14 May 2026 19:05:10 -0700 (PDT) Received: from v4bel ([58.123.110.97]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-83f19f61e5dsm4134946b3a.51.2026.05.14.19.05.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 May 2026 19:05:10 -0700 (PDT) Date: Fri, 15 May 2026 11:05:06 +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: [PATCH v2] exec: mirror set_dumpable() to thread-group siblings' user_dumpable Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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; =20 __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 =3D (value =3D=3D SUID_DUMP_USER); + rcu_read_lock(); + for_each_thread(current, t) { + task_lock(t); + t->user_dumpable =3D user; + task_unlock(t); + } + rcu_read_unlock(); } =20 static inline struct user_arg_ptr native_arg(const char __user *const __us= er *p) --=20 2.43.0