Received: by 2002:a05:6358:53a8:b0:117:f937:c515 with SMTP id z40csp5944245rwe; Tue, 18 Apr 2023 14:08:53 -0700 (PDT) X-Google-Smtp-Source: AKy350ZQrLHcZ/OcZrim4w4nQZyGQcJGp0xlkVewJa4XrLuHJsCUweFP6oaTpmWMGYrO0ovbp4gV X-Received: by 2002:a05:6a20:1584:b0:f0:75f8:5e5c with SMTP id h4-20020a056a20158400b000f075f85e5cmr1119032pzj.19.1681852132909; Tue, 18 Apr 2023 14:08:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681852132; cv=none; d=google.com; s=arc-20160816; b=uKWCHDGmPMp0Z+0aHiq4dEla0+I8QS2JOh0QOQyv+0roiW+yrTpQKCtmLGNT3BqDTj Di5pg4ThQbk5rHPcwQAideslkClT89witSj5j8vsUpNaI5mRRvrWUIPIkZ70HD/qfxv2 H68BF55ChtLrvOSYE4lYC1ifUJeW6r1hM9z1e56jpv8Tz6++oE99UZIVPr+Bd+jJrU4p LLht3GW4bIaHslmDwghNoGvX9WT/00eCcHKJdR+9nd7whY7Nuc04y2GxIlpzmpa3IRGd 8heVzNL2rSKb+mB06kT1HbVl7FCmJIbQY0UwO8YcdfkdH1exr0DrF8qLcxNqcIsSBz6u F9pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=laHOqnD3W3CUxia0m/O9KtMK5N8jzZS3g0NpgnSfrrc=; b=RGhe2+mUx73tFuidaMBhwrFGFVU0Q0Ul/mFeAI0ezAxDe1f28XUml3xXgeRaVhrMqN ui/q0A+R99JTgBS33YB/gfp2l0kh6hLSEQjx7yZvGa9tVPbz3hQkYq4nJzLQ+3lkYwIf l9M/xWyADg35b1kq79Mv86flGT6K0pMPKSbFYNpJjP9lZ0nmzqBovTkN85AC+xOAPBpB f8bG4/5ySuahFd1xRCU6hQJFdK0V89dvdp1vCe6DcfUzVgtT5NmF1Mu1WgRvffcrIlL1 LjVNzgU+i6Rvjt5oudBpgosOM3e1TQPrGCyqv45lorw5gzH+WMXRiXfTUtcS/JAHi5iS bKFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FTct92Fg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m1-20020a63fd41000000b00502d825633asi15066460pgj.639.2023.04.18.14.08.32; Tue, 18 Apr 2023 14:08:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FTct92Fg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232744AbjDRVF7 (ORCPT + 99 others); Tue, 18 Apr 2023 17:05:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232842AbjDRVFv (ORCPT ); Tue, 18 Apr 2023 17:05:51 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 077EE9029 for ; Tue, 18 Apr 2023 14:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681851909; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=laHOqnD3W3CUxia0m/O9KtMK5N8jzZS3g0NpgnSfrrc=; b=FTct92Fg2Ahd5+cIvCfHONsQNDea30QG1wjqRk2gOcRW7YgRfCCkBbizV+cCRQjudwWZx1 bxbFq0pLNKLWcSEBTA9RuHBcBb4CFZsbjEBmwaPiTzQ8Hq1rq2CbAWfjtHia7zqHx5RNf0 Y5mdcYHAt3SshFoTA91ZXEpwbywOtYQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-403-7qqHD665M82NvQjDcbQGIg-1; Tue, 18 Apr 2023 17:05:05 -0400 X-MC-Unique: 7qqHD665M82NvQjDcbQGIg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0A60F811E7C; Tue, 18 Apr 2023 21:05:05 +0000 (UTC) Received: from llong.com (unknown [10.22.34.98]) by smtp.corp.redhat.com (Postfix) with ESMTP id A57F920239E0; Tue, 18 Apr 2023 21:05:04 +0000 (UTC) From: Waiman Long To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joe Mario , Barry Marson , Rafael Aquini , Waiman Long Subject: [PATCH] mm/mmap: Map MAP_STACK to VM_STACK Date: Tue, 18 Apr 2023 17:02:30 -0400 Message-Id: <20230418210230.3495922-1-longman@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 disallows 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. One possible fix is to make sure that a stack VMA will not be merged with a non-stack anonymous VMA. That requires a vm flag that can be used to distinguish a stack VMA from a regular anonymous VMA. One can add a new dummy vm flag for that purpose. However, there is only 1 bit left in the lower 32 bits of vm_flags. Another alternative is to use an existing vm flag. VM_STACK (= VM_GROWSDOWN for most arches) can certainly be used for this purpose. The downside is that it is a slight change in existing behavior. Making a stack VMA growable by default certainly fits the need of a process or thread stack. This patch now maps MAP_STACK to VM_STACK to prevent unwanted merging with adjacent non-stack VMAs and make the VMA more suitable for being used as a stack. Reported-by: Joe Mario Signed-off-by: Waiman Long --- include/linux/mman.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/mman.h b/include/linux/mman.h index cee1e4b566d8..4b621d30ace9 100644 --- a/include/linux/mman.h +++ b/include/linux/mman.h @@ -152,6 +152,7 @@ calc_vm_flag_bits(unsigned long flags) return _calc_vm_trans(flags, MAP_GROWSDOWN, VM_GROWSDOWN ) | _calc_vm_trans(flags, MAP_LOCKED, VM_LOCKED ) | _calc_vm_trans(flags, MAP_SYNC, VM_SYNC ) | + _calc_vm_trans(flags, MAP_STACK, VM_STACK ) | arch_calc_vm_flag_bits(flags); } -- 2.31.1