All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev, John David Anglin <dave.anglin@bell.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Helge Deller <deller@gmx.de>, Guenter Roeck <linux@roeck-us.net>
Subject: [PATCH 6.1 06/11] execve: always mark stack as growing down during early stack setup
Date: Mon,  3 Jul 2023 20:54:25 +0200	[thread overview]
Message-ID: <20230703184519.309377560@linuxfoundation.org> (raw)
In-Reply-To: <20230703184519.121965745@linuxfoundation.org>

From: Linus Torvalds <torvalds@linux-foundation.org>

commit f66066bc5136f25e36a2daff4896c768f18c211e upstream.

While our user stacks can grow either down (all common architectures) or
up (parisc and the ia64 register stack), the initial stack setup when we
copy the argument and environment strings to the new stack at execve()
time is always done by extending the stack downwards.

But it turns out that in commit 8d7071af8907 ("mm: always expand the
stack with the mmap write lock held"), as part of making the stack
growing code more robust, 'expand_downwards()' was now made to actually
check the vma flags:

	if (!(vma->vm_flags & VM_GROWSDOWN))
		return -EFAULT;

and that meant that this execve-time stack expansion started failing on
parisc, because on that architecture, the stack flags do not contain the
VM_GROWSDOWN bit.

At the same time the new check in expand_downwards() is clearly correct,
and simplified the callers, so let's not remove it.

The solution is instead to just codify the fact that yes, during
execve(), the stack grows down.  This not only matches reality, it ends
up being particularly simple: we already have special execve-time flags
for the stack (VM_STACK_INCOMPLETE_SETUP) and use those flags to avoid
page migration during this setup time (see vma_is_temporary_stack() and
invalid_migration_vma()).

So just add VM_GROWSDOWN to that set of temporary flags, and now our
stack flags automatically match reality, and the parisc stack expansion
works again.

Note that the VM_STACK_INCOMPLETE_SETUP bits will be cleared when the
stack is finalized, so we only add the extra VM_GROWSDOWN bit on
CONFIG_STACK_GROWSUP architectures (ie parisc) rather than adding it in
general.

Link: https://lore.kernel.org/all/612eaa53-6904-6e16-67fc-394f4faa0e16@bell.net/
Link: https://lore.kernel.org/all/5fd98a09-4792-1433-752d-029ae3545168@gmx.de/
Fixes: 8d7071af8907 ("mm: always expand the stack with the mmap write lock held")
Reported-by: John David Anglin <dave.anglin@bell.net>
Reported-and-tested-by: Helge Deller <deller@gmx.de>
Reported-and-tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 include/linux/mm.h |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -378,7 +378,7 @@ extern unsigned int kobjsize(const void
 #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
 
 /* Bits set in the VMA until the stack is in its final location */
-#define VM_STACK_INCOMPLETE_SETUP	(VM_RAND_READ | VM_SEQ_READ)
+#define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ | VM_STACK_EARLY)
 
 #define TASK_EXEC ((current->personality & READ_IMPLIES_EXEC) ? VM_EXEC : 0)
 
@@ -400,8 +400,10 @@ extern unsigned int kobjsize(const void
 
 #ifdef CONFIG_STACK_GROWSUP
 #define VM_STACK	VM_GROWSUP
+#define VM_STACK_EARLY	VM_GROWSDOWN
 #else
 #define VM_STACK	VM_GROWSDOWN
+#define VM_STACK_EARLY	0
 #endif
 
 #define VM_STACK_FLAGS	(VM_STACK | VM_STACK_DEFAULT_FLAGS | VM_ACCOUNT)



  parent reply	other threads:[~2023-07-03 18:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-03 18:54 [PATCH 6.1 00/11] 6.1.38-rc1 review Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 01/11] xtensa: fix lock_mm_and_find_vma in case VMA not found Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 02/11] drm/amd/display: Remove optimization for VRR updates Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 03/11] drm/amd/display: Do not update DRR while BW optimizations pending Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 04/11] PCI/ACPI: Validate acpi_pci_set_power_state() parameter Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 05/11] PCI/ACPI: Call _REG when transitioning D-states Greg Kroah-Hartman
2023-07-03 18:54 ` Greg Kroah-Hartman [this message]
2023-07-03 18:54 ` [PATCH 6.1 07/11] nubus: Partially revert proc_create_single_data() conversion Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 08/11] perf symbols: Symbol lookup with kcore can fail if multiple segments match stext Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 09/11] scripts/tags.sh: Resolve gtags empty index generation Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 10/11] docs: Set minimal gtags / GNU GLOBAL version to 6.6.5 Greg Kroah-Hartman
2023-07-03 18:54 ` [PATCH 6.1 11/11] drm/amdgpu: Validate VM ioctl flags Greg Kroah-Hartman
2023-07-03 23:02 ` [PATCH 6.1 00/11] 6.1.38-rc1 review ogasawara takeshi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230703184519.309377560@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=dave.anglin@bell.net \
    --cc=deller@gmx.de \
    --cc=linux@roeck-us.net \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.