All of lore.kernel.org
 help / color / mirror / Atom feed
From: <gregkh@linuxfoundation.org>
To: tglx@linutronix.de, bp@alien8.de, fengguang.wu@intel.com,
	gregkh@linuxfoundation.org
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "x86/cpu_entry_area: Prevent wraparound in setup_cpu_entry_area_ptes() on 32bit" has been added to the 4.14-stable tree
Date: Wed, 27 Dec 2017 16:26:11 +0100	[thread overview]
Message-ID: <1514388371246195@kroah.com> (raw)


This is a note to let you know that I've just added the patch titled

    x86/cpu_entry_area: Prevent wraparound in setup_cpu_entry_area_ptes() on 32bit

to the 4.14-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     x86-cpu_entry_area-prevent-wraparound-in-setup_cpu_entry_area_ptes-on-32bit.patch
and it can be found in the queue-4.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From f6c4fd506cb626e4346aa81688f255e593a7c5a0 Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <tglx@linutronix.de>
Date: Sat, 23 Dec 2017 19:45:11 +0100
Subject: x86/cpu_entry_area: Prevent wraparound in setup_cpu_entry_area_ptes() on 32bit

From: Thomas Gleixner <tglx@linutronix.de>

commit f6c4fd506cb626e4346aa81688f255e593a7c5a0 upstream.

The loop which populates the CPU entry area PMDs can wrap around on 32bit
machines when the number of CPUs is small.

It worked wonderful for NR_CPUS=64 for whatever reason and the moron who
wrote that code did not bother to test it with !SMP.

Check for the wraparound to fix it.

Fixes: 92a0f81d8957 ("x86/cpu_entry_area: Move it out of the fixmap")
Reported-by: kernel test robot <fengguang.wu@intel.com>
Signed-off-by: Thomas "Feels stupid" Gleixner <tglx@linutronix.de>
Tested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/mm/cpu_entry_area.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/x86/mm/cpu_entry_area.c
+++ b/arch/x86/mm/cpu_entry_area.c
@@ -122,7 +122,8 @@ static __init void setup_cpu_entry_area_
 	start = CPU_ENTRY_AREA_BASE;
 	end = start + CPU_ENTRY_AREA_MAP_SIZE;
 
-	for (; start < end; start += PMD_SIZE)
+	/* Careful here: start + PMD_SIZE might wrap around */
+	for (; start < end && start >= CPU_ENTRY_AREA_BASE; start += PMD_SIZE)
 		populate_extra_pte(start);
 #endif
 }


Patches currently in stable-queue which might be from tglx@linutronix.de are

queue-4.14/x86-entry-rename-sysenter_stack-to-cpu_entry_area_entry_stack.patch
queue-4.14/x86-mm-put-mmu-to-hardware-asid-translation-in-one-place.patch
queue-4.14/x86-vsyscall-64-explicitly-set-_page_user-in-the-pagetable-hierarchy.patch
queue-4.14/x86-uv-use-the-right-tlb-flush-api.patch
queue-4.14/x86-decoder-fix-and-update-the-opcodes-map.patch
queue-4.14/x86-mm-dump_pagetables-check-page_present-for-real.patch
queue-4.14/x86-ldt-prevent-ldt-inheritance-on-exec.patch
queue-4.14/x86-microcode-dont-abuse-the-tlb-flush-interface.patch
queue-4.14/x86-doc-remove-obvious-weirdnesses-from-the-x86-mm-layout-documentation.patch
queue-4.14/init-invoke-init_espfix_bsp-from-mm_init.patch
queue-4.14/x86-cpu_entry_area-move-it-to-a-separate-unit.patch
queue-4.14/x86-vsyscall-64-warn-and-fail-vsyscall-emulation-in-native-mode.patch
queue-4.14/x86-mm-create-asm-invpcid.h.patch
queue-4.14/x86-cpu_entry_area-prevent-wraparound-in-setup_cpu_entry_area_ptes-on-32bit.patch
queue-4.14/x86-mm-remove-superfluous-barriers.patch
queue-4.14/x86-ldt-rework-locking.patch
queue-4.14/pci-pm-force-devices-to-d0-in-pci_pm_thaw_noirq.patch
queue-4.14/arch-mm-allow-arch_dup_mmap-to-fail.patch
queue-4.14/x86-cpu_entry_area-move-it-out-of-the-fixmap.patch
queue-4.14/tools-headers-sync-objtool-uapi-header.patch
queue-4.14/x86-mm-remove-hard-coded-asid-limit-checks.patch
queue-4.14/x86-kconfig-limit-nr_cpus-on-32-bit-to-a-sane-amount.patch
queue-4.14/objtool-fix-64-bit-build-on-32-bit-host.patch
queue-4.14/x86-mm-add-comments-to-clarify-which-tlb-flush-functions-are-supposed-to-flush-what.patch
queue-4.14/x86-mm-move-the-cr3-construction-functions-to-tlbflush.h.patch
queue-4.14/x86-mm-dump_pagetables-make-the-address-hints-correct-and-readable.patch
queue-4.14/x86-insn-eval-add-utility-functions-to-get-segment-selector.patch
queue-4.14/objtool-move-synced-files-to-their-original-relative-locations.patch
queue-4.14/x86-mm-use-__flush_tlb_one-for-kernel-memory.patch
queue-4.14/objtool-move-kernel-headers-code-sync-check-to-a-script.patch
queue-4.14/x86-mm-64-improve-the-memory-map-documentation.patch
queue-4.14/objtool-fix-cross-build.patch

                 reply	other threads:[~2017-12-27 15:30 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1514388371246195@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=bp@alien8.de \
    --cc=fengguang.wu@intel.com \
    --cc=stable-commits@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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.