--- /dev/null
+From 8f36ebaf21fdae99c091c67e8b6fab33969f2667 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <marc.zyngier@arm.com>
+Date: Wed, 25 Jan 2017 12:29:59 +0000
+Subject: arm/arm64: KVM: Enforce unconditional flush to PoC when mapping to stage-2
+
+From: Marc Zyngier <marc.zyngier@arm.com>
+
+commit 8f36ebaf21fdae99c091c67e8b6fab33969f2667 upstream.
+
+When we fault in a page, we flush it to the PoC (Point of Coherency)
+if the faulting vcpu has its own caches off, so that it can observe
+the page we just brought it.
+
+But if the vcpu has its caches on, we skip that step. Bad things
+happen when *another* vcpu tries to access that page with its own
+caches disabled. At that point, there is no garantee that the
+data has made it to the PoC, and we access stale data.
+
+The obvious fix is to always flush to PoC when a page is faulted
+in, no matter what the state of the vcpu is.
+
+Fixes: 2d58b733c876 ("arm64: KVM: force cache clean on page fault when caches are off")
+Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
+Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/include/asm/kvm_mmu.h | 9 +--------
+ arch/arm64/include/asm/kvm_mmu.h | 3 +--
+ 2 files changed, 2 insertions(+), 10 deletions(-)
+
+--- a/arch/arm/include/asm/kvm_mmu.h
++++ b/arch/arm/include/asm/kvm_mmu.h
+@@ -150,18 +150,12 @@ static inline void __coherent_cache_gues
+ * and iterate over the range.
+ */
+
+- bool need_flush = !vcpu_has_cache_enabled(vcpu) || ipa_uncached;
+-
+ VM_BUG_ON(size & ~PAGE_MASK);
+
+- if (!need_flush && !icache_is_pipt())
+- goto vipt_cache;
+-
+ while (size) {
+ void *va = kmap_atomic_pfn(pfn);
+
+- if (need_flush)
+- kvm_flush_dcache_to_poc(va, PAGE_SIZE);
++ kvm_flush_dcache_to_poc(va, PAGE_SIZE);
+
+ if (icache_is_pipt())
+ __cpuc_coherent_user_range((unsigned long)va,
+@@ -173,7 +167,6 @@ static inline void __coherent_cache_gues
+ kunmap_atomic(va);
+ }
+
+-vipt_cache:
+ if (!icache_is_pipt() && !icache_is_vivt_asid_tagged()) {
+ /* any kind of VIPT cache */
+ __flush_icache_all();
+--- a/arch/arm64/include/asm/kvm_mmu.h
++++ b/arch/arm64/include/asm/kvm_mmu.h
+@@ -241,8 +241,7 @@ static inline void __coherent_cache_gues
+ {
+ void *va = page_address(pfn_to_page(pfn));
+
+- if (!vcpu_has_cache_enabled(vcpu) || ipa_uncached)
+- kvm_flush_dcache_to_poc(va, size);
++ kvm_flush_dcache_to_poc(va, size);
+
+ if (!icache_is_aliasing()) { /* PIPT */
+ flush_icache_range((unsigned long)va,
--- /dev/null
+From adbe7e26f4257f72817495b9bce114284060b0d7 Mon Sep 17 00:00:00 2001
+From: Robin Murphy <robin.murphy@arm.com>
+Date: Wed, 25 Jan 2017 18:31:31 +0000
+Subject: arm64: dma-mapping: Fix dma_mapping_error() when bypassing SWIOTLB
+
+From: Robin Murphy <robin.murphy@arm.com>
+
+commit adbe7e26f4257f72817495b9bce114284060b0d7 upstream.
+
+When bypassing SWIOTLB on small-memory systems, we need to avoid calling
+into swiotlb_dma_mapping_error() in exactly the same way as we avoid
+swiotlb_dma_supported(), because the former also relies on SWIOTLB state
+being initialised.
+
+Under the assumptions for which we skip SWIOTLB, dma_map_{single,page}()
+will only ever return the DMA-offset-adjusted physical address of the
+page passed in, thus we can report success unconditionally.
+
+Fixes: b67a8b29df7e ("arm64: mm: only initialize swiotlb when necessary")
+CC: Jisheng Zhang <jszhang@marvell.com>
+Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi>
+Signed-off-by: Robin Murphy <robin.murphy@arm.com>
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/mm/dma-mapping.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/arch/arm64/mm/dma-mapping.c
++++ b/arch/arm64/mm/dma-mapping.c
+@@ -352,6 +352,13 @@ static int __swiotlb_dma_supported(struc
+ return 1;
+ }
+
++static int __swiotlb_dma_mapping_error(struct device *hwdev, dma_addr_t addr)
++{
++ if (swiotlb)
++ return swiotlb_dma_mapping_error(hwdev, addr);
++ return 0;
++}
++
+ static struct dma_map_ops swiotlb_dma_ops = {
+ .alloc = __dma_alloc,
+ .free = __dma_free,
+@@ -366,7 +373,7 @@ static struct dma_map_ops swiotlb_dma_op
+ .sync_sg_for_cpu = __swiotlb_sync_sg_for_cpu,
+ .sync_sg_for_device = __swiotlb_sync_sg_for_device,
+ .dma_supported = __swiotlb_dma_supported,
+- .mapping_error = swiotlb_dma_mapping_error,
++ .mapping_error = __swiotlb_dma_mapping_error,
+ };
+
+ static int __init atomic_pool_init(void)
--- /dev/null
+From 7d0928f18bf890d2853281f59aba0dd5a46b34f9 Mon Sep 17 00:00:00 2001
+From: Mark Rutland <mark.rutland@arm.com>
+Date: Thu, 2 Feb 2017 17:32:14 +0000
+Subject: arm64: fix erroneous __raw_read_system_reg() cases
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+commit 7d0928f18bf890d2853281f59aba0dd5a46b34f9 upstream.
+
+Since it was introduced in commit da8d02d19ffdd201 ("arm64/capabilities:
+Make use of system wide safe value"), __raw_read_system_reg() has
+erroneously mapped some sysreg IDs to other registers.
+
+For the fields in ID_ISAR5_EL1, our local feature detection will be
+erroneous. We may spuriously detect that a feature is uniformly
+supported, or may fail to detect when it actually is, meaning some
+compat hwcaps may be erroneous (or not enforced upon hotplug).
+
+This patch corrects the erroneous entries.
+
+Signed-off-by: Mark Rutland <mark.rutland@arm.com>
+Fixes: da8d02d19ffdd201 ("arm64/capabilities: Make use of system wide safe value")
+Reported-by: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
+Cc: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/kernel/cpufeature.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/arch/arm64/kernel/cpufeature.c
++++ b/arch/arm64/kernel/cpufeature.c
+@@ -653,15 +653,15 @@ static u64 __raw_read_system_reg(u32 sys
+ case SYS_ID_ISAR2_EL1: return read_cpuid(ID_ISAR2_EL1);
+ case SYS_ID_ISAR3_EL1: return read_cpuid(ID_ISAR3_EL1);
+ case SYS_ID_ISAR4_EL1: return read_cpuid(ID_ISAR4_EL1);
+- case SYS_ID_ISAR5_EL1: return read_cpuid(ID_ISAR4_EL1);
++ case SYS_ID_ISAR5_EL1: return read_cpuid(ID_ISAR5_EL1);
+ case SYS_MVFR0_EL1: return read_cpuid(MVFR0_EL1);
+ case SYS_MVFR1_EL1: return read_cpuid(MVFR1_EL1);
+ case SYS_MVFR2_EL1: return read_cpuid(MVFR2_EL1);
+
+ case SYS_ID_AA64PFR0_EL1: return read_cpuid(ID_AA64PFR0_EL1);
+- case SYS_ID_AA64PFR1_EL1: return read_cpuid(ID_AA64PFR0_EL1);
++ case SYS_ID_AA64PFR1_EL1: return read_cpuid(ID_AA64PFR1_EL1);
+ case SYS_ID_AA64DFR0_EL1: return read_cpuid(ID_AA64DFR0_EL1);
+- case SYS_ID_AA64DFR1_EL1: return read_cpuid(ID_AA64DFR0_EL1);
++ case SYS_ID_AA64DFR1_EL1: return read_cpuid(ID_AA64DFR1_EL1);
+ case SYS_ID_AA64MMFR0_EL1: return read_cpuid(ID_AA64MMFR0_EL1);
+ case SYS_ID_AA64MMFR1_EL1: return read_cpuid(ID_AA64MMFR1_EL1);
+ case SYS_ID_AA64MMFR2_EL1: return read_cpuid(ID_AA64MMFR2_EL1);
--- /dev/null
+From 1c68bb0f62bf8de8bb30123ea840d5168f25abea Mon Sep 17 00:00:00 2001
+From: Laura Abbott <labbott@redhat.com>
+Date: Tue, 28 Feb 2017 14:07:25 -0800
+Subject: crypto: testmgr - Pad aes_ccm_enc_tv_template vector
+
+From: Laura Abbott <labbott@redhat.com>
+
+commit 1c68bb0f62bf8de8bb30123ea840d5168f25abea upstream.
+
+Running with KASAN and crypto tests currently gives
+
+ BUG: KASAN: global-out-of-bounds in __test_aead+0x9d9/0x2200 at addr ffffffff8212fca0
+ Read of size 16 by task cryptomgr_test/1107
+ Address belongs to variable 0xffffffff8212fca0
+ CPU: 0 PID: 1107 Comm: cryptomgr_test Not tainted 4.10.0+ #45
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
+ Call Trace:
+ dump_stack+0x63/0x8a
+ kasan_report.part.1+0x4a7/0x4e0
+ ? __test_aead+0x9d9/0x2200
+ ? crypto_ccm_init_crypt+0x218/0x3c0 [ccm]
+ kasan_report+0x20/0x30
+ check_memory_region+0x13c/0x1a0
+ memcpy+0x23/0x50
+ __test_aead+0x9d9/0x2200
+ ? kasan_unpoison_shadow+0x35/0x50
+ ? alg_test_akcipher+0xf0/0xf0
+ ? crypto_skcipher_init_tfm+0x2e3/0x310
+ ? crypto_spawn_tfm2+0x37/0x60
+ ? crypto_ccm_init_tfm+0xa9/0xd0 [ccm]
+ ? crypto_aead_init_tfm+0x7b/0x90
+ ? crypto_alloc_tfm+0xc4/0x190
+ test_aead+0x28/0xc0
+ alg_test_aead+0x54/0xd0
+ alg_test+0x1eb/0x3d0
+ ? alg_find_test+0x90/0x90
+ ? __sched_text_start+0x8/0x8
+ ? __wake_up_common+0x70/0xb0
+ cryptomgr_test+0x4d/0x60
+ kthread+0x173/0x1c0
+ ? crypto_acomp_scomp_free_ctx+0x60/0x60
+ ? kthread_create_on_node+0xa0/0xa0
+ ret_from_fork+0x2c/0x40
+ Memory state around the buggy address:
+ ffffffff8212fb80: 00 00 00 00 01 fa fa fa fa fa fa fa 00 00 00 00
+ ffffffff8212fc00: 00 01 fa fa fa fa fa fa 00 00 00 00 01 fa fa fa
+ >ffffffff8212fc80: fa fa fa fa 00 05 fa fa fa fa fa fa 00 00 00 00
+ ^
+ ffffffff8212fd00: 01 fa fa fa fa fa fa fa 00 00 00 00 01 fa fa fa
+ ffffffff8212fd80: fa fa fa fa 00 00 00 00 00 05 fa fa fa fa fa fa
+
+This always happens on the same IV which is less than 16 bytes.
+
+Per Ard,
+
+"CCM IVs are 16 bytes, but due to the way they are constructed
+internally, the final couple of bytes of input IV are dont-cares.
+
+Apparently, we do read all 16 bytes, which triggers the KASAN errors."
+
+Fix this by padding the IV with null bytes to be at least 16 bytes.
+
+Fixes: 0bc5a6c5c79a ("crypto: testmgr - Disable rfc4309 test and convert test vectors")
+Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Signed-off-by: Laura Abbott <labbott@redhat.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ crypto/testmgr.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/crypto/testmgr.h
++++ b/crypto/testmgr.h
+@@ -22813,7 +22813,7 @@ static struct aead_testvec aes_ccm_enc_t
+ "\x09\x75\x9a\x9b\x3c\x9b\x27\x39",
+ .klen = 32,
+ .iv = "\x03\xf9\xd9\x4e\x63\xb5\x3d\x9d"
+- "\x43\xf6\x1e\x50",
++ "\x43\xf6\x1e\x50\0\0\0\0",
+ .assoc = "\x57\xf5\x6b\x8b\x57\x5c\x3d\x3b"
+ "\x13\x02\x01\x0c\x83\x4c\x96\x35"
+ "\x8e\xd6\x39\xcf\x7d\x14\x9b\x94"
--- /dev/null
+From 2e38bea99a80eab408adee27f873a188d57b76cb Mon Sep 17 00:00:00 2001
+From: Miklos Szeredi <mszeredi@redhat.com>
+Date: Wed, 22 Feb 2017 20:08:25 +0100
+Subject: fuse: add missing FR_FORCE
+
+From: Miklos Szeredi <mszeredi@redhat.com>
+
+commit 2e38bea99a80eab408adee27f873a188d57b76cb upstream.
+
+fuse_file_put() was missing the "force" flag for the RELEASE request when
+sending synchronously (fuseblk).
+
+If this flag is not set, then a sync request may be interrupted before it
+is dequeued by the userspace filesystem. In this case the OPEN won't be
+balanced with a RELEASE.
+
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Fixes: 5a18ec176c93 ("fuse: fix hang of single threaded fuseblk filesystem")
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/fuse/file.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/fuse/file.c
++++ b/fs/fuse/file.c
+@@ -100,6 +100,7 @@ static void fuse_file_put(struct fuse_fi
+ iput(req->misc.release.inode);
+ fuse_put_request(ff->fc, req);
+ } else if (sync) {
++ __set_bit(FR_FORCE, &req->flags);
+ __clear_bit(FR_BACKGROUND, &req->flags);
+ fuse_request_send(ff->fc, req);
+ iput(req->misc.release.inode);
--- /dev/null
+From 6a6e1d56a0769795a36c0461c64bf5e5b9bbb4c0 Mon Sep 17 00:00:00 2001
+From: Peter Rosin <peda@axentia.se>
+Date: Wed, 1 Feb 2017 21:40:57 +0100
+Subject: iio: pressure: mpl115: do not rely on structure field ordering
+
+From: Peter Rosin <peda@axentia.se>
+
+commit 6a6e1d56a0769795a36c0461c64bf5e5b9bbb4c0 upstream.
+
+Fixes a regression triggered by a change in the layout of
+struct iio_chan_spec, but the real bug is in the driver which assumed
+a specific structure layout in the first place. Hint: the three bits were
+not OR:ed together as implied by the indentation prior to this patch,
+there was a comma between the first two, which accidentally moved the
+..._SCALE and ..._OFFSET bits to the next structure field. That field
+was .info_mask_shared_by_type before the _available attributes was added
+by commit 51239600074b ("iio:core: add a callback to allow drivers to
+provide _available attributes") and .info_mask_separate_available
+afterwards, and the regression happened.
+
+info_mask_shared_by_type is actually a better choice than the originally
+intended info_mask_separate for the ..._SCALE and ..._OFFSET bits since
+a constant is returned from mpl115_read_raw for the scale/offset. Using
+info_mask_shared_by_type also preserves the behavior from before the
+regression and is therefore less likely to cause other interesting side
+effects.
+
+The above mentioned regression causes unintended sysfs attibutes to
+show up that are not backed by code, in turn causing a NULL pointer
+defererence to happen on access.
+
+Fixes: 3017d90e8931 ("iio: Add Freescale MPL115A2 pressure / temperature sensor driver")
+Fixes: 51239600074b ("iio:core: add a callback to allow drivers to provide _available attributes")
+Signed-off-by: Peter Rosin <peda@axentia.se>
+Signed-off-by: Jonathan Cameron <jic23@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/pressure/mpl115.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/iio/pressure/mpl115.c
++++ b/drivers/iio/pressure/mpl115.c
+@@ -137,6 +137,7 @@ static const struct iio_chan_spec mpl115
+ {
+ .type = IIO_TEMP,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
++ .info_mask_shared_by_type =
+ BIT(IIO_CHAN_INFO_OFFSET) | BIT(IIO_CHAN_INFO_SCALE),
+ },
+ };
--- /dev/null
+From 9cf6cdba586ced75c69b8314b88b2d2f5ce9b3ed Mon Sep 17 00:00:00 2001
+From: Peter Rosin <peda@axentia.se>
+Date: Wed, 1 Feb 2017 21:40:56 +0100
+Subject: iio: pressure: mpl3115: do not rely on structure field ordering
+
+From: Peter Rosin <peda@axentia.se>
+
+commit 9cf6cdba586ced75c69b8314b88b2d2f5ce9b3ed upstream.
+
+Fixes a regression triggered by a change in the layout of
+struct iio_chan_spec, but the real bug is in the driver which assumed
+a specific structure layout in the first place. Hint: the two bits were
+not OR:ed together as implied by the indentation prior to this patch,
+there was a comma between them, which accidentally moved the ..._SCALE
+bit to the next structure field. That field was .info_mask_shared_by_type
+before the _available attributes was added by commit 51239600074b
+("iio:core: add a callback to allow drivers to provide _available
+attributes") and .info_mask_separate_available afterwards, and the
+regression happened.
+
+info_mask_shared_by_type is actually a better choice than the originally
+intended info_mask_separate for the ..._SCALE bit since a constant is
+returned from mpl3115_read_raw for the scale. Using
+info_mask_shared_by_type also preserves the behavior from before the
+regression and is therefore less likely to cause other interesting side
+effects.
+
+The above mentioned regression causes an unintended sysfs attibute to
+show up that is not backed by code, in turn causing the following NULL
+pointer defererence to happen on access.
+
+Segmentation fault
+
+Unable to handle kernel NULL pointer dereference at virtual address 00000000
+pgd = ecc3c000
+[00000000] *pgd=87f91831
+Internal error: Oops: 80000007 [#1] SMP ARM
+Modules linked in:
+CPU: 1 PID: 1051 Comm: cat Not tainted 4.10.0-rc5-00009-gffd8858-dirty #3
+Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
+task: ed54ec00 task.stack: ee2bc000
+PC is at 0x0
+LR is at iio_read_channel_info_avail+0x40/0x280
+pc : [<00000000>] lr : [<c06fbc1c>] psr: a0070013
+sp : ee2bdda8 ip : 00000000 fp : ee2bddf4
+r10: c0a53c74 r9 : ed79f000 r8 : ee8d1018
+r7 : 00001000 r6 : 00000fff r5 : ee8b9a00 r4 : ed79f000
+r3 : ee2bddc4 r2 : ee2bddbc r1 : c0a86dcc r0 : ee8d1000
+Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
+Control: 10c5387d Table: 3cc3c04a DAC: 00000051
+Process cat (pid: 1051, stack limit = 0xee2bc210)
+Stack: (0xee2bdda8 to 0xee2be000)
+dda0: ee2bddc0 00000002 c016d720 c016d394 ed54ec00 00000000
+ddc0: 60070013 ed413780 00000001 edffd480 ee8b9a00 00000fff 00001000 ee8d1018
+dde0: ed79f000 c0a53c74 ee2bde0c ee2bddf8 c0513c58 c06fbbe8 edffd480 edffd540
+de00: ee2bde3c ee2bde10 c0293474 c0513c40 c02933e4 ee2bde60 00000001 ed413780
+de20: 00000001 ed413780 00000000 edffd480 ee2bde4c ee2bde40 c0291d00 c02933f0
+de40: ee2bde9c ee2bde50 c024679c c0291ce0 edffd4b0 b6e37000 00020000 ee2bdf78
+de60: 00000000 00000000 ed54ec00 ed013200 00000817 c0a111fc edffd540 ed413780
+de80: b6e37000 00020000 00020000 ee2bdf78 ee2bded4 ee2bdea0 c0292890 c0246604
+dea0: c0117940 c016ba50 00000025 c0a111fc b6e37000 ed413780 ee2bdf78 00020000
+dec0: ee2bc000 b6e37000 ee2bdf44 ee2bded8 c021d158 c0292770 c0117764 b6e36004
+dee0: c0f0d7c4 ee2bdfb0 b6f89228 00021008 ee2bdfac ee2bdf00 c0101374 c0117770
+df00: 00000000 00000000 ee2bc000 00000000 ee2bdf34 ee2bdf20 c016ba04 c0171080
+df20: 00000000 00020000 ed413780 b6e37000 00000000 ee2bdf78 ee2bdf74 ee2bdf48
+df40: c021e7a0 c021d130 c023e300 c023e280 ee2bdf74 00000000 00000000 ed413780
+df60: ed413780 00020000 ee2bdfa4 ee2bdf78 c021e870 c021e71c 00000000 00000000
+df80: 00020000 00020000 b6e37000 00000003 c0108084 00000000 00000000 ee2bdfa8
+dfa0: c0107ee0 c021e838 00020000 00020000 00000003 b6e37000 00020000 0001a2b4
+dfc0: 00020000 00020000 b6e37000 00000003 7fffe000 00000000 00000000 00020000
+dfe0: 00000000 be98eb4c 0000c740 b6f1985c 60070010 00000003 00000000 00000000
+Backtrace:
+[<c06fbbdc>] (iio_read_channel_info_avail) from [<c0513c58>] (dev_attr_show+0x24/0x50)
+ r10:c0a53c74 r9:ed79f000 r8:ee8d1018 r7:00001000 r6:00000fff r5:ee8b9a00
+ r4:edffd480
+[<c0513c34>] (dev_attr_show) from [<c0293474>] (sysfs_kf_seq_show+0x90/0x110)
+ r5:edffd540 r4:edffd480
+[<c02933e4>] (sysfs_kf_seq_show) from [<c0291d00>] (kernfs_seq_show+0x2c/0x30)
+ r10:edffd480 r9:00000000 r8:ed413780 r7:00000001 r6:ed413780 r5:00000001
+ r4:ee2bde60 r3:c02933e4
+[<c0291cd4>] (kernfs_seq_show) from [<c024679c>] (seq_read+0x1a4/0x4e0)
+[<c02465f8>] (seq_read) from [<c0292890>] (kernfs_fop_read+0x12c/0x1cc)
+ r10:ee2bdf78 r9:00020000 r8:00020000 r7:b6e37000 r6:ed413780 r5:edffd540
+ r4:c0a111fc
+[<c0292764>] (kernfs_fop_read) from [<c021d158>] (__vfs_read+0x34/0x118)
+ r10:b6e37000 r9:ee2bc000 r8:00020000 r7:ee2bdf78 r6:ed413780 r5:b6e37000
+ r4:c0a111fc
+[<c021d124>] (__vfs_read) from [<c021e7a0>] (vfs_read+0x90/0x11c)
+ r8:ee2bdf78 r7:00000000 r6:b6e37000 r5:ed413780 r4:00020000
+[<c021e710>] (vfs_read) from [<c021e870>] (SyS_read+0x44/0x90)
+ r8:00020000 r7:ed413780 r6:ed413780 r5:00000000 r4:00000000
+[<c021e82c>] (SyS_read) from [<c0107ee0>] (ret_fast_syscall+0x0/0x1c)
+ r10:00000000 r8:c0108084 r7:00000003 r6:b6e37000 r5:00020000 r4:00020000
+Code: bad PC value
+---[ end trace 9c4938ccd0389004 ]---
+
+Fixes: cc26ad455f57 ("iio: Add Freescale MPL3115A2 pressure / temperature sensor driver")
+Fixes: 51239600074b ("iio:core: add a callback to allow drivers to provide _available attributes")
+Reported-by: Ken Lin <ken.lin@advantech.com>
+Tested-by: Ken Lin <ken.lin@advantech.com>
+Signed-off-by: Peter Rosin <peda@axentia.se>
+Signed-off-by: Jonathan Cameron <jic23@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iio/pressure/mpl3115.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/pressure/mpl3115.c
++++ b/drivers/iio/pressure/mpl3115.c
+@@ -182,7 +182,7 @@ static const struct iio_chan_spec mpl311
+ {
+ .type = IIO_PRESSURE,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+- BIT(IIO_CHAN_INFO_SCALE),
++ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
+ .scan_index = 0,
+ .scan_type = {
+ .sign = 'u',
+@@ -195,7 +195,7 @@ static const struct iio_chan_spec mpl311
+ {
+ .type = IIO_TEMP,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+- BIT(IIO_CHAN_INFO_SCALE),
++ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
+ .scan_index = 1,
+ .scan_type = {
+ .sign = 's',
--- /dev/null
+From 0bdbf3b071986ba80731203683cf623d5c0cacb1 Mon Sep 17 00:00:00 2001
+From: Shanker Donthineni <shankerd@codeaurora.org>
+Date: Thu, 2 Feb 2017 20:30:03 -0600
+Subject: KVM: arm/arm64: vgic: Stop injecting the MSI occurrence twice
+
+From: Shanker Donthineni <shankerd@codeaurora.org>
+
+commit 0bdbf3b071986ba80731203683cf623d5c0cacb1 upstream.
+
+The IRQFD framework calls the architecture dependent function
+twice if the corresponding GSI type is edge triggered. For ARM,
+the function kvm_set_msi() is getting called twice whenever the
+IRQFD receives the event signal. The rest of the code path is
+trying to inject the MSI without any validation checks. No need
+to call the function vgic_its_inject_msi() second time to avoid
+an unnecessary overhead in IRQ queue logic. It also avoids the
+possibility of VM seeing the MSI twice.
+
+Simple fix, return -1 if the argument 'level' value is zero.
+
+Reviewed-by: Eric Auger <eric.auger@redhat.com>
+Reviewed-by: Christoffer Dall <cdall@linaro.org>
+Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
+Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ virt/kvm/arm/vgic/vgic-irqfd.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/virt/kvm/arm/vgic/vgic-irqfd.c
++++ b/virt/kvm/arm/vgic/vgic-irqfd.c
+@@ -99,6 +99,9 @@ int kvm_set_msi(struct kvm_kernel_irq_ro
+ if (!vgic_has_its(kvm))
+ return -ENODEV;
+
++ if (!level)
++ return -1;
++
+ return vgic_its_inject_msi(kvm, &msi);
+ }
+
pci-altera-fix-tlp_cfg_dw0-for-tlp-write.patch
drivers-hv-vmbus-raise-retry-wait-limits-in-vmbus_post_msg.patch
perf-callchain-reference-count-maps.patch
+crypto-testmgr-pad-aes_ccm_enc_tv_template-vector.patch
+fuse-add-missing-fr_force.patch
+x86-pkeys-check-against-max-pkey-to-avoid-overflows.patch
+arm-arm64-kvm-enforce-unconditional-flush-to-poc-when-mapping-to-stage-2.patch
+arm64-dma-mapping-fix-dma_mapping_error-when-bypassing-swiotlb.patch
+arm64-fix-erroneous-__raw_read_system_reg-cases.patch
+kvm-arm-arm64-vgic-stop-injecting-the-msi-occurrence-twice.patch
+iio-pressure-mpl115-do-not-rely-on-structure-field-ordering.patch
+iio-pressure-mpl3115-do-not-rely-on-structure-field-ordering.patch
--- /dev/null
+From 58ab9a088ddac4efe823471275859d64f735577e Mon Sep 17 00:00:00 2001
+From: Dave Hansen <dave.hansen@linux.intel.com>
+Date: Thu, 23 Feb 2017 14:26:03 -0800
+Subject: x86/pkeys: Check against max pkey to avoid overflows
+
+From: Dave Hansen <dave.hansen@linux.intel.com>
+
+commit 58ab9a088ddac4efe823471275859d64f735577e upstream.
+
+Kirill reported a warning from UBSAN about undefined behavior when using
+protection keys. He is running on hardware that actually has support for
+it, which is not widely available.
+
+The warning triggers because of very large shifts of integers when doing a
+pkey_free() of a large, invalid value. This happens because we never check
+that the pkey "fits" into the mm_pkey_allocation_map().
+
+I do not believe there is any danger here of anything bad happening
+other than some aliasing issues where somebody could do:
+
+ pkey_free(35);
+
+and the kernel would effectively execute:
+
+ pkey_free(8);
+
+While this might be confusing to an app that was doing something stupid, it
+has to do something stupid and the effects are limited to the app shooting
+itself in the foot.
+
+Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
+Cc: linux-kselftest@vger.kernel.org
+Cc: shuah@kernel.org
+Cc: kirill.shutemov@linux.intel.com
+Link: http://lkml.kernel.org/r/20170223222603.A022ED65@viggo.jf.intel.com
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/pkeys.h | 15 +++++++++------
+ 1 file changed, 9 insertions(+), 6 deletions(-)
+
+--- a/arch/x86/include/asm/pkeys.h
++++ b/arch/x86/include/asm/pkeys.h
+@@ -46,6 +46,15 @@ extern int __arch_set_user_pkey_access(s
+ static inline
+ bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
+ {
++ /*
++ * "Allocated" pkeys are those that have been returned
++ * from pkey_alloc(). pkey 0 is special, and never
++ * returned from pkey_alloc().
++ */
++ if (pkey <= 0)
++ return false;
++ if (pkey >= arch_max_pkey())
++ return false;
+ return mm_pkey_allocation_map(mm) & (1U << pkey);
+ }
+
+@@ -82,12 +91,6 @@ int mm_pkey_alloc(struct mm_struct *mm)
+ static inline
+ int mm_pkey_free(struct mm_struct *mm, int pkey)
+ {
+- /*
+- * pkey 0 is special, always allocated and can never
+- * be freed.
+- */
+- if (!pkey)
+- return -EINVAL;
+ if (!mm_pkey_is_allocated(mm, pkey))
+ return -EINVAL;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
