From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE337C36002 for ; Mon, 24 Mar 2025 22:24:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C4614280002; Mon, 24 Mar 2025 18:24:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BCDD1280001; Mon, 24 Mar 2025 18:24:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6E36280002; Mon, 24 Mar 2025 18:24:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 84A31280001 for ; Mon, 24 Mar 2025 18:24:15 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6C61F160346 for ; Mon, 24 Mar 2025 22:24:16 +0000 (UTC) X-FDA: 83257874112.22.12EDA5F Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf27.hostedemail.com (Postfix) with ESMTP id 7D32F40009 for ; Mon, 24 Mar 2025 22:24:14 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KrjnVtLf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742855054; a=rsa-sha256; cv=none; b=xKrTpTKwjghj6F52/Se/sNXshSL3+61kdwRo7nNecyUGGt2TI73uUV08uRuXDsxVM4FARC IgRk/fx8xq1sFHbHTJm3rUwzXNmfMzYEdLZKoDJEIBijSJVXEyOckbi3bS7l0SpZD6SLNd ZGPp5FmIonQcbbtBQ1gkbQBMto/jlqU= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KrjnVtLf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742855054; h=from:from:sender: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:dkim-signature; bh=Q+Zzt8pzMsAcoKZidlF7hVur3wO7pd1WawlETRsumfg=; b=O8NfO95WRWHD/Udmche4zncUpCBDOLNuKthuaXJNrrvAA5WpSWuY1rnv/ReEa9IUT6osbG MIUO4sBYwHEwVP84F8KMHtrSlXSuAVC1khVT/PcP30nWIP7NHVTCQ7eeBnXu4T5QTuNktw FUUEUWnRqDL37Wf4c9PA4W8o5xL+mZM= Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-ac29af3382dso839861766b.2 for ; Mon, 24 Mar 2025 15:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742855053; x=1743459853; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Q+Zzt8pzMsAcoKZidlF7hVur3wO7pd1WawlETRsumfg=; b=KrjnVtLfv76q21F0mWaEuGOA4bsxg1AzfeV9AwJWmNG2UWHo4YwJNMdZOp5bNMOV1X rIalgAqmZjNYy2DVpFIqV1dIwAFbIvioY0kP/4w3Ra7NZVwI99Qnp/wOaC+XkRGNyDTD 6b/rBTaPS+L1WtsAZGjXLPFW7r4LqNCOK6aOW/G5kiQcv/zE6SV+CTQkgoFT6cJttEEs 39BlfCnhrKWI0eNKjcgpje92/t2zz9K5jLKAE8jghfKXrn2fKnV8wENMHIZo+9nulxbZ 9ci+AR/Ah1iCX22XaTrTDrz+8tNwmGFpg5OZkRpPzyJJQFfiKwxzm+j0sMi1E3oXoQag eNIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742855053; x=1743459853; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Q+Zzt8pzMsAcoKZidlF7hVur3wO7pd1WawlETRsumfg=; b=ihNrgkE0U/nP2F+Xi2n+sGa8h9OtjAl0WgnsSxNEZ3jYdFkjoglIRYCG+closK1lS2 ie2nZZOHkmgQg+DoR55eWQJQjyF2y16CpGrf53QD4IqTG6QNUyZNMjIp+AX588WLTG1E KsA1KpXtNyhnoRyHAdOZ6jsHdrw4JEAbgAo3YXaonZORUYnn686Kd+ff1nImN6DREhKB Mlsk4trC6kGBcIPiMzKGAfsumzP+Ne7rA64FACAJkleIJKDd3C4oqnJOqpbd/yogkKMJ WZgkpKQ8mnS0nw2VCihS6WIfSAYtYcPjqlmRfMnRD0JLkY2OCCzmC0iXI387av9MVvcX XChw== X-Forwarded-Encrypted: i=1; AJvYcCVG4p3W85GNjffdwPLiZN20UTcmKsbt1NbFLdI7YjrIgH9V7tQa910Atvw04hqzdFZzLNTUn+aVYQ==@kvack.org X-Gm-Message-State: AOJu0YzjH6jBCRKEuM0v6WgsOHG9Gsg9CrTbY1Kgwxm43K88YlPFMgOc si6IWmCcIitnBOZEjIHQqlaTwngXJ/heylXfzZOmHOEYvMV0nIbd3O80DY+Rxo9VLwkZd9Qpm1H +/051SqXyAy7NoB9B7XkLnaIsV3A= X-Gm-Gg: ASbGncsgSzcw0KQl2M0vFYgYY55ppwb9t5XxBhvfY1C/aQ/E8l0TzcY7v7ZxvxO+1Rm 0+LGVdwlmomx7WAFxlgcQqDuOTX7XNeQblKoDcwFbp7LV0wZjDMdlr8pwun4Y/pfsoOLVlJyQtL kHZ6hx3rtRTQn1dLQXZWnTevjthA== X-Google-Smtp-Source: AGHT+IE7vveODIuMKV9mImaQQMaSQBJD/AJ0Dw0I1is557b1m41KLoVw99cZoHBh/gGY9eMG1dYS5Y0XXSIMBC/Sae0= X-Received: by 2002:a17:907:2dac:b0:ac3:bd68:24eb with SMTP id a640c23a62f3a-ac3f20b07a7mr1538727466b.1.1742855052484; Mon, 24 Mar 2025 15:24:12 -0700 (PDT) MIME-Version: 1.0 References: <67dc67f0.050a0220.25ae54.001f.GAE@google.com> <20250324160003.GA8878@redhat.com> <20250324182722.GA29185@redhat.com> In-Reply-To: <20250324182722.GA29185@redhat.com> From: Mateusz Guzik Date: Mon, 24 Mar 2025 23:24:00 +0100 X-Gm-Features: AQ5f1JoKAM6ik3I_g3NlPZ0VGOs4ToUGcUruZAghViz1VGc7L4lzi9B3A1nZink Message-ID: Subject: Re: [PATCH] exec: fix the racy usage of fs_struct->in_exec To: Oleg Nesterov Cc: syzbot , brauner@kernel.org, kees@kernel.org, viro@zeniv.linux.org.uk, jack@suse.cz, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 7D32F40009 X-Stat-Signature: u1h43f319y1wdcctjbsossu3sp6zti6d X-HE-Tag: 1742855054-357104 X-HE-Meta: U2FsdGVkX1/YpKSITUff0SMBYzpGnRo9OxxECrhRvmqMGwUu3r+CW1n0r7sTBuwLGxUGr2OY4MgIiX4BHJxgOrIPPsePN+1exfEehIXNxxYOnAv8D47tReedSJ3XDErYBJ99E11B/hSLKI+LbYht+FMJAUizbrKyUrQl5DfdOGevHnIfLYxTYu/FiYHwwQPjMsezt9kTTNHoCE1WbYszpKUjnpEaqyZ4i/FqzeScliMx//I+1VE+bJ1Zv7nas4wlB4WTpQJDJmcH3AhxZlmPsN7RT4denTJbOgLkqabGea/Js4JNKkxuVkqRWjQ06QwpBZvTxVZ7RcFSs2yrkjhaUCMNGLtiAxXAmhveTnPxRHQl0pgbHMnc/qh3rwadySz9hWUlWP5DqQEwIniwPDoK/C46R5aUA+jlPXevFQOaD3SbWnZCAHNCrNcfvi9AesBWbWDy6d26MwUYv/0FOXP7Z6U295b2BbItayj4ARHyTfbPr/FB/jbQ89ubV1sKkjcGMKL0Amw5iPGtd2FtqLtjMk7PgPjyo/BSX0HIkqRD3D5ZcY0EisyEQIWwGiDZ64hRCq8t+CeIl+rJZi21Rwtm8Zj2tzCiXNdr54YLhp3XocCp9nBU7EGq/yKoo3X51c6955bFbkRHpaw2mDTjsYChR/1SLRQdYVc3sLO6Jl2JgGhqldNyRvZ/tBfD103krbvpQDcgeMQwPHs0XUv1tdCoGA1AszgbywxdfTzePDSuF17+CSMHS7PSTzVBoCQ/tL+DBIVhJuKLJw/LLSql+n1kmYjeeDl/khFu7WvFkzHXe48VwtNf+N/nkzu81SnanHxW0hUjELIxH1Ll1hA0hoRGPh9rJCvmxIGr0U8Uy1jKsrITqYPZxzZj/PWc4BODltmONdWMLIr96UkLYqRLQBkWTzuLMb+ZdqzljXvRbiE3LzVfmg1QweYJcbjrZ/w07Kq3MZAoFUpxKV4Dsf9DtTc DvhKdvXI u8qjwV7jBnknYG737rfFyo8BN02A/9sxZMshCsx4NYULkkNOtDCyEwIb065xakwx5Mj5M2hZmkeOxxKu6IM1mWfsoQ5K2P3Q3kp9OKONpwkG+wZllCR7w9V9dfSyDp9tafPKFLlgiguedJOQwY9FN621DM25jEeHLpS/jllt6yw8RghdhfjtocPfXGecJWdMkFAhdxcyrJxsEPdRBbDTFzwIq2jpqMtOO9hzRoXd7D4kh0VKcTRYyuSailj40Tocwc41PV8eP2HrgwY67icz/mrEwSAp14puXYuuUDEs5NJfgN8jj7LvTN3236VhpYbD4DhCmBPRVfD5D4PcdAyYQpsZo/EF0u7TCrf2+n/CG+/JPniI6+VCuDY0y08fTKHCVjLa5FAqJ8UgJ/9Opb5hNZa94QrVTETm0F7Fsf426X5ut5/xPTwjCxM2BQ6g2Ek8/mKAGNYmrp9DQMsMCS2HQS8SQI+I/6U6hnHiYbbTNn7yJoIZCCuVC8FemimQrzbiMh9Tf X-Bogosity: Ham, tests=bogofilter, spamicity=0.025187, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Mar 24, 2025 at 7:28=E2=80=AFPM Oleg Nesterov wro= te: > I won't argue with another solution. But this problem is quite old, > unless I am totally confused this logic was wrong from the very > beginning when fs->in_exec was introduced by 498052bba55ec. > > So to me it would be better to have the trivial fix for stable, > exactly because it is trivially backportable. Then cleanup/simplify > this logic on top of it. > So I got myself a crap testcase with a CLONE_FS'ed task which can execve and sanity-checked that suid is indeed not honored as expected. The most convenient way out of planting a mutex in there does not work because of the size -- fs_struct is already at 56 bytes and I'm not going to push it past 64. However, looks like "wait on bit" machinery can be employed here, based on what I had seen with inodes (see __wait_on_freeing_inode) and that should avoid growing the struct, unless I'm grossly misreading something. Anyhow, the plan would be to serialize on the bit, synchronized with the current spin lock. copy_fs would call a helper to wait for it to clear, would still bump ->users under the spin lock. This would decouple the handling from cred_mutex and avoid weirdness like clearing the ->in_exec flag when we never set it. Should be easy enough and viable for backports, I'll try to hack it up tomorrow unless the idea is NAKed. The crapper mentioned above will be used to validate exec vs clone work as expected. -- Mateusz Guzik