--- /dev/null
+From c2a6bbaf0c5f90463a7011a295bbdb7e33c80b51 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Fri, 30 Dec 2016 02:27:31 +0100
+Subject: ACPI / scan: Prefer devices without _HID/_CID for _ADR matching
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit c2a6bbaf0c5f90463a7011a295bbdb7e33c80b51 upstream.
+
+The way acpi_find_child_device() works currently is that, if there
+are two (or more) devices with the same _ADR value in the same
+namespace scope (which is not specifically allowed by the spec and
+the OS behavior in that case is not defined), the first one of them
+found to be present (with the help of _STA) will be returned.
+
+This covers the majority of cases, but is not sufficient if some of
+the devices in question have a _HID (or _CID) returning some valid
+ACPI/PNP device IDs (which is disallowed by the spec) and the
+ASL writers' expectation appears to be that the OS will match
+devices without a valid ACPI/PNP device ID against a given bus
+address first.
+
+To cover this special case as well, modify find_child_checks()
+to prefer devices without ACPI/PNP device IDs over devices that
+have them.
+
+Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Tested-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/glue.c | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/drivers/acpi/glue.c
++++ b/drivers/acpi/glue.c
+@@ -99,13 +99,13 @@ static int find_child_checks(struct acpi
+ return -ENODEV;
+
+ /*
+- * If the device has a _HID (or _CID) returning a valid ACPI/PNP
+- * device ID, it is better to make it look less attractive here, so that
+- * the other device with the same _ADR value (that may not have a valid
+- * device ID) can be matched going forward. [This means a second spec
+- * violation in a row, so whatever we do here is best effort anyway.]
++ * If the device has a _HID returning a valid ACPI/PNP device ID, it is
++ * better to make it look less attractive here, so that the other device
++ * with the same _ADR value (that may not have a valid device ID) can be
++ * matched going forward. [This means a second spec violation in a row,
++ * so whatever we do here is best effort anyway.]
+ */
+- return sta_present && list_empty(&adev->pnp.ids) ?
++ return sta_present && !adev->pnp.type.platform_id ?
+ FIND_CHILD_MAX_SCORE : FIND_CHILD_MIN_SCORE;
+ }
+
--- /dev/null
+From 3b2d69114fefa474fca542e51119036dceb4aa6f Mon Sep 17 00:00:00 2001
+From: Seunghun Han <kkamagui@gmail.com>
+Date: Wed, 26 Apr 2017 16:18:08 +0800
+Subject: ACPICA: Namespace: fix operand cache leak
+
+From: Seunghun Han <kkamagui@gmail.com>
+
+commit 3b2d69114fefa474fca542e51119036dceb4aa6f upstream.
+
+ACPICA commit a23325b2e583556eae88ed3f764e457786bf4df6
+
+I found some ACPI operand cache leaks in ACPI early abort cases.
+
+Boot log of ACPI operand cache leak is as follows:
+>[ 0.174332] ACPI: Added _OSI(Module Device)
+>[ 0.175504] ACPI: Added _OSI(Processor Device)
+>[ 0.176010] ACPI: Added _OSI(3.0 _SCP Extensions)
+>[ 0.177032] ACPI: Added _OSI(Processor Aggregator Device)
+>[ 0.178284] ACPI: SCI (IRQ16705) allocation failed
+>[ 0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install
+System Control Interrupt handler (20160930/evevent-131)
+>[ 0.180008] ACPI: Unable to start the ACPI Interpreter
+>[ 0.181125] ACPI Error: Could not remove SCI handler
+(20160930/evmisc-281)
+>[ 0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has
+objects
+>[ 0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2
+>[ 0.186820] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS
+virtual_box 12/01/2006
+>[ 0.188000] Call Trace:
+>[ 0.188000] ? dump_stack+0x5c/0x7d
+>[ 0.188000] ? kmem_cache_destroy+0x224/0x230
+>[ 0.188000] ? acpi_sleep_proc_init+0x22/0x22
+>[ 0.188000] ? acpi_os_delete_cache+0xa/0xd
+>[ 0.188000] ? acpi_ut_delete_caches+0x3f/0x7b
+>[ 0.188000] ? acpi_terminate+0x5/0xf
+>[ 0.188000] ? acpi_init+0x288/0x32e
+>[ 0.188000] ? __class_create+0x4c/0x80
+>[ 0.188000] ? video_setup+0x7a/0x7a
+>[ 0.188000] ? do_one_initcall+0x4e/0x1b0
+>[ 0.188000] ? kernel_init_freeable+0x194/0x21a
+>[ 0.188000] ? rest_init+0x80/0x80
+>[ 0.188000] ? kernel_init+0xa/0x100
+>[ 0.188000] ? ret_from_fork+0x25/0x30
+
+When early abort is occurred due to invalid ACPI information, Linux kernel
+terminates ACPI by calling acpi_terminate() function. The function calls
+acpi_ns_terminate() function to delete namespace data and ACPI operand cache
+(acpi_gbl_module_code_list).
+
+But the deletion code in acpi_ns_terminate() function is wrapped in
+ACPI_EXEC_APP definition, therefore the code is only executed when the
+definition exists. If the define doesn't exist, ACPI operand cache
+(acpi_gbl_module_code_list) is leaked, and stack dump is shown in kernel log.
+
+This causes a security threat because the old kernel (<= 4.9) shows memory
+locations of kernel functions in stack dump, therefore kernel ASLR can be
+neutralized.
+
+To fix ACPI operand leak for enhancing security, I made a patch which
+removes the ACPI_EXEC_APP define in acpi_ns_terminate() function for
+executing the deletion code unconditionally.
+
+Link: https://github.com/acpica/acpica/commit/a23325b2
+Signed-off-by: Seunghun Han <kkamagui@gmail.com>
+Signed-off-by: Lv Zheng <lv.zheng@intel.com>
+Signed-off-by: Bob Moore <robert.moore@intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Acked-by: Lee, Chun-Yi <jlee@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/acpica/nsutils.c | 23 +++++++++--------------
+ 1 file changed, 9 insertions(+), 14 deletions(-)
+
+--- a/drivers/acpi/acpica/nsutils.c
++++ b/drivers/acpi/acpica/nsutils.c
+@@ -594,25 +594,20 @@ struct acpi_namespace_node *acpi_ns_vali
+ void acpi_ns_terminate(void)
+ {
+ acpi_status status;
++ union acpi_operand_object *prev;
++ union acpi_operand_object *next;
+
+ ACPI_FUNCTION_TRACE(ns_terminate);
+
+-#ifdef ACPI_EXEC_APP
+- {
+- union acpi_operand_object *prev;
+- union acpi_operand_object *next;
++ /* Delete any module-level code blocks */
+
+- /* Delete any module-level code blocks */
+-
+- next = acpi_gbl_module_code_list;
+- while (next) {
+- prev = next;
+- next = next->method.mutex;
+- prev->method.mutex = NULL; /* Clear the Mutex (cheated) field */
+- acpi_ut_remove_reference(prev);
+- }
++ next = acpi_gbl_module_code_list;
++ while (next) {
++ prev = next;
++ next = next->method.mutex;
++ prev->method.mutex = NULL; /* Clear the Mutex (cheated) field */
++ acpi_ut_remove_reference(prev);
+ }
+-#endif
+
+ /*
+ * Free the entire namespace -- all nodes and all objects
--- /dev/null
+From e048cb32f69038aa1c8f11e5c1b331be4181659d Mon Sep 17 00:00:00 2001
+From: Doug Berger <opendmb@gmail.com>
+Date: Mon, 10 Jul 2017 15:49:44 -0700
+Subject: cma: fix calculation of aligned offset
+
+From: Doug Berger <opendmb@gmail.com>
+
+commit e048cb32f69038aa1c8f11e5c1b331be4181659d upstream.
+
+The align_offset parameter is used by bitmap_find_next_zero_area_off()
+to represent the offset of map's base from the previous alignment
+boundary; the function ensures that the returned index, plus the
+align_offset, honors the specified align_mask.
+
+The logic introduced by commit b5be83e308f7 ("mm: cma: align to physical
+address, not CMA region position") has the cma driver calculate the
+offset to the *next* alignment boundary. In most cases, the base
+alignment is greater than that specified when making allocations,
+resulting in a zero offset whether we align up or down. In the example
+given with the commit, the base alignment (8MB) was half the requested
+alignment (16MB) so the math also happened to work since the offset is
+8MB in both directions. However, when requesting allocations with an
+alignment greater than twice that of the base, the returned index would
+not be correctly aligned.
+
+Also, the align_order arguments of cma_bitmap_aligned_mask() and
+cma_bitmap_aligned_offset() should not be negative so the argument type
+was made unsigned.
+
+Fixes: b5be83e308f7 ("mm: cma: align to physical address, not CMA region position")
+Link: http://lkml.kernel.org/r/20170628170742.2895-1-opendmb@gmail.com
+Signed-off-by: Angus Clark <angus@angusclark.org>
+Signed-off-by: Doug Berger <opendmb@gmail.com>
+Acked-by: Gregory Fong <gregory.0xf0@gmail.com>
+Cc: Doug Berger <opendmb@gmail.com>
+Cc: Angus Clark <angus@angusclark.org>
+Cc: Laura Abbott <labbott@redhat.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Lucas Stach <l.stach@pengutronix.de>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Shiraz Hashim <shashim@codeaurora.org>
+Cc: Jaewon Kim <jaewon31.kim@samsung.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/cma.c | 15 ++++++---------
+ 1 file changed, 6 insertions(+), 9 deletions(-)
+
+--- a/mm/cma.c
++++ b/mm/cma.c
+@@ -54,7 +54,7 @@ unsigned long cma_get_size(const struct
+ }
+
+ static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
+- int align_order)
++ unsigned int align_order)
+ {
+ if (align_order <= cma->order_per_bit)
+ return 0;
+@@ -62,17 +62,14 @@ static unsigned long cma_bitmap_aligned_
+ }
+
+ /*
+- * Find a PFN aligned to the specified order and return an offset represented in
+- * order_per_bits.
++ * Find the offset of the base PFN from the specified align_order.
++ * The value returned is represented in order_per_bits.
+ */
+ static unsigned long cma_bitmap_aligned_offset(const struct cma *cma,
+- int align_order)
++ unsigned int align_order)
+ {
+- if (align_order <= cma->order_per_bit)
+- return 0;
+-
+- return (ALIGN(cma->base_pfn, (1UL << align_order))
+- - cma->base_pfn) >> cma->order_per_bit;
++ return (cma->base_pfn & ((1UL << align_order) - 1))
++ >> cma->order_per_bit;
+ }
+
+ static unsigned long cma_bitmap_pages_to_bits(const struct cma *cma,
--- /dev/null
+From fc3dc67471461c0efcb1ed22fb7595121d65fad9 Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Tue, 13 Jun 2017 13:35:51 +0200
+Subject: fs/fcntl: f_setown, avoid undefined behaviour
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+commit fc3dc67471461c0efcb1ed22fb7595121d65fad9 upstream.
+
+fcntl(0, F_SETOWN, 0x80000000) triggers:
+UBSAN: Undefined behaviour in fs/fcntl.c:118:7
+negation of -2147483648 cannot be represented in type 'int':
+CPU: 1 PID: 18261 Comm: syz-executor Not tainted 4.8.1-0-syzkaller #1
+...
+Call Trace:
+...
+ [<ffffffffad8f0868>] ? f_setown+0x1d8/0x200
+ [<ffffffffad8f19a9>] ? SyS_fcntl+0x999/0xf30
+ [<ffffffffaed1fb00>] ? entry_SYSCALL_64_fastpath+0x23/0xc1
+
+Fix that by checking the arg parameter properly (against INT_MAX) before
+"who = -who". And return immediatelly with -EINVAL in case it is wrong.
+Note that according to POSIX we can return EINVAL:
+ http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html
+
+ [EINVAL]
+ The cmd argument is F_SETOWN and the value of the argument
+ is not valid as a process or process group identifier.
+
+[v2] returns an error, v1 used to fail silently
+[v3] implement proper check for the bad value INT_MIN
+
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Cc: Jeff Layton <jlayton@poochiereds.net>
+Cc: "J. Bruce Fields" <bfields@fieldses.org>
+Cc: Alexander Viro <viro@zeniv.linux.org.uk>
+Cc: linux-fsdevel@vger.kernel.org
+Signed-off-by: Jeff Layton <jlayton@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/fcntl.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/fs/fcntl.c
++++ b/fs/fcntl.c
+@@ -114,6 +114,10 @@ void f_setown(struct file *filp, unsigne
+ int who = arg;
+ type = PIDTYPE_PID;
+ if (who < 0) {
++ /* avoid overflow below */
++ if (who == INT_MIN)
++ return -EINVAL;
++
+ type = PIDTYPE_PGID;
+ who = -who;
+ }
--- /dev/null
+From 18365225f0440d09708ad9daade2ec11275c3df9 Mon Sep 17 00:00:00 2001
+From: Michal Hocko <mhocko@suse.com>
+Date: Fri, 12 May 2017 15:46:26 -0700
+Subject: hwpoison, memcg: forcibly uncharge LRU pages
+
+From: Michal Hocko <mhocko@suse.com>
+
+commit 18365225f0440d09708ad9daade2ec11275c3df9 upstream.
+
+Laurent Dufour has noticed that hwpoinsoned pages are kept charged. In
+his particular case he has hit a bad_page("page still charged to
+cgroup") when onlining a hwpoison page. While this looks like something
+that shouldn't happen in the first place because onlining hwpages and
+returning them to the page allocator makes only little sense it shows a
+real problem.
+
+hwpoison pages do not get freed usually so we do not uncharge them (at
+least not since commit 0a31bc97c80c ("mm: memcontrol: rewrite uncharge
+API")). Each charge pins memcg (since e8ea14cc6ead ("mm: memcontrol:
+take a css reference for each charged page")) as well and so the
+mem_cgroup and the associated state will never go away. Fix this leak
+by forcibly uncharging a LRU hwpoisoned page in delete_from_lru_cache().
+We also have to tweak uncharge_list because it cannot rely on zero ref
+count for these pages.
+
+[akpm@linux-foundation.org: coding-style fixes]
+Fixes: 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API")
+Link: http://lkml.kernel.org/r/20170502185507.GB19165@dhcp22.suse.cz
+Signed-off-by: Michal Hocko <mhocko@suse.com>
+Reported-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
+Tested-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
+Reviewed-by: Balbir Singh <bsingharora@gmail.com>
+Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/memcontrol.c | 2 +-
+ mm/memory-failure.c | 7 +++++++
+ 2 files changed, 8 insertions(+), 1 deletion(-)
+
+--- a/mm/memcontrol.c
++++ b/mm/memcontrol.c
+@@ -5531,7 +5531,7 @@ static void uncharge_list(struct list_he
+ next = page->lru.next;
+
+ VM_BUG_ON_PAGE(PageLRU(page), page);
+- VM_BUG_ON_PAGE(page_count(page), page);
++ VM_BUG_ON_PAGE(!PageHWPoison(page) && page_count(page), page);
+
+ if (!page->mem_cgroup)
+ continue;
+--- a/mm/memory-failure.c
++++ b/mm/memory-failure.c
+@@ -535,6 +535,13 @@ static int delete_from_lru_cache(struct
+ */
+ ClearPageActive(p);
+ ClearPageUnevictable(p);
++
++ /*
++ * Poisoned page might never drop its ref count to 0 so we have
++ * to uncharge it manually from its memcg.
++ */
++ mem_cgroup_uncharge(p);
++
+ /*
+ * drop the page count elevated by isolate_lru_page()
+ */
--- /dev/null
+From 999898355e08ae3b92dfd0a08db706e0c6703d30 Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Wed, 14 Dec 2016 15:06:07 -0800
+Subject: ipc: msg, make msgrcv work with LONG_MIN
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+commit 999898355e08ae3b92dfd0a08db706e0c6703d30 upstream.
+
+When LONG_MIN is passed to msgrcv, one would expect to recieve any
+message. But convert_mode does *msgtyp = -*msgtyp and -LONG_MIN is
+undefined. In particular, with my gcc -LONG_MIN produces -LONG_MIN
+again.
+
+So handle this case properly by assigning LONG_MAX to *msgtyp if
+LONG_MIN was specified as msgtyp to msgrcv.
+
+This code:
+ long msg[] = { 100, 200 };
+ int m = msgget(IPC_PRIVATE, IPC_CREAT | 0644);
+ msgsnd(m, &msg, sizeof(msg), 0);
+ msgrcv(m, &msg, sizeof(msg), LONG_MIN, 0);
+
+produces currently nothing:
+
+ msgget(IPC_PRIVATE, IPC_CREAT|0644) = 65538
+ msgsnd(65538, {100, "\310\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16, 0) = 0
+ msgrcv(65538, ...
+
+Except a UBSAN warning:
+
+ UBSAN: Undefined behaviour in ipc/msg.c:745:13
+ negation of -9223372036854775808 cannot be represented in type 'long int':
+
+With the patch, I see what I expect:
+
+ msgget(IPC_PRIVATE, IPC_CREAT|0644) = 0
+ msgsnd(0, {100, "\310\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16, 0) = 0
+ msgrcv(0, {100, "\310\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16, -9223372036854775808, 0) = 16
+
+Link: http://lkml.kernel.org/r/20161024082633.10148-1-jslaby@suse.cz
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Cc: Davidlohr Bueso <dave@stgolabs.net>
+Cc: Manfred Spraul <manfred@colorfullife.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ ipc/msg.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/ipc/msg.c
++++ b/ipc/msg.c
+@@ -763,7 +763,10 @@ static inline int convert_mode(long *msg
+ if (*msgtyp == 0)
+ return SEARCH_ANY;
+ if (*msgtyp < 0) {
+- *msgtyp = -*msgtyp;
++ if (*msgtyp == LONG_MIN) /* -LONG_MIN is undefined */
++ *msgtyp = LONG_MAX;
++ else
++ *msgtyp = -*msgtyp;
+ return SEARCH_LESSEQUAL;
+ }
+ if (msgflg & MSG_EXCEPT)
--- /dev/null
+From 561b5e0709e4a248c67d024d4d94b6e31e3edf2f Mon Sep 17 00:00:00 2001
+From: Michal Hocko <mhocko@suse.com>
+Date: Mon, 10 Jul 2017 15:49:51 -0700
+Subject: mm/mmap.c: do not blow on PROT_NONE MAP_FIXED holes in the stack
+
+From: Michal Hocko <mhocko@suse.com>
+
+commit 561b5e0709e4a248c67d024d4d94b6e31e3edf2f upstream.
+
+Commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas") has
+introduced a regression in some rust and Java environments which are
+trying to implement their own stack guard page. They are punching a new
+MAP_FIXED mapping inside the existing stack Vma.
+
+This will confuse expand_{downwards,upwards} into thinking that the
+stack expansion would in fact get us too close to an existing non-stack
+vma which is a correct behavior wrt safety. It is a real regression on
+the other hand.
+
+Let's work around the problem by considering PROT_NONE mapping as a part
+of the stack. This is a gros hack but overflowing to such a mapping
+would trap anyway an we only can hope that usespace knows what it is
+doing and handle it propely.
+
+Fixes: 1be7107fbe18 ("mm: larger stack guard gap, between vmas")
+Link: http://lkml.kernel.org/r/20170705182849.GA18027@dhcp22.suse.cz
+Signed-off-by: Michal Hocko <mhocko@suse.com>
+Debugged-by: Vlastimil Babka <vbabka@suse.cz>
+Cc: Ben Hutchings <ben@decadent.org.uk>
+Cc: Willy Tarreau <w@1wt.eu>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: Rik van Riel <riel@redhat.com>
+Cc: Hugh Dickins <hughd@google.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/mmap.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/mm/mmap.c
++++ b/mm/mmap.c
+@@ -2240,7 +2240,8 @@ int expand_upwards(struct vm_area_struct
+ gap_addr = TASK_SIZE;
+
+ next = vma->vm_next;
+- if (next && next->vm_start < gap_addr) {
++ if (next && next->vm_start < gap_addr &&
++ (next->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) {
+ if (!(next->vm_flags & VM_GROWSUP))
+ return -ENOMEM;
+ /* Check that both stack segments have the same anon_vma? */
+@@ -2324,7 +2325,8 @@ int expand_downwards(struct vm_area_stru
+ if (gap_addr > address)
+ return -ENOMEM;
+ prev = vma->vm_prev;
+- if (prev && prev->vm_end > gap_addr) {
++ if (prev && prev->vm_end > gap_addr &&
++ (prev->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) {
+ if (!(prev->vm_flags & VM_GROWSDOWN))
+ return -ENOMEM;
+ /* Check that both stack segments have the same anon_vma? */
--- /dev/null
+From b050e3769c6b4013bb937e879fc43bf1847ee819 Mon Sep 17 00:00:00 2001
+From: Vlastimil Babka <vbabka@suse.cz>
+Date: Wed, 15 Nov 2017 17:38:30 -0800
+Subject: mm, page_alloc: fix potential false positive in __zone_watermark_ok
+
+From: Vlastimil Babka <vbabka@suse.cz>
+
+commit b050e3769c6b4013bb937e879fc43bf1847ee819 upstream.
+
+Since commit 97a16fc82a7c ("mm, page_alloc: only enforce watermarks for
+order-0 allocations"), __zone_watermark_ok() check for high-order
+allocations will shortcut per-migratetype free list checks for
+ALLOC_HARDER allocations, and return true as long as there's free page
+of any migratetype. The intention is that ALLOC_HARDER can allocate
+from MIGRATE_HIGHATOMIC free lists, while normal allocations can't.
+
+However, as a side effect, the watermark check will then also return
+true when there are pages only on the MIGRATE_ISOLATE list, or (prior to
+CMA conversion to ZONE_MOVABLE) on the MIGRATE_CMA list. Since the
+allocation cannot actually obtain isolated pages, and might not be able
+to obtain CMA pages, this can result in a false positive.
+
+The condition should be rare and perhaps the outcome is not a fatal one.
+Still, it's better if the watermark check is correct. There also
+shouldn't be a performance tradeoff here.
+
+Link: http://lkml.kernel.org/r/20171102125001.23708-1-vbabka@suse.cz
+Fixes: 97a16fc82a7c ("mm, page_alloc: only enforce watermarks for order-0 allocations")
+Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+Acked-by: Mel Gorman <mgorman@techsingularity.net>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Cc: Rik van Riel <riel@redhat.com>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/page_alloc.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/mm/page_alloc.c
++++ b/mm/page_alloc.c
+@@ -2821,9 +2821,6 @@ bool __zone_watermark_ok(struct zone *z,
+ if (!area->nr_free)
+ continue;
+
+- if (alloc_harder)
+- return true;
+-
+ for (mt = 0; mt < MIGRATE_PCPTYPES; mt++) {
+ if (!list_empty(&area->free_list[mt]))
+ return true;
+@@ -2835,6 +2832,9 @@ bool __zone_watermark_ok(struct zone *z,
+ return true;
+ }
+ #endif
++ if (alloc_harder &&
++ !list_empty(&area->free_list[MIGRATE_HIGHATOMIC]))
++ return true;
+ }
+ return false;
+ }
--- /dev/null
+From 4b380c42f7d00a395feede754f0bc2292eebe6e5 Mon Sep 17 00:00:00 2001
+From: Kevin Cernekee <cernekee@chromium.org>
+Date: Sun, 3 Dec 2017 12:12:45 -0800
+Subject: netfilter: nfnetlink_cthelper: Add missing permission checks
+
+From: Kevin Cernekee <cernekee@chromium.org>
+
+commit 4b380c42f7d00a395feede754f0bc2292eebe6e5 upstream.
+
+The capability check in nfnetlink_rcv() verifies that the caller
+has CAP_NET_ADMIN in the namespace that "owns" the netlink socket.
+However, nfnl_cthelper_list is shared by all net namespaces on the
+system. An unprivileged user can create user and net namespaces
+in which he holds CAP_NET_ADMIN to bypass the netlink_net_capable()
+check:
+
+ $ nfct helper list
+ nfct v1.4.4: netlink error: Operation not permitted
+ $ vpnns -- nfct helper list
+ {
+ .name = ftp,
+ .queuenum = 0,
+ .l3protonum = 2,
+ .l4protonum = 6,
+ .priv_data_len = 24,
+ .status = enabled,
+ };
+
+Add capable() checks in nfnetlink_cthelper, as this is cleaner than
+trying to generalize the solution.
+
+Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Acked-by: Michal Kubecek <mkubecek@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/netfilter/nfnetlink_cthelper.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/net/netfilter/nfnetlink_cthelper.c
++++ b/net/netfilter/nfnetlink_cthelper.c
+@@ -17,6 +17,7 @@
+ #include <linux/types.h>
+ #include <linux/list.h>
+ #include <linux/errno.h>
++#include <linux/capability.h>
+ #include <net/netlink.h>
+ #include <net/sock.h>
+
+@@ -392,6 +393,9 @@ static int nfnl_cthelper_new(struct net
+ struct nfnl_cthelper *nlcth;
+ int ret = 0;
+
++ if (!capable(CAP_NET_ADMIN))
++ return -EPERM;
++
+ if (!tb[NFCTH_NAME] || !tb[NFCTH_TUPLE])
+ return -EINVAL;
+
+@@ -595,6 +599,9 @@ static int nfnl_cthelper_get(struct net
+ struct nfnl_cthelper *nlcth;
+ bool tuple_set = false;
+
++ if (!capable(CAP_NET_ADMIN))
++ return -EPERM;
++
+ if (nlh->nlmsg_flags & NLM_F_DUMP) {
+ struct netlink_dump_control c = {
+ .dump = nfnl_cthelper_dump_table,
+@@ -661,6 +668,9 @@ static int nfnl_cthelper_del(struct net
+ struct nfnl_cthelper *nlcth, *n;
+ int j = 0, ret;
+
++ if (!capable(CAP_NET_ADMIN))
++ return -EPERM;
++
+ if (tb[NFCTH_NAME])
+ helper_name = nla_data(tb[NFCTH_NAME]);
+
--- /dev/null
+From 916a27901de01446bcf57ecca4783f6cff493309 Mon Sep 17 00:00:00 2001
+From: Kevin Cernekee <cernekee@chromium.org>
+Date: Tue, 5 Dec 2017 15:42:41 -0800
+Subject: netfilter: xt_osf: Add missing permission checks
+
+From: Kevin Cernekee <cernekee@chromium.org>
+
+commit 916a27901de01446bcf57ecca4783f6cff493309 upstream.
+
+The capability check in nfnetlink_rcv() verifies that the caller
+has CAP_NET_ADMIN in the namespace that "owns" the netlink socket.
+However, xt_osf_fingers is shared by all net namespaces on the
+system. An unprivileged user can create user and net namespaces
+in which he holds CAP_NET_ADMIN to bypass the netlink_net_capable()
+check:
+
+ vpnns -- nfnl_osf -f /tmp/pf.os
+
+ vpnns -- nfnl_osf -f /tmp/pf.os -d
+
+These non-root operations successfully modify the systemwide OS
+fingerprint list. Add new capable() checks so that they can't.
+
+Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Acked-by: Michal Kubecek <mkubecek@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/netfilter/xt_osf.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/net/netfilter/xt_osf.c
++++ b/net/netfilter/xt_osf.c
+@@ -19,6 +19,7 @@
+ #include <linux/module.h>
+ #include <linux/kernel.h>
+
++#include <linux/capability.h>
+ #include <linux/if.h>
+ #include <linux/inetdevice.h>
+ #include <linux/ip.h>
+@@ -69,6 +70,9 @@ static int xt_osf_add_callback(struct ne
+ struct xt_osf_finger *kf = NULL, *sf;
+ int err = 0;
+
++ if (!capable(CAP_NET_ADMIN))
++ return -EPERM;
++
+ if (!osf_attrs[OSF_ATTR_FINGER])
+ return -EINVAL;
+
+@@ -113,6 +117,9 @@ static int xt_osf_remove_callback(struct
+ struct xt_osf_finger *sf;
+ int err = -ENOENT;
+
++ if (!capable(CAP_NET_ADMIN))
++ return -EPERM;
++
+ if (!osf_attrs[OSF_ATTR_FINGER])
+ return -EINVAL;
+
--- /dev/null
+From 54930dfeb46e978b447af0fb8ab4e181c1bf9d7a Mon Sep 17 00:00:00 2001
+From: Jeff Mahoney <jeffm@suse.com>
+Date: Thu, 22 Jun 2017 16:35:04 -0400
+Subject: reiserfs: don't preallocate blocks for extended attributes
+
+From: Jeff Mahoney <jeffm@suse.com>
+
+commit 54930dfeb46e978b447af0fb8ab4e181c1bf9d7a upstream.
+
+Most extended attributes will fit in a single block. More importantly,
+we drop the reference to the inode while holding the transaction open
+so the preallocated blocks aren't released. As a result, the inode
+may be evicted before it's removed from the transaction's prealloc list
+which can cause memory corruption.
+
+Signed-off-by: Jeff Mahoney <jeffm@suse.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/reiserfs/bitmap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/reiserfs/bitmap.c
++++ b/fs/reiserfs/bitmap.c
+@@ -1136,7 +1136,7 @@ static int determine_prealloc_size(reise
+ hint->prealloc_size = 0;
+
+ if (!hint->formatted_node && hint->preallocate) {
+- if (S_ISREG(hint->inode->i_mode)
++ if (S_ISREG(hint->inode->i_mode) && !IS_PRIVATE(hint->inode)
+ && hint->inode->i_size >=
+ REISERFS_SB(hint->th->t_super)->s_alloc_options.
+ preallocmin * hint->inode->i_sb->s_blocksize)
--- /dev/null
+From 08db141b5313ac2f64b844fb5725b8d81744b417 Mon Sep 17 00:00:00 2001
+From: Jeff Mahoney <jeffm@suse.com>
+Date: Thu, 22 Jun 2017 16:47:34 -0400
+Subject: reiserfs: fix race in prealloc discard
+
+From: Jeff Mahoney <jeffm@suse.com>
+
+commit 08db141b5313ac2f64b844fb5725b8d81744b417 upstream.
+
+The main loop in __discard_prealloc is protected by the reiserfs write lock
+which is dropped across schedules like the BKL it replaced. The problem is
+that it checks the value, calls a routine that schedules, and then adjusts
+the state. As a result, two threads that are calling
+reiserfs_prealloc_discard at the same time can race when one calls
+reiserfs_free_prealloc_block, the lock is dropped, and the other calls
+reiserfs_free_prealloc_block with the same block number. In the right
+circumstances, it can cause the prealloc count to go negative.
+
+Signed-off-by: Jeff Mahoney <jeffm@suse.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/reiserfs/bitmap.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/fs/reiserfs/bitmap.c
++++ b/fs/reiserfs/bitmap.c
+@@ -513,9 +513,17 @@ static void __discard_prealloc(struct re
+ "inode has negative prealloc blocks count.");
+ #endif
+ while (ei->i_prealloc_count > 0) {
+- reiserfs_free_prealloc_block(th, inode, ei->i_prealloc_block);
+- ei->i_prealloc_block++;
++ b_blocknr_t block_to_free;
++
++ /*
++ * reiserfs_free_prealloc_block can drop the write lock,
++ * which could allow another caller to free the same block.
++ * We can protect against it by modifying the prealloc
++ * state before calling it.
++ */
++ block_to_free = ei->i_prealloc_block++;
+ ei->i_prealloc_count--;
++ reiserfs_free_prealloc_block(th, inode, block_to_free);
+ dirty = 1;
+ }
+ if (dirty)
--- /dev/null
+From eef9ffdf9cd39b2986367bc8395e2772bc1284ba Mon Sep 17 00:00:00 2001
+From: Johannes Thumshirn <jthumshirn@suse.de>
+Date: Mon, 9 Oct 2017 13:33:19 +0200
+Subject: scsi: libiscsi: fix shifting of DID_REQUEUE host byte
+
+From: Johannes Thumshirn <jthumshirn@suse.de>
+
+commit eef9ffdf9cd39b2986367bc8395e2772bc1284ba upstream.
+
+The SCSI host byte should be shifted left by 16 in order to have
+scsi_decide_disposition() do the right thing (.i.e. requeue the
+command).
+
+Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
+Fixes: 661134ad3765 ("[SCSI] libiscsi, bnx2i: make bound ep check common")
+Cc: Lee Duncan <lduncan@suse.com>
+Cc: Hannes Reinecke <hare@suse.de>
+Cc: Bart Van Assche <Bart.VanAssche@sandisk.com>
+Cc: Chris Leech <cleech@redhat.com>
+Acked-by: Lee Duncan <lduncan@suse.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/libiscsi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/scsi/libiscsi.c
++++ b/drivers/scsi/libiscsi.c
+@@ -1727,7 +1727,7 @@ int iscsi_queuecommand(struct Scsi_Host
+
+ if (test_bit(ISCSI_SUSPEND_BIT, &conn->suspend_tx)) {
+ reason = FAILURE_SESSION_IN_RECOVERY;
+- sc->result = DID_REQUEUE;
++ sc->result = DID_REQUEUE << 16;
+ goto fault;
+ }
+
prevent-timer-value-0-for-mwaitx.patch
drivers-base-cacheinfo-fix-x86-with-config_of-enabled.patch
drivers-base-cacheinfo-fix-boot-error-message-when-acpi-is-enabled.patch
+mm-mmap.c-do-not-blow-on-prot_none-map_fixed-holes-in-the-stack.patch
+hwpoison-memcg-forcibly-uncharge-lru-pages.patch
+cma-fix-calculation-of-aligned-offset.patch
+mm-page_alloc-fix-potential-false-positive-in-__zone_watermark_ok.patch
+ipc-msg-make-msgrcv-work-with-long_min.patch
+acpi-scan-prefer-devices-without-_hid-_cid-for-_adr-matching.patch
+acpica-namespace-fix-operand-cache-leak.patch
+netfilter-nfnetlink_cthelper-add-missing-permission-checks.patch
+netfilter-xt_osf-add-missing-permission-checks.patch
+reiserfs-fix-race-in-prealloc-discard.patch
+reiserfs-don-t-preallocate-blocks-for-extended-attributes.patch
+fs-fcntl-f_setown-avoid-undefined-behaviour.patch
+scsi-libiscsi-fix-shifting-of-did_requeue-host-byte.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
