]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.4-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 26 May 2018 13:25:04 +0000 (15:25 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 26 May 2018 13:25:04 +0000 (15:25 +0200)
added patches:
ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping.patch
kasan-fix-memory-hotplug-during-boot.patch
kernel-signal.c-avoid-undefined-behaviour-in-kill_something_info.patch
kernel-sys.c-fix-potential-spectre-v1-issue.patch
libata-blacklist-micron-500it-ssd-with-mu01-firmware.patch
libata-blacklist-some-sandisk-ssds-for-ncq.patch
mmc-sdhci-iproc-fix-32bit-writes-for-transfer_mode-register.patch
revert-ipc-shm-fix-shmat-mmap-nil-page-protection.patch
xen-swiotlb-fix-the-check-condition-for-xen_swiotlb_free_coherent.patch
xfs-remove-racy-hasattr-check-from-attr-ops.patch

queue-4.4/ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping.patch [new file with mode: 0644]
queue-4.4/kasan-fix-memory-hotplug-during-boot.patch [new file with mode: 0644]
queue-4.4/kernel-signal.c-avoid-undefined-behaviour-in-kill_something_info.patch [new file with mode: 0644]
queue-4.4/kernel-sys.c-fix-potential-spectre-v1-issue.patch [new file with mode: 0644]
queue-4.4/libata-blacklist-micron-500it-ssd-with-mu01-firmware.patch [new file with mode: 0644]
queue-4.4/libata-blacklist-some-sandisk-ssds-for-ncq.patch [new file with mode: 0644]
queue-4.4/mmc-sdhci-iproc-fix-32bit-writes-for-transfer_mode-register.patch [new file with mode: 0644]
queue-4.4/revert-ipc-shm-fix-shmat-mmap-nil-page-protection.patch [new file with mode: 0644]
queue-4.4/series
queue-4.4/xen-swiotlb-fix-the-check-condition-for-xen_swiotlb_free_coherent.patch [new file with mode: 0644]
queue-4.4/xfs-remove-racy-hasattr-check-from-attr-ops.patch [new file with mode: 0644]

diff --git a/queue-4.4/ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping.patch b/queue-4.4/ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping.patch
new file mode 100644 (file)
index 0000000..4c63019
--- /dev/null
@@ -0,0 +1,51 @@
+From 8f89c007b6dec16a1793cb88de88fcc02117bbbc Mon Sep 17 00:00:00 2001
+From: Davidlohr Bueso <dave@stgolabs.net>
+Date: Fri, 25 May 2018 14:47:30 -0700
+Subject: ipc/shm: fix shmat() nil address after round-down when remapping
+
+From: Davidlohr Bueso <dave@stgolabs.net>
+
+commit 8f89c007b6dec16a1793cb88de88fcc02117bbbc upstream.
+
+shmat()'s SHM_REMAP option forbids passing a nil address for; this is in
+fact the very first thing we check for.  Andrea reported that for
+SHM_RND|SHM_REMAP cases we can end up bypassing the initial addr check,
+but we need to check again if the address was rounded down to nil.  As
+of this patch, such cases will return -EINVAL.
+
+Link: http://lkml.kernel.org/r/20180503204934.kk63josdu6u53fbd@linux-n805
+Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
+Reported-by: Andrea Arcangeli <aarcange@redhat.com>
+Cc: Joe Lawrence <joe.lawrence@redhat.com>
+Cc: Manfred Spraul <manfred@colorfullife.com>
+Cc: <stable@vger.kernel.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>
+
+---
+ ipc/shm.c |   12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/ipc/shm.c
++++ b/ipc/shm.c
+@@ -1113,9 +1113,17 @@ long do_shmat(int shmid, char __user *sh
+               goto out;
+       else if ((addr = (ulong)shmaddr)) {
+               if (addr & (shmlba - 1)) {
+-                      if (shmflg & SHM_RND)
++                      if (shmflg & SHM_RND) {
+                               addr &= ~(shmlba - 1);  /* round down */
+-                      else
++
++                              /*
++                               * Ensure that the round-down is non-nil
++                               * when remapping. This can happen for
++                               * cases when addr < shmlba.
++                               */
++                              if (!addr && (shmflg & SHM_REMAP))
++                                      goto out;
++                      } else
+ #ifndef __ARCH_FORCE_SHMLBA
+                               if (addr & ~PAGE_MASK)
+ #endif
diff --git a/queue-4.4/kasan-fix-memory-hotplug-during-boot.patch b/queue-4.4/kasan-fix-memory-hotplug-during-boot.patch
new file mode 100644 (file)
index 0000000..708ec41
--- /dev/null
@@ -0,0 +1,41 @@
+From 3f1959721558a976aaf9c2024d5bc884e6411bf7 Mon Sep 17 00:00:00 2001
+From: David Hildenbrand <david@redhat.com>
+Date: Fri, 25 May 2018 14:48:11 -0700
+Subject: kasan: fix memory hotplug during boot
+
+From: David Hildenbrand <david@redhat.com>
+
+commit 3f1959721558a976aaf9c2024d5bc884e6411bf7 upstream.
+
+Using module_init() is wrong.  E.g.  ACPI adds and onlines memory before
+our memory notifier gets registered.
+
+This makes sure that ACPI memory detected during boot up will not result
+in a kernel crash.
+
+Easily reproducible with QEMU, just specify a DIMM when starting up.
+
+Link: http://lkml.kernel.org/r/20180522100756.18478-3-david@redhat.com
+Fixes: 786a8959912e ("kasan: disable memory hotplug")
+Signed-off-by: David Hildenbrand <david@redhat.com>
+Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
+Cc: Alexander Potapenko <glider@google.com>
+Cc: Dmitry Vyukov <dvyukov@google.com>
+Cc: <stable@vger.kernel.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/kasan/kasan.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/kasan/kasan.c
++++ b/mm/kasan/kasan.c
+@@ -548,5 +548,5 @@ static int __init kasan_memhotplug_init(
+       return 0;
+ }
+-module_init(kasan_memhotplug_init);
++core_initcall(kasan_memhotplug_init);
+ #endif
diff --git a/queue-4.4/kernel-signal.c-avoid-undefined-behaviour-in-kill_something_info.patch b/queue-4.4/kernel-signal.c-avoid-undefined-behaviour-in-kill_something_info.patch
new file mode 100644 (file)
index 0000000..abca0ef
--- /dev/null
@@ -0,0 +1,55 @@
+From 4ea77014af0d6205b05503d1c7aac6eace11d473 Mon Sep 17 00:00:00 2001
+From: zhongjiang <zhongjiang@huawei.com>
+Date: Mon, 10 Jul 2017 15:52:57 -0700
+Subject: kernel/signal.c: avoid undefined behaviour in kill_something_info
+
+From: zhongjiang <zhongjiang@huawei.com>
+
+commit 4ea77014af0d6205b05503d1c7aac6eace11d473 upstream.
+
+When running kill(72057458746458112, 0) in userspace I hit the following
+issue.
+
+  UBSAN: Undefined behaviour in kernel/signal.c:1462:11
+  negation of -2147483648 cannot be represented in type 'int':
+  CPU: 226 PID: 9849 Comm: test Tainted: G    B          ---- -------   3.10.0-327.53.58.70.x86_64_ubsan+ #116
+  Hardware name: Huawei Technologies Co., Ltd. RH8100 V3/BC61PBIA, BIOS BLHSV028 11/11/2014
+  Call Trace:
+    dump_stack+0x19/0x1b
+    ubsan_epilogue+0xd/0x50
+    __ubsan_handle_negate_overflow+0x109/0x14e
+    SYSC_kill+0x43e/0x4d0
+    SyS_kill+0xe/0x10
+    system_call_fastpath+0x16/0x1b
+
+Add code to avoid the UBSAN detection.
+
+[akpm@linux-foundation.org: tweak comment]
+Link: http://lkml.kernel.org/r/1496670008-59084-1-git-send-email-zhongjiang@huawei.com
+Signed-off-by: zhongjiang <zhongjiang@huawei.com>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Xishi Qiu <qiuxishi@huawei.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/signal.c |    4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/kernel/signal.c
++++ b/kernel/signal.c
+@@ -1392,6 +1392,10 @@ static int kill_something_info(int sig,
+               return ret;
+       }
++      /* -INT_MIN is undefined.  Exclude this case to avoid a UBSAN warning */
++      if (pid == INT_MIN)
++              return -ESRCH;
++
+       read_lock(&tasklist_lock);
+       if (pid != -1) {
+               ret = __kill_pgrp_info(sig, info,
diff --git a/queue-4.4/kernel-sys.c-fix-potential-spectre-v1-issue.patch b/queue-4.4/kernel-sys.c-fix-potential-spectre-v1-issue.patch
new file mode 100644 (file)
index 0000000..97d44a2
--- /dev/null
@@ -0,0 +1,61 @@
+From 23d6aef74da86a33fa6bb75f79565e0a16ee97c2 Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Fri, 25 May 2018 14:47:57 -0700
+Subject: kernel/sys.c: fix potential Spectre v1 issue
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+commit 23d6aef74da86a33fa6bb75f79565e0a16ee97c2 upstream.
+
+`resource' can be controlled by user-space, hence leading to a potential
+exploitation of the Spectre variant 1 vulnerability.
+
+This issue was detected with the help of Smatch:
+
+  kernel/sys.c:1474 __do_compat_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)
+  kernel/sys.c:1455 __do_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)
+
+Fix this by sanitizing *resource* before using it to index
+current->signal->rlim
+
+Notice that given that speculation windows are large, the policy is to
+kill the speculation on the first load and not worry if it can be
+completed with a dependent load/store [1].
+
+[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
+
+Link: http://lkml.kernel.org/r/20180515030038.GA11822@embeddedor.com
+Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Alexei Starovoitov <ast@kernel.org>
+Cc: Dan Williams <dan.j.williams@intel.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: <stable@vger.kernel.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>
+
+---
+ kernel/sys.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/kernel/sys.c
++++ b/kernel/sys.c
+@@ -53,6 +53,8 @@
+ #include <linux/uidgid.h>
+ #include <linux/cred.h>
++#include <linux/nospec.h>
++
+ #include <linux/kmsg_dump.h>
+ /* Move somewhere else to avoid recompiling? */
+ #include <generated/utsrelease.h>
+@@ -1311,6 +1313,7 @@ SYSCALL_DEFINE2(old_getrlimit, unsigned
+       if (resource >= RLIM_NLIMITS)
+               return -EINVAL;
++      resource = array_index_nospec(resource, RLIM_NLIMITS);
+       task_lock(current->group_leader);
+       x = current->signal->rlim[resource];
+       task_unlock(current->group_leader);
diff --git a/queue-4.4/libata-blacklist-micron-500it-ssd-with-mu01-firmware.patch b/queue-4.4/libata-blacklist-micron-500it-ssd-with-mu01-firmware.patch
new file mode 100644 (file)
index 0000000..36b82c7
--- /dev/null
@@ -0,0 +1,66 @@
+From 136d769e0b3475d71350aa3648a116a6ee7a8f6c Mon Sep 17 00:00:00 2001
+From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Date: Sat, 19 May 2018 22:29:36 +0100
+Subject: libata: blacklist Micron 500IT SSD with MU01 firmware
+
+From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+
+commit 136d769e0b3475d71350aa3648a116a6ee7a8f6c upstream.
+
+While whitelisting Micron M500DC drives, the tweaked blacklist entry
+enabled queued TRIM from M500IT variants also. But these do not support
+queued TRIM. And while using those SSDs with the latest kernel we have
+seen errors and even the partition table getting corrupted.
+
+Some part from the dmesg:
+[    6.727384] ata1.00: ATA-9: Micron_M500IT_MTFDDAK060MBD, MU01, max UDMA/133
+[    6.727390] ata1.00: 117231408 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
+[    6.741026] ata1.00: supports DRM functions and may not be fully accessible
+[    6.759887] ata1.00: configured for UDMA/133
+[    6.762256] scsi 0:0:0:0: Direct-Access     ATA      Micron_M500IT_MT MU01 PQ: 0 ANSI: 5
+
+and then for the error:
+[  120.860334] ata1.00: exception Emask 0x1 SAct 0x7ffc0007 SErr 0x0 action 0x6 frozen
+[  120.860338] ata1.00: irq_stat 0x40000008
+[  120.860342] ata1.00: failed command: SEND FPDMA QUEUED
+[  120.860351] ata1.00: cmd 64/01:00:00:00:00/00:00:00:00:00/a0 tag 0 ncq dma 512 out
+         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x5 (timeout)
+[  120.860353] ata1.00: status: { DRDY }
+[  120.860543] ata1: hard resetting link
+[  121.166128] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
+[  121.166376] ata1.00: supports DRM functions and may not be fully accessible
+[  121.186238] ata1.00: supports DRM functions and may not be fully accessible
+[  121.204445] ata1.00: configured for UDMA/133
+[  121.204454] ata1.00: device reported invalid CHS sector 0
+[  121.204541] sd 0:0:0:0: [sda] tag#18 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
+[  121.204546] sd 0:0:0:0: [sda] tag#18 Sense Key : 0x5 [current]
+[  121.204550] sd 0:0:0:0: [sda] tag#18 ASC=0x21 ASCQ=0x4
+[  121.204555] sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x93 93 08 00 00 00 00 00 04 28 80 00 00 00 30 00 00
+[  121.204559] print_req_error: I/O error, dev sda, sector 272512
+
+After few reboots with these errors, and the SSD is corrupted.
+After blacklisting it, the errors are not seen and the SSD does not get
+corrupted any more.
+
+Fixes: 243918be6393 ("libata: Do not blacklist Micron M500DC")
+Cc: Martin K. Petersen <martin.petersen@oracle.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/libata-core.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -4251,6 +4251,8 @@ static const struct ata_blacklist_entry
+       { "SanDisk SD7UB3Q*G1001",      NULL,   ATA_HORKAGE_NOLPM, },
+       /* devices that don't properly handle queued TRIM commands */
++      { "Micron_M500IT_*",            "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
++                                              ATA_HORKAGE_ZERO_AFTER_TRIM, },
+       { "Micron_M500_*",              NULL,   ATA_HORKAGE_NO_NCQ_TRIM |
+                                               ATA_HORKAGE_ZERO_AFTER_TRIM, },
+       { "Crucial_CT*M500*",           NULL,   ATA_HORKAGE_NO_NCQ_TRIM |
diff --git a/queue-4.4/libata-blacklist-some-sandisk-ssds-for-ncq.patch b/queue-4.4/libata-blacklist-some-sandisk-ssds-for-ncq.patch
new file mode 100644 (file)
index 0000000..be4c4e0
--- /dev/null
@@ -0,0 +1,35 @@
+From 322579dcc865b94b47345ad1b6002ad167f85405 Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Tue, 8 May 2018 14:21:56 -0700
+Subject: libata: Blacklist some Sandisk SSDs for NCQ
+
+From: Tejun Heo <tj@kernel.org>
+
+commit 322579dcc865b94b47345ad1b6002ad167f85405 upstream.
+
+Sandisk SSDs SD7SN6S256G and SD8SN8U256G are regularly locking up
+regularly under sustained moderate load with NCQ enabled.  Blacklist
+for now.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Reported-by: Dave Jones <davej@codemonkey.org.uk>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/libata-core.c |    4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -4187,6 +4187,10 @@ static const struct ata_blacklist_entry
+       /* https://bugzilla.kernel.org/show_bug.cgi?id=15573 */
+       { "C300-CTFDDAC128MAG", "0001",         ATA_HORKAGE_NONCQ, },
++      /* Some Sandisk SSDs lock up hard with NCQ enabled.  Reported on
++         SD7SN6S256G and SD8SN8U256G */
++      { "SanDisk SD[78]SN*G", NULL,           ATA_HORKAGE_NONCQ, },
++
+       /* devices which puke on READ_NATIVE_MAX */
+       { "HDS724040KLSA80",    "KFAOA20N",     ATA_HORKAGE_BROKEN_HPA, },
+       { "WDC WD3200JD-00KLB0", "WD-WCAMR1130137", ATA_HORKAGE_BROKEN_HPA },
diff --git a/queue-4.4/mmc-sdhci-iproc-fix-32bit-writes-for-transfer_mode-register.patch b/queue-4.4/mmc-sdhci-iproc-fix-32bit-writes-for-transfer_mode-register.patch
new file mode 100644 (file)
index 0000000..6920cbb
--- /dev/null
@@ -0,0 +1,103 @@
+From 5f651b870485ee60f5abbbd85195a6852978894a Mon Sep 17 00:00:00 2001
+From: Corneliu Doban <corneliu.doban@broadcom.com>
+Date: Fri, 18 May 2018 15:03:56 -0700
+Subject: mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register
+
+From: Corneliu Doban <corneliu.doban@broadcom.com>
+
+commit 5f651b870485ee60f5abbbd85195a6852978894a upstream.
+
+When the host controller accepts only 32bit writes, the value of the
+16bit TRANSFER_MODE register, that has the same 32bit address as the
+16bit COMMAND register, needs to be saved and it will be written
+in a 32bit write together with the command as this will trigger the
+host to send the command on the SD interface.
+When sending the tuning command, TRANSFER_MODE is written and then
+sdhci_set_transfer_mode reads it back to clear AUTO_CMD12 bit and
+write it again resulting in wrong value to be written because the
+initial write value was saved in a shadow and the read-back returned
+a wrong value, from the register.
+Fix sdhci_iproc_readw to return the saved value of TRANSFER_MODE
+when a saved value exist.
+Same fix for read of BLOCK_SIZE and BLOCK_COUNT registers, that are
+saved for a different reason, although a scenario that will cause the
+mentioned problem on this registers is not probable.
+
+Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver")
+Signed-off-by: Corneliu Doban <corneliu.doban@broadcom.com>
+Signed-off-by: Scott Branden <scott.branden@broadcom.com>
+Cc: stable@vger.kernel.org # v4.1+
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-iproc.c |   30 +++++++++++++++++++++++++-----
+ 1 file changed, 25 insertions(+), 5 deletions(-)
+
+--- a/drivers/mmc/host/sdhci-iproc.c
++++ b/drivers/mmc/host/sdhci-iproc.c
+@@ -32,6 +32,8 @@ struct sdhci_iproc_host {
+       const struct sdhci_iproc_data *data;
+       u32 shadow_cmd;
+       u32 shadow_blk;
++      bool is_cmd_shadowed;
++      bool is_blk_shadowed;
+ };
+ #define REG_OFFSET_IN_BITS(reg) ((reg) << 3 & 0x18)
+@@ -47,8 +49,22 @@ static inline u32 sdhci_iproc_readl(stru
+ static u16 sdhci_iproc_readw(struct sdhci_host *host, int reg)
+ {
+-      u32 val = sdhci_iproc_readl(host, (reg & ~3));
+-      u16 word = val >> REG_OFFSET_IN_BITS(reg) & 0xffff;
++      struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
++      struct sdhci_iproc_host *iproc_host = sdhci_pltfm_priv(pltfm_host);
++      u32 val;
++      u16 word;
++
++      if ((reg == SDHCI_TRANSFER_MODE) && iproc_host->is_cmd_shadowed) {
++              /* Get the saved transfer mode */
++              val = iproc_host->shadow_cmd;
++      } else if ((reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) &&
++                 iproc_host->is_blk_shadowed) {
++              /* Get the saved block info */
++              val = iproc_host->shadow_blk;
++      } else {
++              val = sdhci_iproc_readl(host, (reg & ~3));
++      }
++      word = val >> REG_OFFSET_IN_BITS(reg) & 0xffff;
+       return word;
+ }
+@@ -104,13 +120,15 @@ static void sdhci_iproc_writew(struct sd
+       if (reg == SDHCI_COMMAND) {
+               /* Write the block now as we are issuing a command */
+-              if (iproc_host->shadow_blk != 0) {
++              if (iproc_host->is_blk_shadowed) {
+                       sdhci_iproc_writel(host, iproc_host->shadow_blk,
+                               SDHCI_BLOCK_SIZE);
+-                      iproc_host->shadow_blk = 0;
++                      iproc_host->is_blk_shadowed = false;
+               }
+               oldval = iproc_host->shadow_cmd;
+-      } else if (reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) {
++              iproc_host->is_cmd_shadowed = false;
++      } else if ((reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) &&
++                 iproc_host->is_blk_shadowed) {
+               /* Block size and count are stored in shadow reg */
+               oldval = iproc_host->shadow_blk;
+       } else {
+@@ -122,9 +140,11 @@ static void sdhci_iproc_writew(struct sd
+       if (reg == SDHCI_TRANSFER_MODE) {
+               /* Save the transfer mode until the command is issued */
+               iproc_host->shadow_cmd = newval;
++              iproc_host->is_cmd_shadowed = true;
+       } else if (reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) {
+               /* Save the block info until the command is issued */
+               iproc_host->shadow_blk = newval;
++              iproc_host->is_blk_shadowed = true;
+       } else {
+               /* Command or other regular 32-bit write */
+               sdhci_iproc_writel(host, newval, reg & ~3);
diff --git a/queue-4.4/revert-ipc-shm-fix-shmat-mmap-nil-page-protection.patch b/queue-4.4/revert-ipc-shm-fix-shmat-mmap-nil-page-protection.patch
new file mode 100644 (file)
index 0000000..775c516
--- /dev/null
@@ -0,0 +1,69 @@
+From a73ab244f0dad8fffb3291b905f73e2d3eaa7c00 Mon Sep 17 00:00:00 2001
+From: Davidlohr Bueso <dave@stgolabs.net>
+Date: Fri, 25 May 2018 14:47:27 -0700
+Subject: Revert "ipc/shm: Fix shmat mmap nil-page protection"
+
+From: Davidlohr Bueso <dave@stgolabs.net>
+
+commit a73ab244f0dad8fffb3291b905f73e2d3eaa7c00 upstream.
+
+Patch series "ipc/shm: shmat() fixes around nil-page".
+
+These patches fix two issues reported[1] a while back by Joe and Andrea
+around how shmat(2) behaves with nil-page.
+
+The first reverts a commit that it was incorrectly thought that mapping
+nil-page (address=0) was a no no with MAP_FIXED.  This is not the case,
+with the exception of SHM_REMAP; which is address in the second patch.
+
+I chose two patches because it is easier to backport and it explicitly
+reverts bogus behaviour.  Both patches ought to be in -stable and ltp
+testcases need updated (the added testcase around the cve can be
+modified to just test for SHM_RND|SHM_REMAP).
+
+[1] lkml.kernel.org/r/20180430172152.nfa564pvgpk3ut7p@linux-n805
+
+This patch (of 2):
+
+Commit 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection")
+worked on the idea that we should not be mapping as root addr=0 and
+MAP_FIXED.  However, it was reported that this scenario is in fact
+valid, thus making the patch both bogus and breaks userspace as well.
+
+For example X11's libint10.so relies on shmat(1, SHM_RND) for lowmem
+initialization[1].
+
+[1] https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/int10/linux.c#n347
+Link: http://lkml.kernel.org/r/20180503203243.15045-2-dave@stgolabs.net
+Fixes: 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection")
+Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
+Reported-by: Joe Lawrence <joe.lawrence@redhat.com>
+Reported-by: Andrea Arcangeli <aarcange@redhat.com>
+Cc: Manfred Spraul <manfred@colorfullife.com>
+Cc: <stable@vger.kernel.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>
+
+---
+ ipc/shm.c |    9 ++-------
+ 1 file changed, 2 insertions(+), 7 deletions(-)
+
+--- a/ipc/shm.c
++++ b/ipc/shm.c
+@@ -1113,13 +1113,8 @@ long do_shmat(int shmid, char __user *sh
+               goto out;
+       else if ((addr = (ulong)shmaddr)) {
+               if (addr & (shmlba - 1)) {
+-                      /*
+-                       * Round down to the nearest multiple of shmlba.
+-                       * For sane do_mmap_pgoff() parameters, avoid
+-                       * round downs that trigger nil-page and MAP_FIXED.
+-                       */
+-                      if ((shmflg & SHM_RND) && addr >= shmlba)
+-                              addr &= ~(shmlba - 1);
++                      if (shmflg & SHM_RND)
++                              addr &= ~(shmlba - 1);  /* round down */
+                       else
+ #ifndef __ARCH_FORCE_SHMLBA
+                               if (addr & ~PAGE_MASK)
index 130f0981c642473d9e7b6d1d07a752b05e9b7b82..abc132ce6994363669d3c8213ba42009fe1950d1 100644 (file)
@@ -4,4 +4,14 @@ kvm-fix-spelling-mistake-cop_unsuable-cop_unusable.patch
 affs_lookup-close-a-race-with-affs_remove_link.patch
 aio-fix-io_destroy-2-vs.-lookup_ioctx-race.patch
 alsa-timer-fix-pause-event-notification.patch
+mmc-sdhci-iproc-fix-32bit-writes-for-transfer_mode-register.patch
+libata-blacklist-some-sandisk-ssds-for-ncq.patch
+libata-blacklist-micron-500it-ssd-with-mu01-firmware.patch
+xen-swiotlb-fix-the-check-condition-for-xen_swiotlb_free_coherent.patch
+revert-ipc-shm-fix-shmat-mmap-nil-page-protection.patch
+ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping.patch
+kasan-fix-memory-hotplug-during-boot.patch
+kernel-sys.c-fix-potential-spectre-v1-issue.patch
+kernel-signal.c-avoid-undefined-behaviour-in-kill_something_info.patch
+xfs-remove-racy-hasattr-check-from-attr-ops.patch
 do-d_instantiate-unlock_new_inode-combinations-safely.patch
diff --git a/queue-4.4/xen-swiotlb-fix-the-check-condition-for-xen_swiotlb_free_coherent.patch b/queue-4.4/xen-swiotlb-fix-the-check-condition-for-xen_swiotlb_free_coherent.patch
new file mode 100644 (file)
index 0000000..742648e
--- /dev/null
@@ -0,0 +1,44 @@
+From 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 Mon Sep 17 00:00:00 2001
+From: Joe Jin <joe.jin@oracle.com>
+Date: Thu, 17 May 2018 12:33:28 -0700
+Subject: xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent
+
+From: Joe Jin <joe.jin@oracle.com>
+
+commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.
+
+When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
+but Dom Heap is increased by the same size. Tracing raidconfig we found
+that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
+to apply memory. If the memory allocated by Dom0 is not in the DMA area,
+it will exchange memory with Xen to meet the requiment. Later drivers
+call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()
+the check condition (dev_addr + size - 1 <= dma_mask) is always false,
+it prevents calling xen_destroy_contiguous_region() to return the memory
+to the Xen DMA heap.
+
+This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing
+coherent alloc/dealloc check before swizzling the MFNs.".
+
+Signed-off-by: Joe Jin <joe.jin@oracle.com>
+Tested-by: John Sobecki <john.sobecki@oracle.com>
+Reviewed-by: Rzeszutek Wilk <konrad.wilk@oracle.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/xen/swiotlb-xen.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/xen/swiotlb-xen.c
++++ b/drivers/xen/swiotlb-xen.c
+@@ -359,7 +359,7 @@ xen_swiotlb_free_coherent(struct device
+        * physical address */
+       phys = xen_bus_to_phys(dev_addr);
+-      if (((dev_addr + size - 1 > dma_mask)) ||
++      if (((dev_addr + size - 1 <= dma_mask)) ||
+           range_straddles_page_boundary(phys, size))
+               xen_destroy_contiguous_region(phys, order);
diff --git a/queue-4.4/xfs-remove-racy-hasattr-check-from-attr-ops.patch b/queue-4.4/xfs-remove-racy-hasattr-check-from-attr-ops.patch
new file mode 100644 (file)
index 0000000..d639a74
--- /dev/null
@@ -0,0 +1,62 @@
+From 5a93790d4e2df73e30c965ec6e49be82fc3ccfce Mon Sep 17 00:00:00 2001
+From: Brian Foster <bfoster@redhat.com>
+Date: Wed, 25 Jan 2017 07:53:43 -0800
+Subject: xfs: remove racy hasattr check from attr ops
+
+From: Brian Foster <bfoster@redhat.com>
+
+commit 5a93790d4e2df73e30c965ec6e49be82fc3ccfce upstream.
+
+xfs_attr_[get|remove]() have unlocked attribute fork checks to optimize
+away a lock cycle in cases where the fork does not exist or is otherwise
+empty. This check is not safe, however, because an attribute fork short
+form to extent format conversion includes a transient state that causes
+the xfs_inode_hasattr() check to fail. Specifically,
+xfs_attr_shortform_to_leaf() creates an empty extent format attribute
+fork and then adds the existing shortform attributes to it.
+
+This means that lookup of an existing xattr can spuriously return
+-ENOATTR when racing against a setxattr that causes the associated
+format conversion. This was originally reproduced by an untar on a
+particularly configured glusterfs volume, but can also be reproduced on
+demand with properly crafted xattr requests.
+
+The format conversion occurs under the exclusive ilock. xfs_attr_get()
+and xfs_attr_remove() already have the proper locking and checks further
+down in the functions to handle this situation correctly. Drop the
+unlocked checks to avoid the spurious failure and rely on the existing
+logic.
+
+Signed-off-by: Brian Foster <bfoster@redhat.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
+Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
+Cc: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/xfs/libxfs/xfs_attr.c |    6 ------
+ 1 file changed, 6 deletions(-)
+
+--- a/fs/xfs/libxfs/xfs_attr.c
++++ b/fs/xfs/libxfs/xfs_attr.c
+@@ -130,9 +130,6 @@ xfs_attr_get(
+       if (XFS_FORCED_SHUTDOWN(ip->i_mount))
+               return -EIO;
+-      if (!xfs_inode_hasattr(ip))
+-              return -ENOATTR;
+-
+       error = xfs_attr_args_init(&args, ip, name, flags);
+       if (error)
+               return error;
+@@ -417,9 +414,6 @@ xfs_attr_remove(
+       if (XFS_FORCED_SHUTDOWN(dp->i_mount))
+               return -EIO;
+-      if (!xfs_inode_hasattr(dp))
+-              return -ENOATTR;
+-
+       error = xfs_attr_args_init(&args, dp, name, flags);
+       if (error)
+               return error;