- 28 Feb, 2018 8 commits
-
-
Stefan Windfeldt-Prytz authored
commit 4cd140bd upstream. If no iio buffer has been set up and poll is called return 0. Without this check there will be a null pointer dereference when calling poll on a iio driver without an iio buffer. Cc: stable@vger.kernel.org Signed-off-by:
Stefan Windfeldt-Prytz <stefan.windfeldt@axis.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
commit bee92d06 upstream. gcc-8 warns about some obviously incorrect code: net/mac80211/cfg.c: In function 'cfg80211_beacon_dup': net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict] From the context, I conclude that we want to copy from beacon into new_beacon, as we do in the rest of the function. Cc: stable@vger.kernel.org Fixes: 73da7d5b ("mac80211: add channel switch command and beacon callbacks") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Tyrel Datwyler authored
commit c3981365 upstream. The fcp_rsp_info structure as defined in the FC spec has an initial 3 bytes reserved field. The ibmvfc driver mistakenly defined this field as 4 bytes resulting in the rsp_code field being defined in what should be the start of the second reserved field and thus always being reported as zero by the driver. Ideally, we should wire ibmvfc up with libfc for the sake of code deduplication, and ease of maintaining standardized structures in a single place. However, for now simply fixup the definition in ibmvfc for backporting to distros on older kernels. Wiring up with libfc will be done in a followup patch. Cc: <stable@vger.kernel.org> Reported-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Paolo Abeni authored
commit f27337e1 upstream. After the commit e09acddf ("ip_tunnel: replace dst_cache with generic implementation"), a preemption debug warning is triggered on ip4 tunnels updating; the dst cache helper needs to be invoked in unpreemptible context. We don't need to load the cache on tunnel update, so this commit fixes the warning replacing the load with a dst cache reset, which is preempt safe. Fixes: e09acddf ("ip_tunnel: replace dst_cache with generic implementation") Reported-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Paolo Abeni authored
commit e09acddf upstream. The current ip_tunnel cache implementation is prone to a race that will cause the wrong dst to be cached on cuncurrent dst cache miss and ip tunnel update via netlink. Replacing with the generic implementation fix the issue. Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Johan Hovold authored
commit eac56aa3 upstream. Fix child-node lookup during initialisation which was using the wrong OF-helper and ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent pci node could end up being prematurely freed as of_find_node_by_name() drops a reference to its first argument. Any matching child interrupt-controller node was also leaked. Fixes: 0c4ffcfe ("PCI: keystone: Add TI Keystone PCIe driver") Cc: stable <stable@vger.kernel.org> # 3.18 Acked-by:
Murali Karicheri <m-karicheri2@ti.com> Signed-off-by:
Johan Hovold <johan@kernel.org> [lorenzo.pieralisi@arm.com: updated commit subject] Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> [johan: backport to 4.4] Signed-off-by:
-
Michael Ellerman authored
The backport of commit aa8a5e00 ("powerpc/64s: Add support for RFI flush of L1-D cache"), incorrectly placed the new RFI flush code inside an existing #ifdef CONFIG_HARDLOCKUP_DETECTOR block. This has the obvious effect of requiring HARDLOCKUP_DETECTOR to be enabled in order for RFI flush to be enabled, which is a bug. Fix it by moving the #endif up to where it belongs. Fixes: c3892946 ("powerpc/64s: Add support for RFI flush of L1-D cache") Reported-by:
Bernhard Kaindl <bernhard.kaindl@thalesgroup.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Paolo Abeni authored
commit 01ea306f upstream. The Syzbot reported a possible deadlock in the netfilter area caused by rtnl lock, xt lock and socket lock being acquired with a different order on different code paths, leading to the following backtrace: Reviewed-by:
Xin Long <lucien.xin@gmail.com> ====================================================== WARNING: possible circular locking dependency detected 4.15.0+ #301 Not tainted ------------------------------------------------------ syzkaller233489/4179 is trying to acquire lock: (rtnl_mutex){+.+.}, at: [<0000000048e996fd>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74 but task is already holding lock: (&xt[i].mutex){+.+.}, at: [<00000000328553a2>] xt_find_table_lock+0x3e/0x3e0 net/netfilter/x_tables.c:1041 which lock already depends on the new lock. === Since commit 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope"), we already acquire the socket lock in the innermost scope, where needed. In such commit I forgot to remove the outer-most socket lock from the getsockopt() path, this commit addresses the issues dropping it now. v1 -> v2: fix bad subj, added relavant 'fixes' tag Fixes: 22265a5c ("netfilter: xt_TEE: resolve oif using netdevice notifiers") Fixes: 202f59af ("netfilter: ipt_CLUSTERIP: do not hold dev") Fixes: 3f34cfae1230 ("netfilter: on sockopt() acquire sock lock only in the required scope") Reported-by: syzbot+ddde1c7b7ff7442d7f2d@syzkaller.appspotmail.com Suggested-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Tested-by:
Krzysztof Piotr Oledzki <ole@ans.pl> Signed-off-by:
-
- 25 Feb, 2018 32 commits
-
-
Greg Kroah-Hartman authored
-
Wu Fengguang authored
commit b73f96fc upstream. Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Kamil Konieczny authored
commit c927b080 upstream. In AES-ECB mode crypt is done with key only, so any use of IV can cause kernel Oops. Use IV only in AES-CBC and AES-CTR. Signed-off-by:
Kamil Konieczny <k.konieczny@partner.samsung.com> Reported-by:
Anand Moon <linux.amoon@gmail.com> Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Tested-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Jan Dakinevich authored
commit bcdde302 upstream - Expose all invalidation types to the L1 - Reject invvpid instruction, if L1 passed zero vpid value to single context invalidations Signed-off-by:
Jan Dakinevich <jan.dakinevich@gmail.com> Tested-by:
Ladi Prosek <lprosek@redhat.com> Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> [jwang: port to 4.4] Signed-off-by:
Jack Wang <jinpu.wang@profitbricks.com> Signed-off-by:
-
Jan Dakinevich authored
commit 63f3ac48 upstream - Remove VMX_EPT_EXTENT_INDIVIDUAL_ADDR, since there is no such type of EPT invalidation - Add missing VPID types names Signed-off-by:
-
Jim Mattson authored
commit 85c856b3 upstream Bitwise shifts by amounts greater than or equal to the width of the left operand are undefined. A malicious guest can exploit this to crash a 32-bit host, due to the BUG_ON(1)'s in handle_{invept,invvpid}. Signed-off-by:
Jim Mattson <jmattson@google.com> Message-Id: <1477496318-17681-1-git-send-email-jmattson@google.com> [Change 1UL to 1, to match the range check on the shift count. - Paolo] Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> [jwang: port from linux-4.9 to 4.4 ] Signed-off-by:
-
David Hildenbrand authored
(cherry picked from commit 6342c50a) vmx_complete_nested_posted_interrupt() can't fail, let's turn it into a void function. Signed-off-by:
David Hildenbrand <david@redhat.com> Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> [jwang: port to 4.4] Signed-off-by:
-
David Hildenbrand authored
commit 42cf014d upstream. kmap() can't fail, therefore it will always return a valid pointer. Let's just get rid of the unnecessary checks. Signed-off-by:
-
Darren Kenny authored
(cherry picked from commit af189c95) Fixes: 117cc7a9 ("x86/retpoline: Fill return stack buffer on vmexit") Signed-off-by:
Darren Kenny <darren.kenny@oracle.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Link: https://lkml.kernel.org/r/20180202191220.blvgkgutojecxr3b@starbug-vm.ie.oracle.comSigned-off-by:
-
KarimAllah Ahmed authored
(cherry picked from commit 9005c683) [dwmw2: Use ARRAY_SIZE] Signed-off-by:
KarimAllah Ahmed <karahmed@amazon.de> Signed-off-by:
-
David Woodhouse authored
(cherry picked from commit 66f79309) There's no point in building init code with retpolines, since it runs before any potentially hostile userspace does. And before the retpoline is actually ALTERNATIVEd into place, for much of it. Signed-off-by:
-
Dan Williams authored
(cherry picked from commit 085331df) Commit 75f139aa "KVM: x86: Add memory barrier on vmcs field lookup" added a raw 'asm("lfence");' to prevent a bounds check bypass of 'vmcs_field_to_offset_table'. The lfence can be avoided in this path by using the array_index_nospec() helper designed for these types of fixes. Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Josh Poimboeuf authored
(cherry picked from commit 12c69f1e) The 'noreplace-paravirt' option disables paravirt patching, leaving the original pv indirect calls in place. That's highly incompatible with retpolines, unless we want to uglify paravirt even further and convert the paravirt calls to retpolines. As far as I can tell, the option doesn't seem to be useful for much other than introducing surprising corner cases and making the kernel vulnerable to Spectre v2. It was probably a debug option from the early paravirt days. So just remove it. Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
Juergen Gross <jgross@suse.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Jun Nakajima <jun.nakajima@intel.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jason Baron <jbaron@akamai.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Alok Kataria <akataria@vmware.com> Cc: Arjan Van De Ven <arjan.van.de.ven@intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Dan Williams <dan.j.williams@intel.com> Link: https://lkml.kernel.org/r/20180131041333.2x6blhxirc2kclrq@trebleSigned-off-by:
-
Colin Ian King authored
(cherry picked from commit e698dcdf) Trivial fix to spelling mistake in pr_err error message text. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Dan Williams authored
(cherry picked from commit edfbae53) Reflect the presence of get_user(), __get_user(), and 'syscall' protections in sysfs. The expectation is that new and better tooling will allow the kernel to grow more usages of array_index_nospec(), for now, only claim mitigation for __user pointer de-references. Reported-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Dan Williams authored
(cherry picked from commit 259d8c1e) Wireless drivers rely on parse_txq_params to validate that txq_params->ac is less than NL80211_NUM_ACS by the time the low-level driver's ->conf_tx() handler is called. Use a new helper, array_index_nospec(), to sanitize txq_params->ac with respect to speculation. I.e. ensure that any speculation into ->conf_tx() handlers is done with a value of txq_params->ac that is within the bounds of [0, NL80211_NUM_ACS). Reported-by:
Christian Lamparter <chunkeey@gmail.com> Reported-by:
Elena Reshetova <elena.reshetova@intel.com> Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Cc: linux-arch@vger.kernel.org Cc: kernel-hardening@lists.openwall.com Cc: gregkh@linuxfoundation.org Cc: linux-wireless@vger.kernel.org Cc: torvalds@linux-foundation.org Cc: "David S. Miller" <davem@davemloft.net> Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727419584.33451.7700736761686184303.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by:
-
Dan Williams authored
(cherry picked from commit 56c30ba7) 'fd' is a user controlled value that is used as a data dependency to read from the 'fdt->fd' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based on an invalid 'file *' returned from __fcheck_files. Co-developed-by:
-
Dan Williams authored
(cherry picked from commit 2fbd7af5) The syscall table base is a user controlled function pointer in kernel space. Use array_index_nospec() to prevent any out of bounds speculation. While retpoline prevents speculating into a userspace directed target it does not stop the pointer de-reference, the concern is leaking memory relative to the syscall table base, by observing instruction cache behavior. Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dan Williams authored
(cherry picked from commit c7f631cb) Quoting Linus: I do think that it would be a good idea to very expressly document the fact that it's not that the user access itself is unsafe. I do agree that things like "get_user()" want to be protected, but not because of any direct bugs or problems with get_user() and friends, but simply because get_user() is an excellent source of a pointer that is obviously controlled from a potentially attacking user space. So it's a prime candidate for then finding _subsequent_ accesses that can then be used to perturb the cache. Unlike the __get_user() case get_user() includes the address limit check near the pointer de-reference. With that locality the speculation can be mitigated with pointer narrowing rather than a barrier, i.e. array_index_nospec(). Where the narrowing is performed by: cmp %limit, %ptr sbb %mask, %mask and %mask, %ptr With respect to speculation the value of %ptr is either less than %limit or NULL. Co-developed-by:
-
Dan Williams authored
(cherry picked from commit b3d7ad85) Rename the open coded form of this instruction sequence from rdtsc_ordered() into a generic barrier primitive, barrier_nospec(). One of the mitigations for Spectre variant1 vulnerabilities is to fence speculative execution after successfully validating a bounds check. I.e. force the result of a bounds check to resolve in the instruction pipeline to ensure speculative execution honors that result before potentially operating on out-of-bounds data. No functional changes. Suggested-by:
Andi Kleen <ak@linux.intel.com> Suggested-by:
Ingo Molnar <mingo@redhat.com> Signed-off-by:
-
Dan Williams authored
(cherry picked from commit babdde26) array_index_nospec() uses a mask to sanitize user controllable array indexes, i.e. generate a 0 mask if 'index' >= 'size', and a ~0 mask otherwise. While the default array_index_mask_nospec() handles the carry-bit from the (index - size) result in software. The x86 array_index_mask_nospec() does the same, but the carry-bit is handled in the processor CF flag without conditional instructions in the control flow. Suggested-by:
-
Dan Williams authored
(cherry picked from commit f3804203) array_index_nospec() is proposed as a generic mechanism to mitigate against Spectre-variant-1 attacks, i.e. an attack that bypasses boundary checks via speculative execution. The array_index_nospec() implementation is expected to be safe for current generation CPUs across multiple architectures (ARM, x86). Based on an original implementation by Linus Torvalds, tweaked to remove speculative flows by Alexei Starovoitov, and tweaked again by Linus to introduce an x86 assembly implementation for the mask generation. Co-developed-by:
Alexei Starovoitov <ast@kernel.org> Suggested-by:
Cyril Novikov <cnovikov@lynx.com> Signed-off-by:
-
Mark Rutland authored
(cherry picked from commit f84a56f7) Document the rationale and usage of the new array_index_nospec() helper. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: linux-arch@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: gregkh@linuxfoundation.org Cc: kernel-hardening@lists.openwall.com Cc: torvalds@linux-foundation.org Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727413645.33451.15878817161436755393.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by:
-
Dou Liyang authored
(cherry picked from commit 9471eee9) The spectre_v2 option 'auto' does not check whether CONFIG_RETPOLINE is enabled. As a consequence it fails to emit the appropriate warning and sets feature flags which have no effect at all. Add the missing IS_ENABLED() check. Fixes: da285121 ("x86/spectre: Add boot time option to select Spectre v2 mitigation") Signed-off-by:
Dou Liyang <douly.fnst@cn.fujitsu.com> Signed-off-by:
-
Thomas Gleixner authored
(cherry picked from commit e383095c) If sysfs is disabled and RETPOLINE not defined: arch/x86/kernel/cpu/bugs.c:97:13: warning: ‘spectre_v2_bad_module’ defined but not used [-Wunused-variable] static bool spectre_v2_bad_module; Hide it. Fixes: caf7501a ("module/retpoline: Warn about missing retpoline in module") Reported-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
-
Borislav Petkov authored
(cherry picked from commit 55fa19d3) Make [ 0.031118] Spectre V2 mitigation: Mitigation: Full generic retpoline into [ 0.031118] Spectre V2: Mitigation: Full generic retpoline to reduce the mitigation mitigations strings. Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Borislav Petkov authored
(cherry picked from commit 7a32fc51) ... to adhere to the _ASM_X86_ naming scheme. No functional change. Signed-off-by:
-
Andi Kleen authored
(cherry picked from commit caf7501a) There's a risk that a kernel which has full retpoline mitigations becomes vulnerable when a module gets loaded that hasn't been compiled with the right compiler or the right option. To enable detection of that mismatch at module load time, add a module info string "retpoline" at build time when the module was compiled with retpoline support. This only covers compiled C source, but assembler source or prebuilt object files are not checked. If a retpoline enabled kernel detects a non retpoline protected module at load time, print a warning and report it in the sysfs vulnerability file. [ tglx: Massaged changelog ] Signed-off-by:
-
Peter Zijlstra authored
(cherry picked from commit c940a3fb) Replace indirect call with CALL_NOSPEC. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
-
Peter Zijlstra authored
(cherry picked from commit 1a29b5b7) Replace the indirect calls with CALL_NOSPEC. Signed-off-by:
-
Waiman Long authored
commit 1df37383 upstream. It doesn't make sense to have an indirect call thunk with esp/rsp as retpoline code won't work correctly with the stack pointer register. Removing it will help compiler writers to catch error in case such a thunk call is emitted incorrectly. Fixes: 76b04384 ("x86/retpoline: Add initial retpoline support") Suggested-by:
Jeff Law <law@redhat.com> Signed-off-by:
Waiman Long <longman@redhat.com> Signed-off-by:
-
Wanpeng Li authored
commit 9a6e7c39 upstream. qemu-system-x86-8600 [004] d..1 7205.687530: kvm_entry: vcpu 2 qemu-system-x86-8600 [004] .... 7205.687532: kvm_exit: reason EXCEPTION_NMI rip 0xffffffffa921297d info ffffeb2c0e44e018 80000b0e qemu-system-x86-8600 [004] .... 7205.687532: kvm_page_fault: address ffffeb2c0e44e018 error_code 0 qemu-system-x86-8600 [004] .... 7205.687620: kvm_try_async_get_page: gva = 0xffffeb2c0e44e018, gfn = 0x427e4e qemu-system-x86-8600 [004] .N.. 7205.687628: kvm_async_pf_not_present: token 0x8b002 gva 0xffffeb2c0e44e018 kworker/4:2-7814 [004] .... 7205.687655: kvm_async_pf_completed: gva 0xffffeb2c0e44e018 address 0x7fcc30c4e000 qemu-system-x86-8600 [004] .... 7205.687703: kvm_async_pf_ready: token 0x8b002 gva 0xffffeb2c0e44e018 qemu-system-x86-8600 [004] d..1 7205.687711: kvm_entry: vcpu 2 After running some memory intensive workload in guest, I catch the kworker which completes the GUP too quickly, and queues an "Page Ready" #PF exception after the "Page not Present" exception before the next vmentry as the above trace which will result in #DF injected to guest. This patch fixes it by clearing the queue for "Page not Present" if "Page Ready" occurs before the next vmentry since the GUP has already got the required page and shadow page table has already been fixed by "Page Ready" handler. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
Wanpeng Li <wanpeng.li@hotmail.com> Fixes: 7c90705b ("KVM: Inject asynchronous page fault into a PV guest if page is swapped out.") [Changed indentation and added clearing of injected. - Radim] Signed-off-by:
-
