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 05522C6FD18 for ; Wed, 19 Apr 2023 01:37:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 71D788E0002; Tue, 18 Apr 2023 21:37:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CDE68E0001; Tue, 18 Apr 2023 21:37:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56E018E0002; Tue, 18 Apr 2023 21:37:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 495E88E0001 for ; Tue, 18 Apr 2023 21:37:00 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0E0911C6681 for ; Wed, 19 Apr 2023 01:37:00 +0000 (UTC) X-FDA: 80696427000.22.4F04B18 Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) by imf08.hostedemail.com (Postfix) with ESMTP id 3F1CF160003 for ; Wed, 19 Apr 2023 01:36:58 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=5s+OJ9T9; spf=pass (imf08.hostedemail.com: domain of hughd@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681868218; 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:references:dkim-signature; bh=SnOVojuWZvjCGvKm6g2ZvT3BFVBOe3FpgKuoK70Vuw8=; b=v3+YNKfLgLb6x0/lCn8dzevzYemOte1h5c7KRnET6bj3wQRO0u1zvBkk09+5zYzEZC/p1M 5nCX5zPmUenmYw/so0HKk970JpkDOTQoZ9Be0g2dqFjl4PoCAG0bWZjy+tuVOjisRBDEfT NYBMo7APzAwzsn0z6ePRtv4nYv1hMu8= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=5s+OJ9T9; spf=pass (imf08.hostedemail.com: domain of hughd@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681868218; a=rsa-sha256; cv=none; b=hvGPs/xx7NOVGmSvbea+FKATDvME7KTpW3VGGqfN9xsqq7bOSw+rSecJO/2+nnL7IDbn+7 Y6F6kvVFTYJY5u4NSwny1O8XRfT3vHTTAnlupYrq/DN0jmjTfZpFa3iAvsvxygqFbTJChd 2zEI4r2Yxw0GHQZAvUdnVa0fQ/vcjrc= Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-54f6a796bd0so367179397b3.12 for ; Tue, 18 Apr 2023 18:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681868217; x=1684460217; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=SnOVojuWZvjCGvKm6g2ZvT3BFVBOe3FpgKuoK70Vuw8=; b=5s+OJ9T9UsUhZ7DfeIrljal3DDwwl9lStbUBW/eV2Oo3pQ6TguokiFUdiPo9WmlSzv U619T1L2qQXjvKytIr5XDq7TWW+taW8XItZISk3jEe6pIAUddKt7h0zfYLVdj1UfaTHV GQGCMnAoVazHwzX85do2aJI/7gJaJMCcaR23sQZZHlwNGbElriM2ExyUp4+tTieSDmsy mxpl1pUa043IcVai65aZ1+oJRNSvNDXzZOQJ5+n5Lisai4CfAB5bR8ubvWJK9P5tjL89 4PZGEtQvuvP6ORl7WFDdaWnwrTgyIEQaf28rjUt9xzB1YJejS+8bRfDt3TRsMEDRZ+Tq 8Z0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681868217; x=1684460217; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SnOVojuWZvjCGvKm6g2ZvT3BFVBOe3FpgKuoK70Vuw8=; b=ho9fyEv+b4dhwg7Ri54M0ABTAcT949DRPpVkvsA8C1phnCknZEGsUjGQaTYBOYFHxV VPfY0JJt3X2CPlKUlbLkJF7i1eHUXbQiuYLLC0dqOs+3MM/li7CXUchAaeF+4pL53ZuD hlKORc5I+ke8/7zeKR4PbeSjpqhSpcaVA1FelQ1dxhy5a3ZxwU+pjfAvzBmOBc5MRFte KN62lc2Fiq3fCNTO8CO8q8//ru33KrRmrl4+IGsq0OhdXx44jBVf24qwwFtfZUfjrAj3 39JCXMBjLWgmRd+vmdT6QwrH0m3D3a/a7k0MmGxhQ1bYK/iAyi492DwV4Sar+3zQN+h3 cmVg== X-Gm-Message-State: AAQBX9dqf1GVLxdZmtPnT+wG8grpAY3H+NfAmd12BGzWhkbQ1ALW3Eei P2gCzWGs//E8IBCCH5mzuGRIsA== X-Google-Smtp-Source: AKy350Y1HpjyFvNoanRn8jl5X5F27JdYIEha60PvD72lMQbkfwEtMRv9nSrEYo/6ZDyok87hqZtS2A== X-Received: by 2002:a81:918c:0:b0:552:ae45:6e0f with SMTP id i134-20020a81918c000000b00552ae456e0fmr1837025ywg.26.1681868217241; Tue, 18 Apr 2023 18:36:57 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id l72-20020a81704b000000b0054f88e5858esm4195396ywc.78.2023.04.18.18.36.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Apr 2023 18:36:56 -0700 (PDT) Date: Tue, 18 Apr 2023 18:36:43 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Waiman Long cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joe Mario , Barry Marson , Rafael Aquini Subject: Re: [PATCH] mm/mmap: Map MAP_STACK to VM_STACK In-Reply-To: <6c3c68b1-c4d4-dd82-58e8-f7013fb6c8e5@redhat.com> Message-ID: References: <20230418210230.3495922-1-longman@redhat.com> <20230418141852.75e551e57e97f4b522957c5c@linux-foundation.org> <6c3c68b1-c4d4-dd82-58e8-f7013fb6c8e5@redhat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1463760895-397833526-1681868216=:9821" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3F1CF160003 X-Stat-Signature: 6ym3mqy6sr5gybpec7s8m3c38d3s47ui X-Rspam-User: X-HE-Tag: 1681868218-871866 X-HE-Meta: U2FsdGVkX19/eOTyDFrJTcfk0AIqn0SPyf/+uq6c9b71FjtaK/aNgNG6ekAkdO0Q3QgPfeQahMn8uUK9ugCwSa/ECsjfvu1oZ7e37GREOTIo/xbnBoEEtnjF+XcMgqhAidrUogvm5jqtkuX2QczvzyR1DlHCPJ9fwBh2qmYijAobvi1frkAFiekl4bAzKBxVr1cYFsTaj32Pu7BbDqqCrtyJ3/JDkjlL0iZOi4+Iq29k5erHT7O/+9sAVLqszlOr/bOxOo0eyT6eC0VXt7c1OZ5xBibp0zL+2eSRBcW9IbyLDjO1AgRER71d8VxKpnw/rwgiaDl6G/SFSYUCBXJkXfYTtusKZxuPLcI1sBjzr2klf8kLmSiU8OIKYm1mCoJfIfu03A8tXpwvWg7AoZR2AVEfVk+HuPIghiPRQ94+U+h9DIr/A1NIGXY1tGl9ysIUw8D3l+kruhm3nZ8H+YjW/nxj4PfgubA2BR66q1zAoOpkHab9JBJKmLh6TCaVvsMbRziyuBrwt0ClyRtL+KcG8RS73/6d6syzFHiNxqEyBuL7JwP37qeqbNqqt0t4liQRM+kuJxJWyRpzVFAK/OWFWrJFC0mFi/JdbPrMjUbYVMhOKp7bNjtvjGIMUCLu3RkfleyDKREe4J50T86fcmbWFkYcXfajtCuUPtWxhyZMEJl2xXltDafy+XB4vPjdadQt0r12J325jBWYNfhXHSljuvfQ1DjrGyYnYqiDyZxa6xvza44E2WsQ/FliyPTVZia8dgURG8bBeWXc/6gcREc9o5A3sRb2YzOwD6xxB6zzjMMj0nQJe1tXYGeRWhHjU28dr9RXJCdND2XhWw1sl9Bat8pood88AiWzplMV768NM8Sm866n4O4hWwY4v2gOlFxMAjEYdPYITDrPyKKXC1c3ezmdqUte9zrvY1cfyQt5wyv9gDXYnqtVwT9+q69qqXNatCuuKeSJ/QZWSz0r2O6 HzHeauIo ECxFt4HkwVYAwizz+ATA8txeGA4EqbQRVwQS/jcfaIOnXeDjm0cjJq8Pv2SLG1NTTVccx8kb8U9GrtUTyez8IPIeAUU5oVd+A1fJfteE4+eKgbgT8PgOdmcRWbLmM4muTVXp5QK4WzQW1LU/0R8eMPtaPLsTIh0/2I0BF/nyzKj94YmC6gnH0PqdCnUEdHEF/itUfoROo6mSTIiLYBuhuX6k5JPebGdb1mTiE3h9JCkcD104V3qTSmULXgq6lfNfNemLQBybjW3YbliNiAOFV/Bc8/r8+nmKdHHkKL+ZZwSZQRrLR1wXK5X9R2fOmebUxIyPeBEDXI2fLvey8qPsO+jc9D8b8smyoiIEsPgmwVHMSU9WqrQXSX5wsPiEUUmVKuQaworvzC6I7je8A8PlrXexQS4wZeqWFK2FMPfR+99jtTF/m/uNxKzDkUPOYjIKik+sDSH/Pl+dq4byWtMkYGHAQH6M7I2ay2B01S/5QAjabPJYAv1U+C6Mcj+zXT1OLJYmgVxjylQE0EJs= 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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463760895-397833526-1681868216=:9821 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 18 Apr 2023, Waiman Long wrote: > On 4/18/23 17:18, Andrew Morton wrote: > > On Tue, 18 Apr 2023 17:02:30 -0400 Waiman Long wro= te: > > > >> One of the flags of mmap(2) is MAP_STACK to request a memory segment > >> suitable for a process or thread stack. The kernel currently ignores > >> this flags. Glibc uses MAP_STACK when mmapping a thread stack. However= , > >> selinux has an execstack check in selinux_file_mprotect() which disall= ows > >> a stack VMA to be made executable. > >> > >> Since MAP_STACK is a noop, it is possible for a stack VMA to be merged > >> with an adjacent anonymous VMA. With that merging, using mprotect(2) > >> to change a part of the merged anonymous VMA to make it executable may > >> fail. This can lead to sporadic failure of applications that need to > >> make those changes. > > "Sporadic failure of applications" sounds quite serious. Can you > > provide more details? >=20 > The problem boils down to the fact that it is possible for user code to m= map a > region of memory and then for the kernel to merge the VMA for that memory= with > the VMA for one of the application's thread stacks. This is causing rando= m > SEGVs with one of our large customer application. >=20 > At a high level, this is what's happening: >=20 > =C2=A01) App runs creating lots of threads. > =C2=A02) It mmap's 256K pages of anonymous memory. > =C2=A03) It writes executable code to that memory. > =C2=A04) It calls mprotect() with PROT_EXEC on that memory so > =C2=A0=C2=A0=C2=A0 it can subsequently execute the code. >=20 > The above mprotect() will fail if the mmap'd region's VMA gets merged wit= h the > VMA for one of the thread stacks.=C2=A0 That's because the default RHEL S= ELinux > policy is to not allow executable stacks. Then wouldn't the bug be at the SELinux end? VMAs may have been merged already, but the mprotect() with PROT_EXEC of the good non-stack range will then split that area off from the stack again - maybe the SELinux check does not understand that must happen? Hugh ---1463760895-397833526-1681868216=:9821--