stable.vger.kernel.org archive mirror
 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,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH 6.4 23/28] gup: add warning if some caller would seem to want stack expansion
Date: Thu, 29 Jun 2023 20:44:11 +0200	[thread overview]
Message-ID: <20230629184152.797695288@linuxfoundation.org> (raw)
In-Reply-To: <20230629184151.888604958@linuxfoundation.org>

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

commit a425ac5365f6cb3cc47bf83e6bff0213c10445f7 upstream.

It feels very unlikely that anybody would want to do a GUP in an
unmapped area under the stack pointer, but real users sometimes do some
really strange things.  So add a (temporary) warning for the case where
a GUP fails and expanding the stack might have made it work.

It's trivial to do the expansion in the caller as part of getting the mm
lock in the first place - see __access_remote_vm() for ptrace, for
example - it's just that it's unnecessarily painful to do it deep in the
guts of the GUP lookup when we might have to drop and re-take the lock.

I doubt anybody actually does anything quite this strange, but let's be
proactive: adding these warnings is simple, and will make debugging it
much easier if they trigger.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 mm/gup.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1096,7 +1096,11 @@ static long __get_user_pages(struct mm_s
 
 		/* first iteration or cross vma bound */
 		if (!vma || start >= vma->vm_end) {
-			vma = vma_lookup(mm, start);
+			vma = find_vma(mm, start);
+			if (vma && (start < vma->vm_start)) {
+				WARN_ON_ONCE(vma->vm_flags & VM_GROWSDOWN);
+				vma = NULL;
+			}
 			if (!vma && in_gate_area(mm, start)) {
 				ret = get_gate_page(mm, start & PAGE_MASK,
 						gup_flags, &vma,
@@ -1265,9 +1269,13 @@ int fixup_user_fault(struct mm_struct *m
 		fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
 
 retry:
-	vma = vma_lookup(mm, address);
+	vma = find_vma(mm, address);
 	if (!vma)
 		return -EFAULT;
+	if (address < vma->vm_start ) {
+		WARN_ON_ONCE(vma->vm_flags & VM_GROWSDOWN);
+		return -EFAULT;
+	}
 
 	if (!vma_permits_fault(vma, fault_flags))
 		return -EFAULT;



  parent reply	other threads:[~2023-06-29 18:48 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-29 18:43 [PATCH 6.4 00/28] 6.4.1-rc1 review Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 01/28] x86/microcode/AMD: Load late on both threads too Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 02/28] x86/smp: Make stop_other_cpus() more robust Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 03/28] x86/smp: Dont access non-existing CPUID leaf Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 04/28] x86/smp: Remove pointless wmb()s from native_stop_other_cpus() Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 05/28] x86/smp: Use dedicated cache-line for mwait_play_dead() Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 06/28] x86/smp: Cure kexec() vs. mwait_play_dead() breakage Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 07/28] cpufreq: amd-pstate: Make amd-pstate EPP driver name hyphenated Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 08/28] can: isotp: isotp_sendmsg(): fix return error fix on TX path Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 09/28] maple_tree: fix potential out-of-bounds access in mas_wr_end_piv() Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 10/28] mm: introduce new lock_mm_and_find_vma() page fault helper Greg Kroah-Hartman
2023-06-29 18:43 ` [PATCH 6.4 11/28] mm: make the page fault mmap locking killable Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 12/28] arm64/mm: Convert to using lock_mm_and_find_vma() Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 13/28] powerpc/mm: " Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 14/28] mips/mm: " Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 15/28] riscv/mm: " Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 16/28] arm/mm: " Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 17/28] mm/fault: convert remaining simple cases to lock_mm_and_find_vma() Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 18/28] powerpc/mm: convert coprocessor fault " Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 19/28] mm: make find_extend_vma() fail if write lock not held Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 20/28] execve: expand new process stack manually ahead of time Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 21/28] mm: always expand the stack with the mmap write lock held Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 22/28] HID: wacom: Use ktime_t rather than int when dealing with timestamps Greg Kroah-Hartman
2023-06-29 18:44 ` Greg Kroah-Hartman [this message]
2023-06-29 18:44 ` [PATCH 6.4 24/28] mm/khugepaged: fix regression in collapse_file() Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 25/28] fbdev: fix potential OOB read in fast_imageblit() Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 26/28] HID: hidraw: fix data race on device refcount Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 27/28] HID: logitech-hidpp: add HIDPP_QUIRK_DELAYED_INIT for the T651 Greg Kroah-Hartman
2023-06-29 18:44 ` [PATCH 6.4 28/28] Revert "thermal/drivers/mediatek: Use devm_of_iomap to avoid resource leak in mtk_thermal_probe" Greg Kroah-Hartman
2023-06-30  5:30 ` [PATCH 6.4 00/28] 6.4.1-rc1 review Naresh Kamboju
2023-06-30  5:52   ` Greg Kroah-Hartman
2023-06-30  6:16   ` Linus Torvalds
2023-06-30  6:29     ` Greg Kroah-Hartman
2023-06-30  6:56       ` Helge Deller
2023-07-02 21:33         ` [PATCH 6.4 00/28] 6.4.1-rc1 review - hppa argument list too long Helge Deller
2023-07-02 22:45           ` Linus Torvalds
2023-07-02 23:30             ` Linus Torvalds
2023-07-03  3:23               ` Guenter Roeck
2023-07-03  4:22                 ` Linus Torvalds
2023-07-03  4:46                   ` Guenter Roeck
2023-07-03  4:49                     ` Linus Torvalds
2023-07-03  5:33                       ` Guenter Roeck
2023-07-03  6:20                         ` Linus Torvalds
2023-07-03  7:08                           ` Helge Deller
2023-07-03 16:49                             ` Linus Torvalds
2023-07-03 17:19                               ` Guenter Roeck
2023-07-03 17:30                                 ` Linus Torvalds
2023-07-03 19:24                               ` Helge Deller
2023-07-03 19:31                                 ` Sam James
2023-07-03 19:36                                   ` Sam James
2023-07-03 12:59                           ` Guenter Roeck
2023-07-03 13:06                             ` Guenter Roeck
2023-06-30  6:29     ` [PATCH 6.4 00/28] 6.4.1-rc1 review Guenter Roeck
2023-06-30  6:33       ` Guenter Roeck
2023-06-30  6:33       ` Linus Torvalds
2023-06-30  6:47         ` Linus Torvalds
2023-06-30 22:51           ` Guenter Roeck
2023-07-01  1:24             ` Linus Torvalds
2023-07-01  2:49               ` Guenter Roeck
2023-07-01  4:22                 ` Linus Torvalds
2023-07-01  9:57                   ` Greg Kroah-Hartman
2023-07-01 10:32                   ` Max Filippov
2023-07-01 15:01                     ` Linus Torvalds
2023-06-30  6:51         ` Greg Kroah-Hartman
2023-06-30  6:28   ` Greg Kroah-Hartman

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=20230629184152.797695288@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).