From b223a6cc787a9de8b298ac83141d52346ac1f08b Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 10 Mar 2017 08:51:25 +0100 Subject: [PATCH] 4.9-stable patches added patches: 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 crypto-testmgr-pad-aes_ccm_enc_tv_template-vector.patch fuse-add-missing-fr_force.patch iio-pressure-mpl115-do-not-rely-on-structure-field-ordering.patch iio-pressure-mpl3115-do-not-rely-on-structure-field-ordering.patch kvm-arm-arm64-vgic-stop-injecting-the-msi-occurrence-twice.patch x86-pkeys-check-against-max-pkey-to-avoid-overflows.patch --- ...flush-to-poc-when-mapping-to-stage-2.patch | 73 ++++++++++ ...mapping_error-when-bypassing-swiotlb.patch | 54 ++++++++ ...rroneous-__raw_read_system_reg-cases.patch | 53 ++++++++ ...r-pad-aes_ccm_enc_tv_template-vector.patch | 83 ++++++++++++ queue-4.9/fuse-add-missing-fr_force.patch | 34 +++++ ...not-rely-on-structure-field-ordering.patch | 51 +++++++ ...not-rely-on-structure-field-ordering.patch | 128 ++++++++++++++++++ ...p-injecting-the-msi-occurrence-twice.patch | 42 ++++++ queue-4.9/series | 9 ++ ...-against-max-pkey-to-avoid-overflows.patch | 73 ++++++++++ 10 files changed, 600 insertions(+) create mode 100644 queue-4.9/arm-arm64-kvm-enforce-unconditional-flush-to-poc-when-mapping-to-stage-2.patch create mode 100644 queue-4.9/arm64-dma-mapping-fix-dma_mapping_error-when-bypassing-swiotlb.patch create mode 100644 queue-4.9/arm64-fix-erroneous-__raw_read_system_reg-cases.patch create mode 100644 queue-4.9/crypto-testmgr-pad-aes_ccm_enc_tv_template-vector.patch create mode 100644 queue-4.9/fuse-add-missing-fr_force.patch create mode 100644 queue-4.9/iio-pressure-mpl115-do-not-rely-on-structure-field-ordering.patch create mode 100644 queue-4.9/iio-pressure-mpl3115-do-not-rely-on-structure-field-ordering.patch create mode 100644 queue-4.9/kvm-arm-arm64-vgic-stop-injecting-the-msi-occurrence-twice.patch create mode 100644 queue-4.9/x86-pkeys-check-against-max-pkey-to-avoid-overflows.patch diff --git a/queue-4.9/arm-arm64-kvm-enforce-unconditional-flush-to-poc-when-mapping-to-stage-2.patch b/queue-4.9/arm-arm64-kvm-enforce-unconditional-flush-to-poc-when-mapping-to-stage-2.patch new file mode 100644 index 00000000000..8ce1e781941 --- /dev/null +++ b/queue-4.9/arm-arm64-kvm-enforce-unconditional-flush-to-poc-when-mapping-to-stage-2.patch @@ -0,0 +1,73 @@ +From 8f36ebaf21fdae99c091c67e8b6fab33969f2667 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +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 + +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 +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman + +--- + 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, diff --git a/queue-4.9/arm64-dma-mapping-fix-dma_mapping_error-when-bypassing-swiotlb.patch b/queue-4.9/arm64-dma-mapping-fix-dma_mapping_error-when-bypassing-swiotlb.patch new file mode 100644 index 00000000000..8331d1af06b --- /dev/null +++ b/queue-4.9/arm64-dma-mapping-fix-dma_mapping_error-when-bypassing-swiotlb.patch @@ -0,0 +1,54 @@ +From adbe7e26f4257f72817495b9bce114284060b0d7 Mon Sep 17 00:00:00 2001 +From: Robin Murphy +Date: Wed, 25 Jan 2017 18:31:31 +0000 +Subject: arm64: dma-mapping: Fix dma_mapping_error() when bypassing SWIOTLB + +From: Robin Murphy + +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 +Reported-by: Aaro Koskinen +Signed-off-by: Robin Murphy +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.9/arm64-fix-erroneous-__raw_read_system_reg-cases.patch b/queue-4.9/arm64-fix-erroneous-__raw_read_system_reg-cases.patch new file mode 100644 index 00000000000..ee01c91d168 --- /dev/null +++ b/queue-4.9/arm64-fix-erroneous-__raw_read_system_reg-cases.patch @@ -0,0 +1,53 @@ +From 7d0928f18bf890d2853281f59aba0dd5a46b34f9 Mon Sep 17 00:00:00 2001 +From: Mark Rutland +Date: Thu, 2 Feb 2017 17:32:14 +0000 +Subject: arm64: fix erroneous __raw_read_system_reg() cases + +From: Mark Rutland + +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 +Fixes: da8d02d19ffdd201 ("arm64/capabilities: Make use of system wide safe value") +Reported-by: Catalin Marinas +Cc: Suzuki K Poulose +Cc: Will Deacon +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.9/crypto-testmgr-pad-aes_ccm_enc_tv_template-vector.patch b/queue-4.9/crypto-testmgr-pad-aes_ccm_enc_tv_template-vector.patch new file mode 100644 index 00000000000..db3b2390a7c --- /dev/null +++ b/queue-4.9/crypto-testmgr-pad-aes_ccm_enc_tv_template-vector.patch @@ -0,0 +1,83 @@ +From 1c68bb0f62bf8de8bb30123ea840d5168f25abea Mon Sep 17 00:00:00 2001 +From: Laura Abbott +Date: Tue, 28 Feb 2017 14:07:25 -0800 +Subject: crypto: testmgr - Pad aes_ccm_enc_tv_template vector + +From: Laura Abbott + +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 +Signed-off-by: Laura Abbott +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + 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" diff --git a/queue-4.9/fuse-add-missing-fr_force.patch b/queue-4.9/fuse-add-missing-fr_force.patch new file mode 100644 index 00000000000..0683b89b65a --- /dev/null +++ b/queue-4.9/fuse-add-missing-fr_force.patch @@ -0,0 +1,34 @@ +From 2e38bea99a80eab408adee27f873a188d57b76cb Mon Sep 17 00:00:00 2001 +From: Miklos Szeredi +Date: Wed, 22 Feb 2017 20:08:25 +0100 +Subject: fuse: add missing FR_FORCE + +From: Miklos Szeredi + +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 +Fixes: 5a18ec176c93 ("fuse: fix hang of single threaded fuseblk filesystem") +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.9/iio-pressure-mpl115-do-not-rely-on-structure-field-ordering.patch b/queue-4.9/iio-pressure-mpl115-do-not-rely-on-structure-field-ordering.patch new file mode 100644 index 00000000000..62bc00de025 --- /dev/null +++ b/queue-4.9/iio-pressure-mpl115-do-not-rely-on-structure-field-ordering.patch @@ -0,0 +1,51 @@ +From 6a6e1d56a0769795a36c0461c64bf5e5b9bbb4c0 Mon Sep 17 00:00:00 2001 +From: Peter Rosin +Date: Wed, 1 Feb 2017 21:40:57 +0100 +Subject: iio: pressure: mpl115: do not rely on structure field ordering + +From: Peter Rosin + +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 +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + 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), + }, + }; diff --git a/queue-4.9/iio-pressure-mpl3115-do-not-rely-on-structure-field-ordering.patch b/queue-4.9/iio-pressure-mpl3115-do-not-rely-on-structure-field-ordering.patch new file mode 100644 index 00000000000..d5c468cf3ed --- /dev/null +++ b/queue-4.9/iio-pressure-mpl3115-do-not-rely-on-structure-field-ordering.patch @@ -0,0 +1,128 @@ +From 9cf6cdba586ced75c69b8314b88b2d2f5ce9b3ed Mon Sep 17 00:00:00 2001 +From: Peter Rosin +Date: Wed, 1 Feb 2017 21:40:56 +0100 +Subject: iio: pressure: mpl3115: do not rely on structure field ordering + +From: Peter Rosin + +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 : [] 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: +[] (iio_read_channel_info_avail) from [] (dev_attr_show+0x24/0x50) + r10:c0a53c74 r9:ed79f000 r8:ee8d1018 r7:00001000 r6:00000fff r5:ee8b9a00 + r4:edffd480 +[] (dev_attr_show) from [] (sysfs_kf_seq_show+0x90/0x110) + r5:edffd540 r4:edffd480 +[] (sysfs_kf_seq_show) from [] (kernfs_seq_show+0x2c/0x30) + r10:edffd480 r9:00000000 r8:ed413780 r7:00000001 r6:ed413780 r5:00000001 + r4:ee2bde60 r3:c02933e4 +[] (kernfs_seq_show) from [] (seq_read+0x1a4/0x4e0) +[] (seq_read) from [] (kernfs_fop_read+0x12c/0x1cc) + r10:ee2bdf78 r9:00020000 r8:00020000 r7:b6e37000 r6:ed413780 r5:edffd540 + r4:c0a111fc +[] (kernfs_fop_read) from [] (__vfs_read+0x34/0x118) + r10:b6e37000 r9:ee2bc000 r8:00020000 r7:ee2bdf78 r6:ed413780 r5:b6e37000 + r4:c0a111fc +[] (__vfs_read) from [] (vfs_read+0x90/0x11c) + r8:ee2bdf78 r7:00000000 r6:b6e37000 r5:ed413780 r4:00020000 +[] (vfs_read) from [] (SyS_read+0x44/0x90) + r8:00020000 r7:ed413780 r6:ed413780 r5:00000000 r4:00000000 +[] (SyS_read) from [] (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 +Tested-by: Ken Lin +Signed-off-by: Peter Rosin +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman + +--- + 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', diff --git a/queue-4.9/kvm-arm-arm64-vgic-stop-injecting-the-msi-occurrence-twice.patch b/queue-4.9/kvm-arm-arm64-vgic-stop-injecting-the-msi-occurrence-twice.patch new file mode 100644 index 00000000000..feb72f8013d --- /dev/null +++ b/queue-4.9/kvm-arm-arm64-vgic-stop-injecting-the-msi-occurrence-twice.patch @@ -0,0 +1,42 @@ +From 0bdbf3b071986ba80731203683cf623d5c0cacb1 Mon Sep 17 00:00:00 2001 +From: Shanker Donthineni +Date: Thu, 2 Feb 2017 20:30:03 -0600 +Subject: KVM: arm/arm64: vgic: Stop injecting the MSI occurrence twice + +From: Shanker Donthineni + +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 +Reviewed-by: Christoffer Dall +Signed-off-by: Shanker Donthineni +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } + diff --git a/queue-4.9/series b/queue-4.9/series index a366a64167b..d2c029e1e2c 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -84,3 +84,12 @@ pci-hotplug-pnv-php-disable-msi-and-pci-device-properly.patch 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 diff --git a/queue-4.9/x86-pkeys-check-against-max-pkey-to-avoid-overflows.patch b/queue-4.9/x86-pkeys-check-against-max-pkey-to-avoid-overflows.patch new file mode 100644 index 00000000000..1a450ccc393 --- /dev/null +++ b/queue-4.9/x86-pkeys-check-against-max-pkey-to-avoid-overflows.patch @@ -0,0 +1,73 @@ +From 58ab9a088ddac4efe823471275859d64f735577e Mon Sep 17 00:00:00 2001 +From: Dave Hansen +Date: Thu, 23 Feb 2017 14:26:03 -0800 +Subject: x86/pkeys: Check against max pkey to avoid overflows + +From: Dave Hansen + +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 +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + -- 2.47.3