commit a0768244828d0da096ce957616150220da607be1 Author: Greg Kroah-Hartman Date: Fri Jul 3 19:49:53 2015 -0700 Linux 3.14.47 commit 4811cb9e8d36b8395e884322e49deb8963e8f094 Author: Christoffer Dall Date: Tue Dec 9 14:33:45 2014 +0100 arm/arm64: KVM: Don't allow creating VCPUs after vgic_initialized commit 716139df2517fbc3f2306dbe8eba0fa88dca0189 upstream. When the vgic initializes its internal state it does so based on the number of VCPUs available at the time. If we allow KVM to create more VCPUs after the VGIC has been initialized, we are likely to error out in unfortunate ways later, perform buffer overflows etc. Acked-by: Marc Zyngier Reviewed-by: Eric Auger Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 7b3d155fd3d886f2766d42bde3ff4116bd95994c Author: Christoffer Dall Date: Thu Nov 27 10:35:03 2014 +0100 arm/arm64: KVM: Introduce stage2_unmap_vm commit 957db105c99792ae8ef61ffc9ae77d910f6471da upstream. Introduce a new function to unmap user RAM regions in the stage2 page tables. This is needed on reboot (or when the guest turns off the MMU) to ensure we fault in pages again and make the dcache, RAM, and icache coherent. Using unmap_stage2_range for the whole guest physical range does not work, because that unmaps IO regions (such as the GIC) which will not be recreated or in the best case faulted in on a page-by-page basis. Call this function on secondary and subsequent calls to the KVM_ARM_VCPU_INIT ioctl so that a reset VCPU will detect the guest Stage-1 MMU is off when faulting in pages and make the caches coherent. Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit d6f5e8769d9bc6c7ec58669c940537cca63e0b73 Author: Christoffer Dall Date: Thu Oct 16 17:21:16 2014 +0200 arm/arm64: KVM: Reset the HCR on each vcpu when resetting the vcpu commit b856a59141b1066d3c896a0d0231f84dabd040af upstream. When userspace resets the vcpu using KVM_ARM_VCPU_INIT, we should also reset the HCR, because we now modify the HCR dynamically to enable/disable trapping of guest accesses to the VM registers. This is crucial for reboot of VMs working since otherwise we will not be doing the necessary cache maintenance operations when faulting in pages with the guest MMU off. Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 97110822ab73a02e9174779b5f5c5e63a468c1d3 Author: Christoffer Dall Date: Thu Oct 16 16:14:43 2014 +0200 arm/arm64: KVM: Correct KVM_ARM_VCPU_INIT power off option commit 3ad8b3de526a76fbe9466b366059e4958957b88f upstream. The implementation of KVM_ARM_VCPU_INIT is currently not doing what userspace expects, namely making sure that a vcpu which may have been turned off using PSCI is returned to its initial state, which would be powered on if userspace does not set the KVM_ARM_VCPU_POWER_OFF flag. Implement the expected functionality and clarify the ABI. Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 21ed02b76ae27513ce2143aa5e474d860a358ca8 Author: Christoffer Dall Date: Tue Dec 2 15:27:51 2014 +0100 arm/arm64: KVM: Don't clear the VCPU_POWER_OFF flag commit 03f1d4c17edb31b41b14ca3a749ae38d2dd6639d upstream. If a VCPU was originally started with power off (typically to be brought up by PSCI in SMP configurations), there is no need to clear the POWER_OFF flag in the kernel, as this flag is only tested during the init ioctl itself. Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 38abe7a44e2119407724063030d809d5d41d24d6 Author: Ard Biesheuvel Date: Mon Nov 10 08:33:55 2014 +0000 arm/arm64: kvm: drop inappropriate use of kvm_is_mmio_pfn() commit 07a9748c78cfc39b54f06125a216b67b9c8f09ed upstream. Instead of using kvm_is_mmio_pfn() to decide whether a host region should be stage 2 mapped with device attributes, add a new static function kvm_is_device_pfn() that disregards RAM pages with the reserved bit set, as those should usually not be mapped as device memory. Signed-off-by: Ard Biesheuvel Signed-off-by: Marc Zyngier Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 1439e00610cdb4f2d8adb253dc51f083bd20049b Author: Geoff Levand Date: Fri Oct 31 23:06:47 2014 +0000 arm64/kvm: Fix assembler compatibility of macros commit 286fb1cc32b11c18da3573a8c8c37a4f9da16e30 upstream. Some of the macros defined in kvm_arm.h are useful in assembly files, but are not compatible with the assembler. Change any C language integer constant definitions using appended U, UL, or ULL to the UL() preprocessor macro. Also, add a preprocessor include of the asm/memory.h file which defines the UL() macro. Fixes build errors like these when using kvm_arm.h in assembly source files: Error: unexpected characters following instruction at operand 3 -- `and x0,x1,#((1U<<25)-1)' Acked-by: Mark Rutland Signed-off-by: Geoff Levand Signed-off-by: Will Deacon Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit de20651c83c29cf701ea3808da17dc670bc8c5c5 Author: Christoffer Dall Date: Thu Nov 6 11:47:39 2014 +0000 arm/arm64: KVM: vgic: Fix error code in kvm_vgic_create() commit 6b50f54064a02b77a7b990032b80234fee59bcd6 upstream. If we detect another vCPU is running we just exit and return 0 as if we succesfully created the VGIC, but the VGIC wouldn't actual be created. This shouldn't break in-kernel behavior because the kernel will not observe the failed the attempt to create the VGIC, but userspace could be rightfully confused. Cc: Andre Przywara Signed-off-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Paolo Bonzini Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 0bb169d7fb507623c506a5dde870e72850bc6ce3 Author: Mark Rutland Date: Tue Oct 28 19:36:45 2014 +0000 arm64: KVM: fix unmapping with 48-bit VAs commit 7cbb87d67e38cfc55680290a706fd7517f10050d upstream. Currently if using a 48-bit VA, tearing down the hyp page tables (which can happen in the absence of a GICH or GICV resource) results in the rather nasty splat below, evidently becasue we access a table that doesn't actually exist. Commit 38f791a4e499792e (arm64: KVM: Implement 48 VA support for KVM EL2 and Stage-2) added a pgd_none check to __create_hyp_mappings to account for the additional level of tables, but didn't add a corresponding check to unmap_range, and this seems to be the source of the problem. This patch adds the missing pgd_none check, ensuring we don't try to access tables that don't exist. Original splat below: kvm [1]: Using HYP init bounce page @83fe94a000 kvm [1]: Cannot obtain GICH resource Unable to handle kernel paging request at virtual address ffff7f7fff000000 pgd = ffff800000770000 [ffff7f7fff000000] *pgd=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc2+ #89 task: ffff8003eb500000 ti: ffff8003eb45c000 task.ti: ffff8003eb45c000 PC is at unmap_range+0x120/0x580 LR is at free_hyp_pgds+0xac/0xe4 pc : [] lr : [] pstate: 80000045 sp : ffff8003eb45fbf0 x29: ffff8003eb45fbf0 x28: ffff800000736000 x27: ffff800000735000 x26: ffff7f7fff000000 x25: 0000000040000000 x24: ffff8000006f5000 x23: 0000000000000000 x22: 0000007fffffffff x21: 0000800000000000 x20: 0000008000000000 x19: 0000000000000000 x18: ffff800000648000 x17: ffff800000537228 x16: 0000000000000000 x15: 000000000000001f x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000020 x11: 0000000000000062 x10: 0000000000000006 x9 : 0000000000000000 x8 : 0000000000000063 x7 : 0000000000000018 x6 : 00000003ff000000 x5 : ffff800000744188 x4 : 0000000000000001 x3 : 0000000040000000 x2 : ffff800000000000 x1 : 0000007fffffffff x0 : 000000003fffffff Process swapper/0 (pid: 1, stack limit = 0xffff8003eb45c058) Stack: (0xffff8003eb45fbf0 to 0xffff8003eb460000) fbe0: eb45fcb0 ffff8003 0009cad8 ffff8000 fc00: 00000000 00000080 00736140 ffff8000 00736000 ffff8000 00000000 00007c80 fc20: 00000000 00000080 006f5000 ffff8000 00000000 00000080 00743000 ffff8000 fc40: 00735000 ffff8000 006d3030 ffff8000 006fe7b8 ffff8000 00000000 00000080 fc60: ffffffff 0000007f fdac1000 ffff8003 fd94b000 ffff8003 fda47000 ffff8003 fc80: 00502b40 ffff8000 ff000000 ffff7f7f fdec6000 00008003 fdac1630 ffff8003 fca0: eb45fcb0 ffff8003 ffffffff 0000007f eb45fd00 ffff8003 0009b378 ffff8000 fcc0: ffffffea 00000000 006fe000 ffff8000 00736728 ffff8000 00736120 ffff8000 fce0: 00000040 00000000 00743000 ffff8000 006fe7b8 ffff8000 0050cd48 00000000 fd00: eb45fd60 ffff8003 00096070 ffff8000 006f06e0 ffff8000 006f06e0 ffff8000 fd20: fd948b40 ffff8003 0009a320 ffff8000 00000000 00000000 00000000 00000000 fd40: 00000ae0 00000000 006aa25c ffff8000 eb45fd60 ffff8003 0017ca44 00000002 fd60: eb45fdc0 ffff8003 0009a33c ffff8000 006f06e0 ffff8000 006f06e0 ffff8000 fd80: fd948b40 ffff8003 0009a320 ffff8000 00000000 00000000 00735000 ffff8000 fda0: 006d3090 ffff8000 006aa25c ffff8000 00735000 ffff8000 006d3030 ffff8000 fdc0: eb45fdd0 ffff8003 000814c0 ffff8000 eb45fe50 ffff8003 006aaac4 ffff8000 fde0: 006ddd90 ffff8000 00000006 00000000 006d3000 ffff8000 00000095 00000000 fe00: 006a1e90 ffff8000 00735000 ffff8000 006d3000 ffff8000 006aa25c ffff8000 fe20: 00735000 ffff8000 006d3030 ffff8000 eb45fe50 ffff8003 006fac68 ffff8000 fe40: 00000006 00000006 fe293ee6 ffff8003 eb45feb0 ffff8003 004f8ee8 ffff8000 fe60: 004f8ed4 ffff8000 00735000 ffff8000 00000000 00000000 00000000 00000000 fe80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 fea0: 00000000 00000000 00000000 00000000 00000000 00000000 000843d0 ffff8000 fec0: 004f8ed4 ffff8000 00000000 00000000 00000000 00000000 00000000 00000000 fee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ff00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ff20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ff40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ff60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ff80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffa0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000005 00000000 ffe0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Call trace: [] unmap_range+0x120/0x580 [] free_hyp_pgds+0xa8/0xe4 [] kvm_arch_init+0x268/0x44c [] kvm_init+0x24/0x260 [] arm_init+0x18/0x24 [] do_one_initcall+0x88/0x1a0 [] kernel_init_freeable+0x148/0x1e8 [] kernel_init+0x10/0xd4 Code: 8b000263 92628479 d1000720 eb01001f (f9400340) ---[ end trace 3bc230562e926fa4 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Jungseok Lee Acked-by: Marc Zyngier Acked-by: Christoffer Dall Signed-off-by: Marc Zyngier Signed-off-by: Paolo Bonzini Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 78760f7994ce49d907d1424f3f1f151639dad751 Author: Steve Capper Date: Tue Oct 14 15:02:15 2014 +0100 arm: kvm: STRICT_MM_TYPECHECKS fix for user_mem_abort commit 3d08c629244257473450a8ba17cb8184b91e68f8 upstream. Commit: b886576 ARM: KVM: user_mem_abort: support stage 2 MMIO page mapping introduced some code in user_mem_abort that failed to compile if STRICT_MM_TYPECHECKS was enabled. This patch fixes up the failing comparison. Signed-off-by: Steve Capper Reviewed-by: Kim Phillips Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 02524d7e8bc8e72e4813eb7de44c52be1ce6d73b Author: Christoffer Dall Date: Fri Oct 10 12:14:29 2014 +0200 arm/arm64: KVM: Ensure memslots are within KVM_PHYS_SIZE commit c3058d5da2222629bc2223c488a4512b59bb4baf upstream. [Since we don't backport commit 8eef912 (arm/arm64: KVM: map MMIO regions at creation time) for linux-3.14.y, the context of this patch is different, while the change itself is same.] When creating or moving a memslot, make sure the IPA space is within the addressable range of the guest. Otherwise, user space can create too large a memslot and KVM would try to access potentially unallocated page table entries when inserting entries in the Stage-2 page tables. Acked-by: Catalin Marinas Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit e5890a3e839ab92da899f9f6d2bfd0e9a06c55b2 Author: Ard Biesheuvel Date: Wed Sep 17 14:56:17 2014 -0700 arm/arm64: KVM: fix potential NULL dereference in user_mem_abort() commit 37b544087ef3f65ca68465ba39291a07195dac26 upstream. Handle the potential NULL return value of find_vma_intersection() before dereferencing it. Acked-by: Marc Zyngier Signed-off-by: Ard Biesheuvel Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 42846f9b74fdb743c0ed4be08dc67365f98a81d4 Author: Vladimir Murzin Date: Mon Sep 22 15:52:48 2014 +0100 arm: kvm: fix CPU hotplug commit 37a34ac1d4775aafbc73b9db53c7daebbbc67e6a upstream. On some platforms with no power management capabilities, the hotplug implementation is allowed to return from a smp_ops.cpu_die() call as a function return. Upon a CPU onlining event, the KVM CPU notifier tries to reinstall the hyp stub, which fails on platform where no reset took place following a hotplug event, with the message: CPU1: smp_ops.cpu_die() returned, trying to resuscitate CPU1: Booted secondary processor Kernel panic - not syncing: unexpected prefetch abort in Hyp mode at: 0x80409540 unexpected data abort in Hyp mode at: 0x80401fe8 unexpected HVC/SVC trap in Hyp mode at: 0x805c6170 since KVM code is trying to reinstall the stub on a system where it is already configured. To prevent this issue, this patch adds a check in the KVM hotplug notifier that detects if the HYP stub really needs re-installing when a CPU is onlined and skips the installation call if the stub is already in place, which means that the CPU has not been reset. Signed-off-by: Vladimir Murzin Acked-by: Lorenzo Pieralisi Acked-by: Marc Zyngier Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 70d011e1c968dd17bbf497c4b72dbf897278fad8 Author: Joel Schopp Date: Wed Jul 9 11:17:04 2014 -0500 arm/arm64: KVM: Fix VTTBR_BADDR_MASK and pgd alloc commit dbff124e29fa24aff9705b354b5f4648cd96e0bb upstream. The current aarch64 calculation for VTTBR_BADDR_MASK masks only 39 bits and not all the bits in the PA range. This is clearly a bug that manifests itself on systems that allocate memory in the higher address space range. [ Modified from Joel's original patch to be based on PHYS_MASK_SHIFT instead of a hard-coded value and to move the alignment check of the allocation to mmu.c. Also added a comment explaining why we hardcode the IPA range and changed the stage-2 pgd allocation to be based on the 40 bit IPA range instead of the maximum possible 48 bit PA range. - Christoffer ] Reviewed-by: Catalin Marinas Signed-off-by: Joel Schopp Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 009ac1f72ca7cc631fae7b07333c3c8e5d7bccf6 Author: Christoffer Dall Date: Thu Sep 25 18:41:07 2014 +0200 arm/arm64: KVM: Fix set_clear_sgi_pend_reg offset commit 0fea6d7628ed6e25a9ee1b67edf7c859718d39e8 upstream. The sgi values calculated in read_set_clear_sgi_pend_reg() and write_set_clear_sgi_pend_reg() were horribly incorrectly multiplied by 4 with catastrophic results in that subfunctions ended up overwriting memory not allocated for the expected purpose. This showed up as bugs in kfree() and the kernel complaining a lot of you turn on memory debugging. This addresses: http://marc.info/?l=kvm&m=141164910007868&w=2 Reported-by: Shannon Zhao Signed-off-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 79f03a7665abcb4121a091a0f2008ea83c4bb0d1 Author: Marc Zyngier Date: Tue Jul 8 12:09:00 2014 +0100 KVM: ARM: vgic: plug irq injection race commit 71afaba4a2e98bb7bdeba5078370ab43d46e67a1 upstream. [Since we don't backport commit 227844f (arm/arm64: KVM: Rename irq_state to irq_pending) for linux-3.14.y, here we still use vgic_update_irq_state instead of vgic_update_irq_pending.] As it stands, nothing prevents userspace from injecting an interrupt before the guest's GIC is actually initialized. This goes unnoticed so far (as everything is pretty much statically allocated), but ends up exploding in a spectacular way once we switch to a more dynamic allocation (the GIC data structure isn't there yet). The fix is to test for the "ready" flag in the VGIC distributor before trying to inject the interrupt. Note that in order to avoid breaking userspace, we have to ignore what is essentially an error. Signed-off-by: Marc Zyngier Acked-by: Christoffer Dall Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit be255a24d4599e3aae60007e1cbc499f61a092fa Author: Ard Biesheuvel Date: Tue Sep 9 11:27:09 2014 +0100 ARM/arm64: KVM: fix use of WnR bit in kvm_is_write_fault() commit a7d079cea2dffb112e26da2566dd84c0ef1fce97 upstream. [Since we don't backport commit 9804788 (arm/arm64: KVM: Support KVM_CAP_READONLY_MEM), ingore the changes in kvm_handle_guest_abort introduced by this patch.] The ISS encoding for an exception from a Data Abort has a WnR bit[6] that indicates whether the Data Abort was caused by a read or a write instruction. While there are several fields in the encoding that are only valid if the ISV bit[24] is set, WnR is not one of them, so we can read it unconditionally. Instead of fixing both implementations of kvm_is_write_fault() in place, reimplement it just once using kvm_vcpu_dabt_iswrite(), which already does the right thing with respect to the WnR bit. Also fix up the callers to pass 'vcpu' Acked-by: Laszlo Ersek Acked-by: Marc Zyngier Acked-by: Christoffer Dall Signed-off-by: Ard Biesheuvel Signed-off-by: Marc Zyngier Signed-off-by: Shannon Zhao Signed-off-by: Greg Kroah-Hartman commit 51a73e8859c3d38cf9cc9f5b374abc36078e5eef Author: Greg Ungerer Date: Mon Apr 14 15:47:01 2014 +0200 bus: mvebu: pass the coherency availability information at init time commit 5686a1e5aa436c49187a60052d5885fb1f541ce6 upstream. Until now, the mvebu-mbus was guessing by itself whether hardware I/O coherency was available or not by poking into the Device Tree to see if the coherency fabric Device Tree node was present or not. However, on some upcoming SoCs, the presence or absence of the coherency fabric DT node isn't sufficient: in CONFIG_SMP, the coherency can be enabled, but not in !CONFIG_SMP. In order to clean this up, the mvebu_mbus_dt_init() function is extended to get a boolean argument telling whether coherency is enabled or not. Therefore, the logic to decide whether coherency is available or not now belongs to the core SoC code instead of the mvebu-mbus driver itself, which is much better. Signed-off-by: Thomas Petazzoni Link: https://lkml.kernel.org/r/1397483228-25625-4-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper [ Greg Ungerer: back ported to linux-3.14.y Back port necessary due to large code differences in affected files. This change in combination with commit e553554536 ("ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/375/38x/XP") is critical to the hardware I/O coherency being set correctly by both the mbus driver and all peripheral hardware drivers. Without this change drivers will incorrectly enable I/O coherency window attributes and this causes rare unreliable system behavior including oops. ] Signed-off-by: Greg Ungerer Signed-off-by: Greg Kroah-Hartman commit 580201425a781e0b3fb43a089747d3aebd8b31ea Author: Bandan Das Date: Thu Jun 11 02:05:33 2015 -0400 KVM: nSVM: Check for NRIPS support before updating control field commit f104765b4f81fd74d69e0eb161e89096deade2db upstream. If hardware doesn't support DecodeAssist - a feature that provides more information about the intercept in the VMCB, KVM decodes the instruction and then updates the next_rip vmcb control field. However, NRIP support itself depends on cpuid Fn8000_000A_EDX[NRIPS]. Since skip_emulated_instruction() doesn't verify nrip support before accepting control.next_rip as valid, avoid writing this field if support isn't present. Signed-off-by: Bandan Das Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 3a3ac04f0e0ef48c2d30ae6df7b8906421c2b35d Author: Sebastien Szymanski Date: Wed May 20 16:30:37 2015 +0200 ARM: clk-imx6q: refine sata's parent commit da946aeaeadcd24ff0cda9984c6fb8ed2bfd462a upstream. According to IMX6D/Q RM, table 18-3, sata clock's parent is ahb, not ipg. Signed-off-by: Sebastien Szymanski Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo [dirk.behme: Adjust moved file] Signed-off-by: Dirk Behme Signed-off-by: Greg Kroah-Hartman commit b292fc7723b66d9796ae550b284223d95019ac44 Author: Ben Hutchings Date: Thu Jan 29 02:50:33 2015 +0000 splice: Apply generic position and size checks to each write commit 894c6350eaad7e613ae267504014a456e00a3e2a from the 3.2-stable branch. We need to check the position and size of file writes against various limits, using generic_write_check(). This was not being done for the splice write path. It was fixed upstream by commit 8d0207652cbe ("->splice_write() via ->write_iter()") but we can't apply that. CVE-2014-7822 Signed-off-by: Ben Hutchings Cc: Vinson Lee Signed-off-by: Greg Kroah-Hartman commit ac17ab9b37774017674d11fc3a9f01f815c230e9 Author: Or Gerlitz Date: Thu Oct 30 15:59:27 2014 +0200 net/mlx4_en: Don't attempt to TX offload the outer UDP checksum for VXLAN commit a4f2dacbf2a5045e34b98a35d9a3857800f25a7b upstream. For VXLAN/NVGRE encapsulation, the current HW doesn't support offloading both the outer UDP TX checksum and the inner TCP/UDP TX checksum. The driver doesn't advertize SKB_GSO_UDP_TUNNEL_CSUM, however we are wrongly telling the HW to offload the outer UDP checksum for encapsulated packets, fix that. Fixes: 837052d0ccc5 ('net/mlx4_en: Add netdev support for TCP/IP offloads of vxlan tunneling') Signed-off-by: Or Gerlitz Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 02590fd855d1690568b2fa439c942e933221b57a Author: Filipe Manana Date: Sun Nov 9 08:38:39 2014 +0000 Btrfs: make xattr replace operations atomic commit 5f5bc6b1e2d5a6f827bc860ef2dc5b6f365d1339 upstream. Replacing a xattr consists of doing a lookup for its existing value, delete the current value from the respective leaf, release the search path and then finally insert the new value. This leaves a time window where readers (getxattr, listxattrs) won't see any value for the xattr. Xattrs are used to store ACLs, so this has security implications. This change also fixes 2 other existing issues which were: *) Deleting the old xattr value without verifying first if the new xattr will fit in the existing leaf item (in case multiple xattrs are packed in the same item due to name hash collision); *) Returning -EEXIST when the flag XATTR_CREATE is given and the xattr doesn't exist but we have have an existing item that packs muliple xattrs with the same name hash as the input xattr. In this case we should return ENOSPC. A test case for xfstests follows soon. Thanks to Alexandre Oliva for reporting the non-atomicity of the xattr replace implementation. Reported-by: Alexandre Oliva Signed-off-by: Filipe Manana Signed-off-by: Chris Mason Signed-off-by: Greg Kroah-Hartman commit 77544e78c388cc755c056f451b322dedba991c0a Author: Quentin Casasnovas Date: Tue Feb 3 13:00:22 2015 +0100 x86/microcode/intel: Guard against stack overflow in the loader commit f84598bd7c851f8b0bf8cd0d7c3be0d73c432ff4 upstream. mc_saved_tmp is a static array allocated on the stack, we need to make sure mc_saved_count stays within its bounds, otherwise we're overflowing the stack in _save_mc(). A specially crafted microcode header could lead to a kernel crash or potentially kernel execution. Signed-off-by: Quentin Casasnovas Cc: "H. Peter Anvin" Cc: Fenghua Yu Link: http://lkml.kernel.org/r/1422964824-22056-1-git-send-email-quentin.casasnovas@oracle.com Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit d68014d7b064d3d735296a6bb828c701162f1a66 Author: Tomas Henzl Date: Fri Sep 12 14:44:15 2014 +0200 hpsa: add missing pci_set_master in kdump path commit 859c75aba20264d87dd026bab0d0ca3bff385955 upstream. Add a call to pci_set_master(...) missing in the previous patch "hpsa: refine the pci enable/disable handling". Found thanks to Rob Elliot. Signed-off-by: Tomas Henzl Reviewed-by: Robert Elliott Tested-by: Robert Elliott Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit a374854f755a53f839abceb1cf0ff95b3d563339 Author: Pablo Neira Ayuso Date: Tue Mar 17 13:21:42 2015 +0100 netfilter: nf_tables: allow to change chain policy without hook if it exists commit d6b6cb1d3e6f78d55c2d4043d77d0d8def3f3b99 upstream. If there's an existing base chain, we have to allow to change the default policy without indicating the hook information. However, if the chain doesn't exists, we have to enforce the presence of the hook attribute. Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit b89c87de3c8836ef14e643ce89684a2a2afb9bb5 Author: Pablo Neira Ayuso Date: Sat Mar 21 19:25:05 2015 +0100 netfilter: nft_compat: set IP6T_F_PROTO flag if protocol is set commit 749177ccc74f9c6d0f51bd78a15c652a2134aa11 upstream. ip6tables extensions check for this flag to restrict match/target to a given protocol. Without this flag set, SYNPROXY6 returns an error. Signed-off-by: Pablo Neira Ayuso Acked-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman commit b2e7c364e03f9aa8b11c3b1f30d83e7ed255fe9a Author: Ian Wilson Date: Thu Mar 12 09:37:58 2015 +0000 netfilter: Zero the tuple in nfnl_cthelper_parse_tuple() commit 78146572b9cd20452da47951812f35b1ad4906be upstream. nfnl_cthelper_parse_tuple() is called from nfnl_cthelper_new(), nfnl_cthelper_get() and nfnl_cthelper_del(). In each case they pass a pointer to an nf_conntrack_tuple data structure local variable: struct nf_conntrack_tuple tuple; ... ret = nfnl_cthelper_parse_tuple(&tuple, tb[NFCTH_TUPLE]); The problem is that this local variable is not initialized, and nfnl_cthelper_parse_tuple() only initializes two fields: src.l3num and dst.protonum. This leaves all other fields with undefined values based on whatever is on the stack: tuple->src.l3num = ntohs(nla_get_be16(tb[NFCTH_TUPLE_L3PROTONUM])); tuple->dst.protonum = nla_get_u8(tb[NFCTH_TUPLE_L4PROTONUM]); The symptom observed was that when the rpc and tns helpers were added then traffic to port 1536 was being sent to user-space. Signed-off-by: Ian Wilson Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit c8371574991021825d76ce7e1cc996078c60f41b Author: Tomas Henzl Date: Thu Aug 14 16:12:39 2014 +0200 hpsa: refine the pci enable/disable handling commit 132aa220b45d60e9b20def1e9d8be9422eed9616 upstream. When a second(kdump) kernel starts and the hard reset method is used the driver calls pci_disable_device without previously enabling it, so the kernel shows a warning - [ 16.876248] WARNING: at drivers/pci/pci.c:1431 pci_disable_device+0x84/0x90() [ 16.882686] Device hpsa disabling already-disabled device ... This patch fixes it, in addition to this I tried to balance also some other pairs of enable/disable device in the driver. Unfortunately I wasn't able to verify the functionality for the case of a sw reset, because of a lack of proper hw. Signed-off-by: Tomas Henzl Reviewed-by: Stephen M. Cameron Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit ece9210859abb2cc0126f8adbfbbdee668d4906a Author: Jim Snow Date: Tue Nov 18 14:51:09 2014 +0100 sb_edac: Fix erroneous bytes->gigabytes conversion commit 8c009100295597f23978c224aec5751a365bc965 upstream. Signed-off-by: Jim Snow Signed-off-by: Lukasz Anaczkowski Signed-off-by: Mauro Carvalho Chehab [ vlee: Backported to 3.14. Adjusted context. ] Signed-off-by: Vinson Lee Signed-off-by: Greg Kroah-Hartman commit d21c3b33bba6b263e67c65cc8854e6b6e940ff1d Author: Chen Gang Date: Wed Dec 24 23:04:54 2014 +0800 netfilter: nfnetlink_cthelper: Remove 'const' and '&' to avoid warnings commit b18c5d15e8714336365d9d51782d5b53afa0443c upstream. The related code can be simplified, and also can avoid related warnings (with allmodconfig under parisc): CC [M] net/netfilter/nfnetlink_cthelper.o net/netfilter/nfnetlink_cthelper.c: In function ‘nfnl_cthelper_from_nlattr’: net/netfilter/nfnetlink_cthelper.c:97:9: warning: passing argument 1 o ‘memcpy’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-array-qualifiers] memcpy(&help->data, nla_data(attr), help->helper->data_len); ^ In file included from include/linux/string.h:17:0, from include/uapi/linux/uuid.h:25, from include/linux/uuid.h:23, from include/linux/mod_devicetable.h:12, from ./arch/parisc/include/asm/hardware.h:4, from ./arch/parisc/include/asm/processor.h:15, from ./arch/parisc/include/asm/spinlock.h:6, from ./arch/parisc/include/asm/atomic.h:21, from include/linux/atomic.h:4, from ./arch/parisc/include/asm/bitops.h:12, from include/linux/bitops.h:36, from include/linux/kernel.h:10, from include/linux/list.h:8, from include/linux/module.h:9, from net/netfilter/nfnetlink_cthelper.c:11: ./arch/parisc/include/asm/string.h:8:8: note: expected ‘void *’ but argument is of type ‘const char (*)[]’ void * memcpy(void * dest,const void *src,size_t count); ^ Signed-off-by: Chen Gang Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit d5d37cb10aa6a098aab22ac7ae4e0a96d5ac89f4 Author: Konrad Rzeszutek Wilk Date: Fri Apr 17 15:04:48 2015 -0400 config: Enable NEED_DMA_MAP_STATE by default when SWIOTLB is selected commit a6dfa128ce5c414ab46b1d690f7a1b8decb8526d upstream. A huge amount of NIC drivers use the DMA API, however if compiled under 32-bit an very important part of the DMA API can be ommitted leading to the drivers not working at all (especially if used with 'swiotlb=force iommu=soft'). As Prashant Sreedharan explains it: "the driver [tg3] uses DEFINE_DMA_UNMAP_ADDR(), dma_unmap_addr_set() to keep a copy of the dma "mapping" and dma_unmap_addr() to get the "mapping" value. On most of the platforms this is a no-op, but ... with "iommu=soft and swiotlb=force" this house keeping is required, ... otherwise we pass 0 while calling pci_unmap_/pci_dma_sync_ instead of the DMA address." As such enable this even when using 32-bit kernels. Reported-by: Ian Jackson Signed-off-by: Konrad Rzeszutek Wilk Acked-by: David S. Miller Acked-by: Prashant Sreedharan Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Michael Chan Cc: Thomas Gleixner Cc: boris.ostrovsky@oracle.com Cc: cascardo@linux.vnet.ibm.com Cc: david.vrabel@citrix.com Cc: sanjeevb@broadcom.com Cc: siva.kallam@broadcom.com Cc: vyasevich@gmail.com Cc: xen-devel@lists.xensource.com Link: http://lkml.kernel.org/r/20150417190448.GA9462@l.oracle.com Signed-off-by: Ingo Molnar Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit f3fb38ae7386eeff5913251950e285efa86a3b24 Author: Eugene Shatokhin Date: Tue Mar 17 19:09:18 2015 +0900 kprobes/x86: Return correct length in __copy_instruction() commit c80e5c0c23ce2282476fdc64c4b5e3d3a40723fd upstream. On x86-64, __copy_instruction() always returns 0 (error) if the instruction uses %rip-relative addressing. This is because kernel_insn_init() is called the second time for 'insn' instance in such cases and sets all its fields to 0. Because of this, trying to place a kprobe on such instruction will fail, register_kprobe() will return -EINVAL. This patch fixes the problem. Signed-off-by: Eugene Shatokhin Signed-off-by: Masami Hiramatsu Link: http://lkml.kernel.org/r/20150317100918.28349.94654.stgit@localhost.localdomain Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 22ff38e850b7fc87bdcccbebe92c3e7764ffe389 Author: Marek Szyprowski Date: Thu Apr 23 12:46:16 2015 +0100 arm64: dma-mapping: always clear allocated buffers commit 6829e274a623187c24f7cfc0e3d35f25d087fcc5 upstream. Buffers allocated by dma_alloc_coherent() are always zeroed on Alpha, ARM (32bit), MIPS, PowerPC, x86/x86_64 and probably other architectures. It turned out that some drivers rely on this 'feature'. Allocated buffer might be also exposed to userspace with dma_mmap() call, so clearing it is desired from security point of view to avoid exposing random memory to userspace. This patch unifies dma_alloc_coherent() behavior on ARM64 architecture with other implementations by unconditionally zeroing allocated buffer. Signed-off-by: Marek Szyprowski [will: ported to 3.14.y] Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman