From: Greg Kroah-Hartman Date: Sat, 26 May 2018 13:25:21 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v3.18.111~28 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=9c4906e50f47d802c96343e508b890efb8705acc;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: drm-vmwgfx-fix-32-bit-vmw_port_hb_-macros.patch ib-hfi1-use-after-free-race-condition-in-send-context-error-path.patch 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 mmc-sdhci-iproc-remove-hard-coded-mmc-cap-1.8v.patch revert-ipc-shm-fix-shmat-mmap-nil-page-protection.patch xen-swiotlb-fix-the-check-condition-for-xen_swiotlb_free_coherent.patch --- diff --git a/queue-4.9/drm-vmwgfx-fix-32-bit-vmw_port_hb_-macros.patch b/queue-4.9/drm-vmwgfx-fix-32-bit-vmw_port_hb_-macros.patch new file mode 100644 index 00000000000..3ec4a358ae2 --- /dev/null +++ b/queue-4.9/drm-vmwgfx-fix-32-bit-vmw_port_hb_-macros.patch @@ -0,0 +1,77 @@ +From 938ae7259c908ad031da35d551da297640bb640c Mon Sep 17 00:00:00 2001 +From: Thomas Hellstrom +Date: Wed, 23 May 2018 16:11:24 +0200 +Subject: drm/vmwgfx: Fix 32-bit VMW_PORT_HB_[IN|OUT] macros + +From: Thomas Hellstrom + +commit 938ae7259c908ad031da35d551da297640bb640c upstream. + +Depending on whether the kernel is compiled with frame-pointer or not, +the temporary memory location used for the bp parameter in these macros +is referenced relative to the stack pointer or the frame pointer. +Hence we can never reference that parameter when we've modified either +the stack pointer or the frame pointer, because then the compiler would +generate an incorrect stack reference. + +Fix this by pushing the temporary memory parameter on a known location on +the stack before modifying the stack- and frame pointers. + +Cc: +Signed-off-by: Thomas Hellstrom +Reviewed-by: Brian Paul +Reviewed-by: Sinclair Yeh +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/vmwgfx/vmwgfx_msg.h | 25 +++++++++++++++++-------- + 1 file changed, 17 insertions(+), 8 deletions(-) + +--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.h ++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.h +@@ -135,17 +135,24 @@ + + #else + +-/* In the 32-bit version of this macro, we use "m" because there is no +- * more register left for bp ++/* ++ * In the 32-bit version of this macro, we store bp in a memory location ++ * because we've ran out of registers. ++ * Now we can't reference that memory location while we've modified ++ * %esp or %ebp, so we first push it on the stack, just before we push ++ * %ebp, and then when we need it we read it from the stack where we ++ * just pushed it. + */ + #define VMW_PORT_HB_OUT(cmd, in_ecx, in_si, in_di, \ + port_num, magic, bp, \ + eax, ebx, ecx, edx, si, di) \ + ({ \ +- asm volatile ("push %%ebp;" \ +- "mov %12, %%ebp;" \ ++ asm volatile ("push %12;" \ ++ "push %%ebp;" \ ++ "mov 0x04(%%esp), %%ebp;" \ + "rep outsb;" \ +- "pop %%ebp;" : \ ++ "pop %%ebp;" \ ++ "add $0x04, %%esp;" : \ + "=a"(eax), \ + "=b"(ebx), \ + "=c"(ecx), \ +@@ -167,10 +174,12 @@ + port_num, magic, bp, \ + eax, ebx, ecx, edx, si, di) \ + ({ \ +- asm volatile ("push %%ebp;" \ +- "mov %12, %%ebp;" \ ++ asm volatile ("push %12;" \ ++ "push %%ebp;" \ ++ "mov 0x04(%%esp), %%ebp;" \ + "rep insb;" \ +- "pop %%ebp" : \ ++ "pop %%ebp;" \ ++ "add $0x04, %%esp;" : \ + "=a"(eax), \ + "=b"(ebx), \ + "=c"(ecx), \ diff --git a/queue-4.9/ib-hfi1-use-after-free-race-condition-in-send-context-error-path.patch b/queue-4.9/ib-hfi1-use-after-free-race-condition-in-send-context-error-path.patch new file mode 100644 index 00000000000..3b10dd302b6 --- /dev/null +++ b/queue-4.9/ib-hfi1-use-after-free-race-condition-in-send-context-error-path.patch @@ -0,0 +1,85 @@ +From f9e76ca3771bf23d2142a81a88ddd8f31f5c4c03 Mon Sep 17 00:00:00 2001 +From: "Michael J. Ruhl" +Date: Wed, 2 May 2018 06:42:51 -0700 +Subject: IB/hfi1: Use after free race condition in send context error path + +From: Michael J. Ruhl + +commit f9e76ca3771bf23d2142a81a88ddd8f31f5c4c03 upstream. + +A pio send egress error can occur when the PSM library attempts to +to send a bad packet. That issue is still being investigated. + +The pio error interrupt handler then attempts to progress the recovery +of the errored pio send context. + +Code inspection reveals that the handling lacks the necessary locking +if that recovery interleaves with a PSM close of the "context" object +contains the pio send context. + +The lack of the locking can cause the recovery to access the already +freed pio send context object and incorrectly deduce that the pio +send context is actually a kernel pio send context as shown by the +NULL deref stack below: + +[] _dev_info+0x6c/0x90 +[] sc_restart+0x70/0x1f0 [hfi1] +[] ? __schedule+0x424/0x9b0 +[] sc_halted+0x15/0x20 [hfi1] +[] process_one_work+0x17a/0x440 +[] worker_thread+0x126/0x3c0 +[] ? manage_workers.isra.24+0x2a0/0x2a0 +[] kthread+0xcf/0xe0 +[] ? insert_kthread_work+0x40/0x40 +[] ret_from_fork+0x58/0x90 +[] ? insert_kthread_work+0x40/0x40 + +This is the best case scenario and other scenarios can corrupt the +already freed memory. + +Fix by adding the necessary locking in the pio send context error +handler. + +Cc: # 4.9.x +Reviewed-by: Mike Marciniszyn +Reviewed-by: Dennis Dalessandro +Signed-off-by: Michael J. Ruhl +Signed-off-by: Dennis Dalessandro +Signed-off-by: Doug Ledford +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/hw/hfi1/chip.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/infiniband/hw/hfi1/chip.c ++++ b/drivers/infiniband/hw/hfi1/chip.c +@@ -5860,6 +5860,7 @@ static void is_sendctxt_err_int(struct h + u64 status; + u32 sw_index; + int i = 0; ++ unsigned long irq_flags; + + sw_index = dd->hw_to_sw[hw_context]; + if (sw_index >= dd->num_send_contexts) { +@@ -5869,10 +5870,12 @@ static void is_sendctxt_err_int(struct h + return; + } + sci = &dd->send_contexts[sw_index]; ++ spin_lock_irqsave(&dd->sc_lock, irq_flags); + sc = sci->sc; + if (!sc) { + dd_dev_err(dd, "%s: context %u(%u): no sc?\n", __func__, + sw_index, hw_context); ++ spin_unlock_irqrestore(&dd->sc_lock, irq_flags); + return; + } + +@@ -5894,6 +5897,7 @@ static void is_sendctxt_err_int(struct h + */ + if (sc->type != SC_USER) + queue_work(dd->pport->hfi1_wq, &sc->halt_work); ++ spin_unlock_irqrestore(&dd->sc_lock, irq_flags); + + /* + * Update the counters for the corresponding status bits. diff --git a/queue-4.9/ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping.patch b/queue-4.9/ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping.patch new file mode 100644 index 00000000000..3ea5dbf718c --- /dev/null +++ b/queue-4.9/ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping.patch @@ -0,0 +1,51 @@ +From 8f89c007b6dec16a1793cb88de88fcc02117bbbc Mon Sep 17 00:00:00 2001 +From: Davidlohr Bueso +Date: Fri, 25 May 2018 14:47:30 -0700 +Subject: ipc/shm: fix shmat() nil address after round-down when remapping + +From: Davidlohr Bueso + +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 +Reported-by: Andrea Arcangeli +Cc: Joe Lawrence +Cc: Manfred Spraul +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + ipc/shm.c | 12 ++++++++++-- + 1 file changed, 10 insertions(+), 2 deletions(-) + +--- a/ipc/shm.c ++++ b/ipc/shm.c +@@ -1127,9 +1127,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.9/kasan-fix-memory-hotplug-during-boot.patch b/queue-4.9/kasan-fix-memory-hotplug-during-boot.patch new file mode 100644 index 00000000000..736b29f8b87 --- /dev/null +++ b/queue-4.9/kasan-fix-memory-hotplug-during-boot.patch @@ -0,0 +1,41 @@ +From 3f1959721558a976aaf9c2024d5bc884e6411bf7 Mon Sep 17 00:00:00 2001 +From: David Hildenbrand +Date: Fri, 25 May 2018 14:48:11 -0700 +Subject: kasan: fix memory hotplug during boot + +From: David Hildenbrand + +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 +Acked-by: Andrey Ryabinin +Cc: Alexander Potapenko +Cc: Dmitry Vyukov +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/kasan/kasan.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/mm/kasan/kasan.c ++++ b/mm/kasan/kasan.c +@@ -800,5 +800,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.9/kernel-signal.c-avoid-undefined-behaviour-in-kill_something_info.patch b/queue-4.9/kernel-signal.c-avoid-undefined-behaviour-in-kill_something_info.patch new file mode 100644 index 00000000000..abca0efbdb5 --- /dev/null +++ b/queue-4.9/kernel-signal.c-avoid-undefined-behaviour-in-kill_something_info.patch @@ -0,0 +1,55 @@ +From 4ea77014af0d6205b05503d1c7aac6eace11d473 Mon Sep 17 00:00:00 2001 +From: zhongjiang +Date: Mon, 10 Jul 2017 15:52:57 -0700 +Subject: kernel/signal.c: avoid undefined behaviour in kill_something_info + +From: zhongjiang + +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 +Cc: Oleg Nesterov +Cc: Michal Hocko +Cc: Vlastimil Babka +Cc: Xishi Qiu +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + 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.9/kernel-sys.c-fix-potential-spectre-v1-issue.patch b/queue-4.9/kernel-sys.c-fix-potential-spectre-v1-issue.patch new file mode 100644 index 00000000000..685ce8ce8aa --- /dev/null +++ b/queue-4.9/kernel-sys.c-fix-potential-spectre-v1-issue.patch @@ -0,0 +1,52 @@ +From 23d6aef74da86a33fa6bb75f79565e0a16ee97c2 Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +Date: Fri, 25 May 2018 14:47:57 -0700 +Subject: kernel/sys.c: fix potential Spectre v1 issue + +From: Gustavo A. R. Silva + +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 +Reviewed-by: Andrew Morton +Cc: Alexei Starovoitov +Cc: Dan Williams +Cc: Thomas Gleixner +Cc: Peter Zijlstra +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/sys.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/kernel/sys.c ++++ b/kernel/sys.c +@@ -1313,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.9/libata-blacklist-micron-500it-ssd-with-mu01-firmware.patch b/queue-4.9/libata-blacklist-micron-500it-ssd-with-mu01-firmware.patch new file mode 100644 index 00000000000..32b609341d8 --- /dev/null +++ b/queue-4.9/libata-blacklist-micron-500it-ssd-with-mu01-firmware.patch @@ -0,0 +1,66 @@ +From 136d769e0b3475d71350aa3648a116a6ee7a8f6c Mon Sep 17 00:00:00 2001 +From: Sudip Mukherjee +Date: Sat, 19 May 2018 22:29:36 +0100 +Subject: libata: blacklist Micron 500IT SSD with MU01 firmware + +From: Sudip Mukherjee + +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 +Cc: stable@vger.kernel.org +Signed-off-by: Sudip Mukherjee +Signed-off-by: Tejun Heo +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ata/libata-core.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/ata/libata-core.c ++++ b/drivers/ata/libata-core.c +@@ -4430,6 +4430,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.9/libata-blacklist-some-sandisk-ssds-for-ncq.patch b/queue-4.9/libata-blacklist-some-sandisk-ssds-for-ncq.patch new file mode 100644 index 00000000000..1a33d9ed4a3 --- /dev/null +++ b/queue-4.9/libata-blacklist-some-sandisk-ssds-for-ncq.patch @@ -0,0 +1,35 @@ +From 322579dcc865b94b47345ad1b6002ad167f85405 Mon Sep 17 00:00:00 2001 +From: Tejun Heo +Date: Tue, 8 May 2018 14:21:56 -0700 +Subject: libata: Blacklist some Sandisk SSDs for NCQ + +From: Tejun Heo + +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 +Reported-by: Dave Jones +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ata/libata-core.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/ata/libata-core.c ++++ b/drivers/ata/libata-core.c +@@ -4366,6 +4366,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.9/mmc-sdhci-iproc-fix-32bit-writes-for-transfer_mode-register.patch b/queue-4.9/mmc-sdhci-iproc-fix-32bit-writes-for-transfer_mode-register.patch new file mode 100644 index 00000000000..72ee2b52089 --- /dev/null +++ b/queue-4.9/mmc-sdhci-iproc-fix-32bit-writes-for-transfer_mode-register.patch @@ -0,0 +1,103 @@ +From 5f651b870485ee60f5abbbd85195a6852978894a Mon Sep 17 00:00:00 2001 +From: Corneliu Doban +Date: Fri, 18 May 2018 15:03:56 -0700 +Subject: mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register + +From: Corneliu Doban + +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 +Signed-off-by: Scott Branden +Cc: stable@vger.kernel.org # v4.1+ +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -33,6 +33,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) +@@ -48,8 +50,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; + } + +@@ -105,13 +121,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 { +@@ -123,9 +141,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.9/mmc-sdhci-iproc-remove-hard-coded-mmc-cap-1.8v.patch b/queue-4.9/mmc-sdhci-iproc-remove-hard-coded-mmc-cap-1.8v.patch new file mode 100644 index 00000000000..6f425b9d90c --- /dev/null +++ b/queue-4.9/mmc-sdhci-iproc-remove-hard-coded-mmc-cap-1.8v.patch @@ -0,0 +1,35 @@ +From 4c94238f37af87a2165c3fb491b4a8b50e90649c Mon Sep 17 00:00:00 2001 +From: Srinath Mannam +Date: Fri, 18 May 2018 15:03:55 -0700 +Subject: mmc: sdhci-iproc: remove hard coded mmc cap 1.8v + +From: Srinath Mannam + +commit 4c94238f37af87a2165c3fb491b4a8b50e90649c upstream. + +Remove hard coded mmc cap 1.8v from platform data as it is board specific. +The 1.8v DDR mmc caps can be enabled using DTS property for those +boards that support it. + +Fixes: b17b4ab8ce38 ("mmc: sdhci-iproc: define MMC caps in platform data") +Signed-off-by: Srinath Mannam +Signed-off-by: Scott Branden +Reviewed-by: Ray Jui +Cc: stable@vger.kernel.org # v4.8+ +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci-iproc.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/mmc/host/sdhci-iproc.c ++++ b/drivers/mmc/host/sdhci-iproc.c +@@ -176,7 +176,6 @@ static const struct sdhci_iproc_data ipr + .caps1 = SDHCI_DRIVER_TYPE_C | + SDHCI_DRIVER_TYPE_D | + SDHCI_SUPPORT_DDR50, +- .mmc_caps = MMC_CAP_1_8V_DDR, + }; + + static const struct sdhci_pltfm_data sdhci_bcm2835_pltfm_data = { diff --git a/queue-4.9/revert-ipc-shm-fix-shmat-mmap-nil-page-protection.patch b/queue-4.9/revert-ipc-shm-fix-shmat-mmap-nil-page-protection.patch new file mode 100644 index 00000000000..16338f79ee2 --- /dev/null +++ b/queue-4.9/revert-ipc-shm-fix-shmat-mmap-nil-page-protection.patch @@ -0,0 +1,69 @@ +From a73ab244f0dad8fffb3291b905f73e2d3eaa7c00 Mon Sep 17 00:00:00 2001 +From: Davidlohr Bueso +Date: Fri, 25 May 2018 14:47:27 -0700 +Subject: Revert "ipc/shm: Fix shmat mmap nil-page protection" + +From: Davidlohr Bueso + +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 +Reported-by: Joe Lawrence +Reported-by: Andrea Arcangeli +Cc: Manfred Spraul +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + ipc/shm.c | 9 ++------- + 1 file changed, 2 insertions(+), 7 deletions(-) + +--- a/ipc/shm.c ++++ b/ipc/shm.c +@@ -1127,13 +1127,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) diff --git a/queue-4.9/series b/queue-4.9/series index 79be32b44fa..0659fd885d5 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -6,3 +6,15 @@ 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 do-d_instantiate-unlock_new_inode-combinations-safely.patch +mmc-sdhci-iproc-remove-hard-coded-mmc-cap-1.8v.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 +drm-vmwgfx-fix-32-bit-vmw_port_hb_-macros.patch +ib-hfi1-use-after-free-race-condition-in-send-context-error-path.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 diff --git a/queue-4.9/xen-swiotlb-fix-the-check-condition-for-xen_swiotlb_free_coherent.patch b/queue-4.9/xen-swiotlb-fix-the-check-condition-for-xen_swiotlb_free_coherent.patch new file mode 100644 index 00000000000..742648edb6e --- /dev/null +++ b/queue-4.9/xen-swiotlb-fix-the-check-condition-for-xen_swiotlb_free_coherent.patch @@ -0,0 +1,44 @@ +From 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 Mon Sep 17 00:00:00 2001 +From: Joe Jin +Date: Thu, 17 May 2018 12:33:28 -0700 +Subject: xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent + +From: Joe Jin + +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 +Tested-by: John Sobecki +Reviewed-by: Rzeszutek Wilk +Cc: stable@vger.kernel.org +Signed-off-by: Konrad Rzeszutek Wilk +Signed-off-by: Greg Kroah-Hartman + +--- + 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); +