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 1EBF3C3600C for ; Mon, 24 Mar 2025 17:02:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD240280003; Mon, 24 Mar 2025 13:02:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B830A280001; Mon, 24 Mar 2025 13:02:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A4A38280003; Mon, 24 Mar 2025 13:02:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 89801280001 for ; Mon, 24 Mar 2025 13:02:09 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8F246120524 for ; Mon, 24 Mar 2025 17:02:10 +0000 (UTC) X-FDA: 83257062420.01.87C8DED Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf08.hostedemail.com (Postfix) with ESMTP id D75DC160007 for ; Mon, 24 Mar 2025 17:02:06 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cvYvM9yn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742835727; a=rsa-sha256; cv=none; b=BMP2cbzfHPi50XQiD4DQ/Sg4mxcYSR8KCoWD11vV1gREioqSbJUYhOkXC8Dqu6FxWuIymW r1hminETmVjRFUThTm//k1OGUc8UKEySAwsx2GQu0heTaCYVqYn94A8mZ+MnCGUoxiBIeJ 3q1UOjqzZyjd7bdEE5ED7NNuLLtUdNU= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cvYvM9yn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.41 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=1742835727; 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=2up/SKxehnXgkWs4Ef7nSpSMX8c3dSxERNVt1+RKM+k=; b=jAA9HjlOIHeZZ0SWOvGlVaweVhyA64YGyunSlQW4Yi8HgVGtCptzx1iFZSWWZBdbgWdcaw zPvhKuFqWGfp7QYJNJB7Hi3e89rI972cyC/WfOFMpvUtXAW4yeuOxSOMgQ+tHAlJaaoEuj yj/ZVq89QyX/d0JeQuHxuYjgpHuRC0o= Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-5e5e8274a74so7048529a12.1 for ; Mon, 24 Mar 2025 10:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742835725; x=1743440525; 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=2up/SKxehnXgkWs4Ef7nSpSMX8c3dSxERNVt1+RKM+k=; b=cvYvM9ynlUyMsS7UTOsQIUaeD3mNMuPAyBpsBKXJbBkhMykbjZ/RL0GcO9GS8mufp/ 4n1TtNctTPL94xLWxGK6ZMwMt1UonUKEMMbbSkSyKV7rPjy/ZSdEI5Z0qFYAWhY2zcyx NltFSpuZJ3FGd1BEeJ00gXnXq1xrOJMe32hIwDGDRQhs0JFDCJfKFiV0FZ0OcUOU/G0z CIGFQ1iGXBYDciVo2qaLdE+Q4hM093yIZJ3veYUHak7Lz9jCfGQJI9kmKdQVRODCpKEX 1Yd4imJn0XuzKeRterSCy+UrxqNoPmIBqfi9q6PNPQDxdh1+uWuYGOoTvzVpYrBzNCmj 66ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742835725; x=1743440525; 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=2up/SKxehnXgkWs4Ef7nSpSMX8c3dSxERNVt1+RKM+k=; b=cILzLDYfLL/FIql9GxvYQIl1AaTs+GdKGnMKr7wRbqct1Oorw5Ja90ABjibcDXp1jD Dfi5kS6Dmx6BkVIq5Ylp/IYu7dfEVNRgdced9ObXNCj0+PJoGy3J6VA8OkpqZXW0cc7h ANPQMHhupitFTwnPmwuKEYFfWvQpe7eBoPCSRy8LaZQ/l1+G8KJoxJcGJP7jjNUPnUcb eAKf7yD8qzkO4owOrtfN6qudPbATae9R14tVMKIFSCZ5Gt2p8TAqA45oE2mPkn+VreCu 0GuCNOl4b5QRcTyjwvWR1S6Shtg+RcYIOcKjb4xZyTEsKMqUg+khFsCbosNxOAkO9oSV axYA== X-Forwarded-Encrypted: i=1; AJvYcCWI3gAhn5gTGeMyvl5wHjQ1F8xXTrVawDT/0u+eKQglVkx+G7s2xUt6hfLGft0zD828zYTagt3X9Q==@kvack.org X-Gm-Message-State: AOJu0YyTr45jmzyiUqXJrofIvaukjl2md8CnSmiS2ZCb9czeYH5kbE1q eBhhua6X7QABWEysbjboMg5mZaErzNtdtjIKQG6sGDcPeIFJazsdl7/3ftdHJ2fRvso0hcVb0fr ujl6cOvcKA5VDVMZiRcwT0kGsrOg= X-Gm-Gg: ASbGncvYaZoFmfUI8FZaCnioz/pi8+XddLysdV4MuQOMPFGkRJqnr1c/tJumKBO6EuJ V9ZfVDpqZ3JxLT9faKkX1LCBUayIEXJSKvFiX263355NIOqJCm6t91H2qruqslNTsIvNyVCwdH5 HgESOr6XRmCghRa8V7qTqBUC6d7ilRWg6TBOsA X-Google-Smtp-Source: AGHT+IHuiWa1FtlMrtBlsq9an4gefRWo3qK5hBfqWQZhZL88FVZ8mCE1dqHyAEQzQpcUJefJLinbnNkHzTWEJdcI5nM= X-Received: by 2002:a05:6402:270a:b0:5e5:c010:e67e with SMTP id 4fb4d7f45d1cf-5ebcd521363mr10382450a12.31.1742835724279; Mon, 24 Mar 2025 10:02:04 -0700 (PDT) MIME-Version: 1.0 References: <67dc67f0.050a0220.25ae54.001f.GAE@google.com> <20250324160003.GA8878@redhat.com> In-Reply-To: <20250324160003.GA8878@redhat.com> From: Mateusz Guzik Date: Mon, 24 Mar 2025 18:01:51 +0100 X-Gm-Features: AQ5f1JrNHUcbs-my_evWJlj7MfcVWW5i_6x-T-zxej8wazTFGmtUxOJEEWF9t2U 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: D75DC160007 X-Stat-Signature: 7y3h6gtrpke9gs95sqdha1ino6ascssm X-HE-Tag: 1742835726-400814 X-HE-Meta: U2FsdGVkX19ONNobYjaxi1WuyiiaemvcCSy/wKS6SI6b4VgQi8LBIC1DJ8oMgyQugSSy9ytoqq/JhwTsjlF+FaPRU5ymPqgB6xmmPGIw8ppSb+V52HRi6/Jz3/2clNQAU7FGnbzJkBpHiTGnBNQzJ0SHMPOyxjTV0fpudLaDGRjrVHzl/In9oE3YufES1v5tntb5whYfpmmnuP08bmMFy2PZYJsuxX+r5QEGv4ThWlX/jhyzLTXFxuiIdZIg5cD5I2g76x4E/DLBctAsUWpxVuQ9AMeQeJR663w2WF8NklcawbWdnosI7UgXdsh2HMJJ5jfpyr7XX7ZO6jy4HhbUxj+1wpMtdj/uLnCKwstaLLGY2J6EncZEw1NBDs/51Eh3vigQHW9qOQlWd9h+5xlzrhZv9nWZFUBZeGpOajnrWF2KKCDIVbpRECRCBftlEl8ym4VDT8vHfJmgGFj3+gT2lS8qTC9mzND3rIJYkW4EJ7SWhsFQc9OGr6QSh6BlvXwujlHpJ0R4uu22aqCP5CMAf9UFed7GZiDNGZ4Ho0oi9SG8X6pWX4dCNxBlXLbfq31EdX9gph/VVAW6rcuZWEmFgRgrKaUolO4BSGtwDSGozgaaTqFgMDhXQEo1fetO2sOXxi7f4YwMKGcmtFC3GLWDpJBIX02e/f9WfcSVX/MFTUM8A76f4HOW794IT/0y5FWVUH/JZ8cZycNQ+sl/V0+rtYDaCXFEs0+NDSDTkZpiGLKrXqKcTPI1191Ef+coA7oP9rTEVNAlVoBcSDCGGhbPqjgaHypX5FxTlgcj+pXQQYLgHnG2O39RrowlJrlsfU3iojvjQTroPYdMqqKeytKfood4x6X88M1BF9kVdWKjhkV4ojOToWBI+upE7oYaA6kBHXeC9Njo7gCVWLLsg+kfLGqkRAJGbbmz7ldJBr30sCzZVipTQod6GrZaA+U2YTYBQOwXgb+rTy70oWimj4l lWaKNkER Yfsh2gkYusRE7Q5ouQfpZeFeMXNiKMp0UrpZOcsx/kOUsDgLS90EH9aqhX0cCyYmejN33b71fn+b8DbNMiW+aXDxIhZ8BiiKnkN4LuTtJmxMBP0Q0JwMxtcXSUxj/3ezPvzQ2S9zkAgf36Ob7xPobNmLHmI3N5L8Bb4FUJOUrgC0s6dVdr0L+QPb1Ue9Apj1HkZkjmHTL9Wz2r6myS5kpHsr6AT4nTBPUfEjvj8InEHD5vGo7gFHlNllA/M7q4JkSB/mK3gSj77TDa/miqErqYFtjoRNJ6QpVviXBgZXTUzqJutScxkE2eVgTiSfFnh8Yk+WGBGjUfR06Y+t8D5w7b+1WUlaN89ByzPbvfrSiJnQ7A8/0jDXf2wkaebU8KXBPPM1KHJYu3K5WJwvJlRbtLaRrQTHNZkTfm2plCtxyD9LCJcjDRtTGcJ2hZ7giNnqf2KZJQ2LiiX1eHfA2AWjgLISjvAQTcevYsNXnCEgNQqxEN2smPm/rkuB4KjO/f7+D9B+Z X-Bogosity: Ham, tests=bogofilter, spamicity=0.002057, 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 5:00=E2=80=AFPM Oleg Nesterov wro= te: > > check_unsafe_exec() sets fs->in_exec under cred_guard_mutex, then execve(= ) > paths clear fs->in_exec lockless. This is fine if exec succeeds, but if i= t > fails we have the following race: > > T1 sets fs->in_exec =3D 1, fails, drops cred_guard_mutex > > T2 sets fs->in_exec =3D 1 > > T1 clears fs->in_exec > > T2 continues with fs->in_exec =3D=3D 0 > > Change fs/exec.c to clear fs->in_exec with cred_guard_mutex held. > I had cursory glances at this code earlier and the more I try to understand it the more confused I am. The mutex at hand hides in ->signal and fs->in_exec remains treated as a fl= ag. The loop in check_unsafe_exec() tries to guard against a task which shares ->fs, but does not share ->mm? To my reading this implies unshared ->signal, so the mutex protection does not apply. I think this ends up being harmless as in this case nobody is going to set ->in_exec (instead they are going to share LSM_UNSAFE_SHARE), so clearing it in these spots becomes a nop. At the same time the check in copy_fs() no longer blocks clones as check_unsafe_exec() already opts to LSM_UNSAFE_SHARE? Even if this all works with the patch, this is an incredibly odd set of dependencies and I don't see a good reason for it to still be here. Per my other e-mail the obvious scheme would serialize all execs sharing ->fs and make copy_fs do a killable wait for execs to finish. Arguably this would also improve userspace-visible behavior as a transient -EBUSY would be eliminated. No matter what the specific solution, imo treating ->in_exec as a flag needs to die. is there a problem getting this done even for stable kernels? I understand it would be harder to backport churn-wise, but should be much easier to reason about? Just my $0,03 --=20 Mateusz Guzik