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 81D18C433F5 for ; Thu, 6 Oct 2022 20:20:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B22686B0072; Thu, 6 Oct 2022 16:20:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD1F46B0073; Thu, 6 Oct 2022 16:20:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9723C8E0001; Thu, 6 Oct 2022 16:20:39 -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 7EEE66B0072 for ; Thu, 6 Oct 2022 16:20:39 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4D7974120C for ; Thu, 6 Oct 2022 20:20:39 +0000 (UTC) X-FDA: 79991642598.19.379B094 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf21.hostedemail.com (Postfix) with ESMTP id B6FEF1C0015 for ; Thu, 6 Oct 2022 20:20:38 +0000 (UTC) Received: by mail-pj1-f51.google.com with SMTP id i7-20020a17090a65c700b0020ad9666a86so5401119pjs.0 for ; Thu, 06 Oct 2022 13:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:message-id:subject:cc :to:from:date:from:to:cc:subject:date; bh=Rk5zz4A39+pbcgAoB20NzVrsEawygpTbgx4vBx4ppIs=; b=BYx3cjQRaQ61qD4kci8lj8sUlKGwxBQTGugOVwVFovwHCmI/LQDbCjb+DkICpsvW4m STdWXo4QVJpb8zGJImpu91r/m8zGJm3KZaeFnkzRlgCgjI+0GDcxB5MTmrhucCW633IN I6hYYHjSrLy5aixD/PhLwPqvTzNVP1wuQopiQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:message-id:subject:cc :to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=Rk5zz4A39+pbcgAoB20NzVrsEawygpTbgx4vBx4ppIs=; b=WrXo/tCSP0YwOr17Do0q2ik3626tXXiLVdMTdEXE3BUOo9w8NosJ+F3Q0W1ELGDNTL NPvuVQrlq0EAlhp5CqEai4u6jqsDU+IIuqatN6KkczBjLyjZEZFgD5s48YBs6UQsafqy ARl2/oFQINvyWTyJX5G7aAN+yKBMNuTdMVvNNu9Ut4tyyVOqxbx4S8xEx0ciNF4cNACf ZiXrHwQoDdjSuMbDQPw6t/DdpHkR3Xmy1tZuX3wlPx5Nwds8tCdklOcS20gnh/dIFnOG HxNljpvu4I1OUkGXPzem+M1XW3efu9h/yerqjZFPpqzWEe5YUYlJCt7Fr0WsID7B5xeK joYw== X-Gm-Message-State: ACrzQf3pbcjcyP75WwiWscOWBYq+iiYn/0tZesse/X5Pu7RDoOgd5VFb EgDWi6hwDX4yr/C8TXcJ05eMbw== X-Google-Smtp-Source: AMsMyM6jQK6faWu8ciVNIyHuo5DdhGUHU792hu5M2+fkiWdd1JDFyJ7HN7J/+hDDUVtrL381rrTPHQ== X-Received: by 2002:a17:902:864c:b0:179:fe02:611e with SMTP id y12-20020a170902864c00b00179fe02611emr1539895plt.10.1665087637621; Thu, 06 Oct 2022 13:20:37 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id p8-20020a635b08000000b0045328df8bd0sm148201pgb.71.2022.10.06.13.20.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Oct 2022 13:20:36 -0700 (PDT) Date: Thu, 6 Oct 2022 13:20:35 -0700 From: Kees Cook To: Jorge Merlino Cc: Christian Brauner , Eric Biederman , Jann Horn , Alexander Viro , Thomas Gleixner , Andy Lutomirski , Sebastian Andrzej Siewior , Andrew Morton , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, John Johansen , Paul Moore , James Morris , "Serge E. Hallyn" , Stephen Smalley , Eric Paris , Richard Haines , Casey Schaufler , Xin Long , "David S. Miller" , Todd Kjos , Ondrej Mosnacek , Prashanth Prahlad , Micah Morton , Fenghua Yu , Andrei Vagin , linux-kernel@vger.kernel.org, apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH] Fix race condition when exec'ing setuid files Message-ID: <202210061301.207A20C8E5@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202209131456.76A13BC5E4@keescook> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665087638; a=rsa-sha256; cv=none; b=qB6iBJd4onFe+NdlOysSEfWginOIZ6pV1aJtInvLaTB0N6p8wjZWfrCZGK3N/Rs3TDjZry NCrmD+ptpjeovokXa5y4cLpBayO/4kw6EBUeKWzLe23rCR7SDbnT1r2MAay9OU5hoXvs+r JFwZmzn9BOuYm1B4ecPt/uzQ6GvgbVA= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=BYx3cjQR; spf=pass (imf21.hostedemail.com: domain of keescook@chromium.org designates 209.85.216.51 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665087638; 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: in-reply-to:in-reply-to:references:dkim-signature; bh=Rk5zz4A39+pbcgAoB20NzVrsEawygpTbgx4vBx4ppIs=; b=FZMfiHaMcPTRT0NdNyjpGXtiNY9qbKWHovIFaxwFvzo9eelGhheFkA9N/0KlvlR76P2twS TeNdJ2lbCsybkhWa38cteCiAptrBKQ4lry521j+yNxhUuP2jWoOvaP8wiJVpjOrdIPTiWN ovmnMneEaWnVGwKQFZMCZjSBDonoWZk= X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=BYx3cjQR; spf=pass (imf21.hostedemail.com: domain of keescook@chromium.org designates 209.85.216.51 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Stat-Signature: xqtzpm98jhbyw5aip9wdmwtpj83wu1d7 X-Rspamd-Queue-Id: B6FEF1C0015 X-Rspamd-Server: rspam01 X-HE-Tag: 1665087638-524063 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Sep 13, 2022 at 15:03:38 -0700, Kees Cook wrote: > It seems quite unusual to have a high-load heavily threaded > process decide to exec. In looking at this a bunch more, I actually think everything is working as intended. If a process is actively launching threads while also trying to exec, they're going to create races for themselves. So the question, then, is "why are they trying to exec while actively spawning new threads?" That appears to be the core problem here, and as far as I can tell, the kernel has behaved this way for a very long time. I don't think the kernel should fix this, either, because it leads to a very weird state for userspace, where the thread spawner may suddenly die due to the exec happening in another thread. This really looks like something userspace needs to handle correctly (i.e. don't try to exec while actively spawning threads). For example, here's a fix to the original PoC: --- a.c.original 2022-10-06 13:07:13.279845619 -0700 +++ a.c 2022-10-06 13:10:27.702941645 -0700 @@ -8,8 +8,10 @@ return NULL; } +int stop_spawning; + void *target(void *p) { - for (;;) { + while (!stop_spawning) { pthread_t t; if (pthread_create(&t, NULL, nothing, NULL) == 0) pthread_join(t, NULL); @@ -17,18 +19,26 @@ return NULL; } +#define MAX_THREADS 10 + int main(void) { + pthread_t threads[MAX_THREADS]; struct timespec tv; int i; - for (i = 0; i < 10; i++) { - pthread_t t; - pthread_create(&t, NULL, target, NULL); + for (i = 0; i < MAX_THREADS; i++) { + pthread_create(&threads[i], NULL, target, NULL); } tv.tv_sec = 0; tv.tv_nsec = 100000; nanosleep(&tv, NULL); + + /* Signal shut down, and collect spawners. */ + stop_spawning = 1; + for (i = 0; i < MAX_THREADS; i++) + pthread_join(threads[i], NULL); + if (execl("./b", "./b", NULL) < 0) perror("execl"); return 0; -- Kees Cook