mirror_ubuntu-bionic-kernel.git
2 weeks agoUBUNTU: Ubuntu-4.15.0-50.54 master Ubuntu-4.15.0-50.54
Stefan Bader [Mon, 6 May 2019 16:59:24 +0000 (18:59 +0200)]
UBUNTU: Ubuntu-4.15.0-50.54

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation/mds: Add 'mitigations=' support for MDS
Josh Poimboeuf [Wed, 17 Apr 2019 21:39:02 +0000 (16:39 -0500)]
x86/speculation/mds: Add 'mitigations=' support for MDS

Add MDS to the new 'mitigations=' cmdline option.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit 5c14068f87d04adc73ba3f41c2a303d3c3d1fa12)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agos390/speculation: Support 'mitigations=' cmdline option
Josh Poimboeuf [Fri, 12 Apr 2019 20:39:31 +0000 (15:39 -0500)]
s390/speculation: Support 'mitigations=' cmdline option

Configure s390 runtime CPU speculation bug mitigations in accordance
with the 'mitigations=' cmdline option.  This affects Spectre v1 and
Spectre v2.

The default behavior is unchanged.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Jiri Kosina <jkosina@suse.cz> (on x86)
Reviewed-by: Jiri Kosina <jkosina@suse.cz>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux-s390@vger.kernel.org
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-arch@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tyler Hicks <tyhicks@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Steven Price <steven.price@arm.com>
Cc: Phil Auld <pauld@redhat.com>
Link: https://lkml.kernel.org/r/e4a161805458a5ec88812aac0307ae3908a030fc.1555085500.git.jpoimboe@redhat.com
CVE-2017-5715
CVE-2017-5753

(cherry picked from commit 0336e04a6520bdaefdb0769d2a70084fa52e81ed https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agopowerpc/speculation: Support 'mitigations=' cmdline option
Josh Poimboeuf [Fri, 12 Apr 2019 20:39:30 +0000 (15:39 -0500)]
powerpc/speculation: Support 'mitigations=' cmdline option

Configure powerpc CPU runtime speculation bug mitigations in accordance
with the 'mitigations=' cmdline option.  This affects Meltdown, Spectre
v1, Spectre v2, and Speculative Store Bypass.

The default behavior is unchanged.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Jiri Kosina <jkosina@suse.cz> (on x86)
Reviewed-by: Jiri Kosina <jkosina@suse.cz>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux-s390@vger.kernel.org
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-arch@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tyler Hicks <tyhicks@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Steven Price <steven.price@arm.com>
Cc: Phil Auld <pauld@redhat.com>
Link: https://lkml.kernel.org/r/245a606e1a42a558a310220312d9b6adb9159df6.1555085500.git.jpoimboe@redhat.com
CVE-2017-5715
CVE-2017-5753
CVE-2017-5754
CVE-2018-3639

(backported from commit 782e69efb3dfed6e8360bc612e8c7827a901a8f9 https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git)
[tyhicks: Backport to 4.15:
 - include <linux/cpu.h> from security.c]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation: Support 'mitigations=' cmdline option
Josh Poimboeuf [Fri, 12 Apr 2019 20:39:29 +0000 (15:39 -0500)]
x86/speculation: Support 'mitigations=' cmdline option

Configure x86 runtime CPU speculation bug mitigations in accordance with
the 'mitigations=' cmdline option.  This affects Meltdown, Spectre v2,
Speculative Store Bypass, and L1TF.

The default behavior is unchanged.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Jiri Kosina <jkosina@suse.cz> (on x86)
Reviewed-by: Jiri Kosina <jkosina@suse.cz>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux-s390@vger.kernel.org
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-arch@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tyler Hicks <tyhicks@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Steven Price <steven.price@arm.com>
Cc: Phil Auld <pauld@redhat.com>
Link: https://lkml.kernel.org/r/6616d0ae169308516cfdf5216bedd169f8a8291b.1555085500.git.jpoimboe@redhat.com
CVE-2017-5715
CVE-2017-5754
CVE-2018-3639
CVE-2018-3620
CVE-2018-3646

(cherry picked from commit d68be4c4d31295ff6ae34a8ddfaa4c1a8ff42812 https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agocpu/speculation: Add 'mitigations=' cmdline option
Josh Poimboeuf [Fri, 12 Apr 2019 20:39:28 +0000 (15:39 -0500)]
cpu/speculation: Add 'mitigations=' cmdline option

Keeping track of the number of mitigations for all the CPU speculation
bugs has become overwhelming for many users.  It's getting more and more
complicated to decide which mitigations are needed for a given
architecture.  Complicating matters is the fact that each arch tends to
have its own custom way to mitigate the same vulnerability.

Most users fall into a few basic categories:

a) they want all mitigations off;

b) they want all reasonable mitigations on, with SMT enabled even if
   it's vulnerable; or

c) they want all reasonable mitigations on, with SMT disabled if
   vulnerable.

Define a set of curated, arch-independent options, each of which is an
aggregation of existing options:

- mitigations=off: Disable all mitigations.

- mitigations=auto: [default] Enable all the default mitigations, but
  leave SMT enabled, even if it's vulnerable.

- mitigations=auto,nosmt: Enable all the default mitigations, disabling
  SMT if needed by a mitigation.

Currently, these options are placeholders which don't actually do
anything.  They will be fleshed out in upcoming patches.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Jiri Kosina <jkosina@suse.cz> (on x86)
Reviewed-by: Jiri Kosina <jkosina@suse.cz>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Jon Masters <jcm@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux-s390@vger.kernel.org
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-arch@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tyler Hicks <tyhicks@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Steven Price <steven.price@arm.com>
Cc: Phil Auld <pauld@redhat.com>
Link: https://lkml.kernel.org/r/b07a8ef9b7c5055c3a4637c87d07c296d5016fe0.1555085500.git.jpoimboe@redhat.com
CVE-2017-5715
CVE-2017-5754
CVE-2018-3639
CVE-2018-3620
CVE-2018-3646

(backported from commit 98af8452945c55652de68536afdde3b520fec429 https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git)
[tyhicks: Backport to 4.15:
 - Minor context differences since boot_cpu_state_init() uses per_cpu_ptr()
   instead of this_cpu_write()]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation/mds: Print SMT vulnerable on MSBDS with mitigations off
Konrad Rzeszutek Wilk [Fri, 12 Apr 2019 21:50:58 +0000 (17:50 -0400)]
x86/speculation/mds: Print SMT vulnerable on MSBDS with mitigations off

This code is only for CPUs which are affected by MSBDS, but are *not*
affected by the other two MDS issues.

For such CPUs, enabling the mds_idle_clear mitigation is enough to
mitigate SMT.

However if user boots with 'mds=off' and still has SMT enabled, we should
not report that SMT is mitigated:

$cat /sys//devices/system/cpu/vulnerabilities/mds
Vulnerable; SMT mitigated

But rather:
Vulnerable; SMT vulnerable

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20190412215118.294906495@localhost.localdomain
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit e2c3c94788b08891dcf3dbe608f9880523ecd71b)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation/mds: Fix comment
Boris Ostrovsky [Fri, 12 Apr 2019 21:50:57 +0000 (17:50 -0400)]
x86/speculation/mds: Fix comment

s/L1TF/MDS/

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit cae5ec342645746d617dd420d206e1588d47768a)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation/mds: Add SMT warning message
Josh Poimboeuf [Tue, 2 Apr 2019 15:00:51 +0000 (10:00 -0500)]
x86/speculation/mds: Add SMT warning message

MDS is vulnerable with SMT.  Make that clear with a one-time printk
whenever SMT first gets enabled.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Jiri Kosina <jkosina@suse.cz>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit 39226ef02bfb43248b7db12a4fdccb39d95318e3)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation: Move arch_smt_update() call to after mitigation decisions
Josh Poimboeuf [Tue, 2 Apr 2019 15:00:14 +0000 (10:00 -0500)]
x86/speculation: Move arch_smt_update() call to after mitigation decisions

arch_smt_update() now has a dependency on both Spectre v2 and MDS
mitigations.  Move its initial call to after all the mitigation decisions
have been made.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Jiri Kosina <jkosina@suse.cz>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit 7c3658b20194a5b3209a143f63bc9c643c6a3ae2)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation/mds: Add mds=full,nosmt cmdline option
Josh Poimboeuf [Tue, 2 Apr 2019 14:59:33 +0000 (09:59 -0500)]
x86/speculation/mds: Add mds=full,nosmt cmdline option

Add the mds=full,nosmt cmdline option.  This is like mds=full, but with
SMT disabled if the CPU is vulnerable.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Jiri Kosina <jkosina@suse.cz>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit d71eb0ce109a124b0fa714832823b9452f2762cf)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agoDocumentation: Add MDS vulnerability documentation
Thomas Gleixner [Mon, 18 Feb 2019 23:02:31 +0000 (00:02 +0100)]
Documentation: Add MDS vulnerability documentation

Add the initial MDS vulnerability documentation.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit 62d4d464fd5f465de4afc55e267d994f6e103d37)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agoDocumentation: Move L1TF to separate directory
Thomas Gleixner [Tue, 19 Feb 2019 10:10:49 +0000 (11:10 +0100)]
Documentation: Move L1TF to separate directory

Move L!TF to a separate directory so the MDS stuff can be added at the
side. Otherwise the all hardware vulnerabilites have their own top level
entry. Should have done that right away.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit a4117ea9cd8a01aa62d791fa3026ee7befe73614)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation/mds: Add mitigation mode VMWERV
Thomas Gleixner [Wed, 20 Feb 2019 08:40:40 +0000 (09:40 +0100)]
x86/speculation/mds: Add mitigation mode VMWERV

In virtualized environments it can happen that the host has the microcode
update which utilizes the VERW instruction to clear CPU buffers, but the
hypervisor is not yet updated to expose the X86_FEATURE_MD_CLEAR CPUID bit
to guests.

Introduce an internal mitigation mode VWWERV which enables the invocation
of the CPU buffer clearing even if X86_FEATURE_MD_CLEAR is not set. If the
system has no updated microcode this results in a pointless execution of
the VERW instruction wasting a few CPU cycles. If the microcode is updated,
but not exposed to a guest then the CPU buffers will be cleared.

That said: Virtual Machines Will Eventually Receive Vaccine

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit 8a2979fc4e819a1bb77c782def72e45d9f5a3f0d)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation/mds: Add sysfs reporting for MDS
Thomas Gleixner [Mon, 18 Feb 2019 21:51:43 +0000 (22:51 +0100)]
x86/speculation/mds: Add sysfs reporting for MDS

Add the sysfs reporting file for MDS. It exposes the vulnerability and
mitigation state similar to the existing files for the other speculative
hardware vulnerabilities.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Borislav Petkov <bp@suse.de>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(backported from commit bd8651092f9656672e53feb1f8e793a0b960138d)
[tyhicks: Backport to 4.15:
 - Include asm/hypervisor.h from bugs.c for hypervisor_is_type()]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation/mds: Add mitigation control for MDS
Thomas Gleixner [Mon, 18 Feb 2019 21:04:08 +0000 (22:04 +0100)]
x86/speculation/mds: Add mitigation control for MDS

Now that the mitigations are in place, add a command line parameter to
control the mitigation, a mitigation selector function and a SMT update
mechanism.

This is the minimal straight forward initial implementation which just
provides an always on/off mode. The command line parameter is:

  mds=[full|off]

This is consistent with the existing mitigations for other speculative
hardware vulnerabilities.

The idle invocation is dynamically updated according to the SMT state of
the system similar to the dynamic update of the STIBP mitigation. The idle
mitigation is limited to CPUs which are only affected by MSBDS and not any
other variant, because the other variants cannot be mitigated on SMT
enabled systems.

CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit c5ee1ae05768716933d4e5d2015b59bdf6df04c5)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation/mds: Conditionally clear CPU buffers on idle entry
Thomas Gleixner [Mon, 18 Feb 2019 22:04:01 +0000 (23:04 +0100)]
x86/speculation/mds: Conditionally clear CPU buffers on idle entry

Add a static key which controls the invocation of the CPU buffer clear
mechanism on idle entry. This is independent of other MDS mitigations
because the idle entry invocation to mitigate the potential leakage due to
store buffer repartitioning is only necessary on SMT systems.

Add the actual invocations to the different halt/mwait variants which
covers all usage sites. mwaitx is not patched as it's not available on
Intel CPUs.

The buffer clear is only invoked before entering the C-State to prevent
that stale data from the idling CPU is spilled to the Hyper-Thread sibling
after the Store buffer got repartitioned and all entries are available to
the non idle sibling.

When coming out of idle the store buffer is partitioned again so each
sibling has half of it available. Now CPU which returned from idle could be
speculatively exposed to contents of the sibling, but the buffers are
flushed either on exit to user space or on VMENTER.

When later on conditional buffer clearing is implemented on top of this,
then there is no action required either because before returning to user
space the context switch will set the condition flag which causes a flush
on the return to user path.

Note, that the buffer clearing on idle is only sensible on CPUs which are
solely affected by MSBDS and not any other variant of MDS because the other
MDS variants cannot be mitigated when SMT is enabled, so the buffer
clearing on idle would be a window dressing exercise.

This intentionally does not handle the case in the acpi/processor_idle
driver which uses the legacy IO port interface for C-State transitions for
two reasons:

 - The acpi/processor_idle driver was replaced by the intel_idle driver
   almost a decade ago. Anything Nehalem upwards supports it and defaults
   to that new driver.

 - The legacy IO port interface is likely to be used on older and therefore
   unaffected CPUs or on systems which do not receive microcode updates
   anymore, so there is no point in adding that.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit 131ddbba14bc156defba98235818f3fb0cd9537e)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/kvm/vmx: Add MDS protection when L1D Flush is not active
Thomas Gleixner [Wed, 27 Feb 2019 11:48:14 +0000 (12:48 +0100)]
x86/kvm/vmx: Add MDS protection when L1D Flush is not active

CPUs which are affected by L1TF and MDS mitigate MDS with the L1D Flush on
VMENTER when updated microcode is installed.

If a CPU is not affected by L1TF or if the L1D Flush is not in use, then
MDS mitigation needs to be invoked explicit.

For these cases, follow the host mitigation state and invoke the MDS
mitigation before VMENTER.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(backported from commit e3f1fbbd5ffb7ca71bf13d447983c03cf4e27030)
[tyhicks: Backport to 4.18:
 - Adjust path of vmx.c which was changed in upstream commit a821bab2d1ee]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation/mds: Clear CPU buffers on exit to user
Thomas Gleixner [Mon, 18 Feb 2019 22:42:51 +0000 (23:42 +0100)]
x86/speculation/mds: Clear CPU buffers on exit to user

Add a static key which controls the invocation of the CPU buffer clear
mechanism on exit to user space and add the call into
prepare_exit_to_usermode() and do_nmi() right before actually returning.

Add documentation which kernel to user space transition this covers and
explain why some corner cases are not mitigated.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit b5ce1d36407a2324d2ab63c30ca1f71f24e9861e)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation/mds: Add mds_clear_cpu_buffers()
Thomas Gleixner [Mon, 18 Feb 2019 22:13:06 +0000 (23:13 +0100)]
x86/speculation/mds: Add mds_clear_cpu_buffers()

The Microarchitectural Data Sampling (MDS) vulernabilities are mitigated by
clearing the affected CPU buffers. The mechanism for clearing the buffers
uses the unused and obsolete VERW instruction in combination with a
microcode update which triggers a CPU buffer clear when VERW is executed.

Provide a inline function with the assembly magic. The argument of the VERW
instruction must be a memory operand as documented:

  "MD_CLEAR enumerates that the memory-operand variant of VERW (for
   example, VERW m16) has been extended to also overwrite buffers affected
   by MDS. This buffer overwriting functionality is not guaranteed for the
   register operand variant of VERW."

Documentation also recommends to use a writable data segment selector:

  "The buffer overwriting occurs regardless of the result of the VERW
   permission check, as well as when the selector is null or causes a
   descriptor load segment violation. However, for lowest latency we
   recommend using a selector that indicates a valid writable data
   segment."

Add x86 specific documentation about MDS and the internal workings of the
mitigation.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit 96ea82f6839ef16812729b3820feb25f293abf63)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/kvm: Expose X86_FEATURE_MD_CLEAR to guests
Andi Kleen [Sat, 19 Jan 2019 00:50:23 +0000 (16:50 -0800)]
x86/kvm: Expose X86_FEATURE_MD_CLEAR to guests

X86_FEATURE_MD_CLEAR is a new CPUID bit which is set when microcode
provides the mechanism to invoke a flush of various exploitable CPU buffers
by invoking the VERW instruction.

Hand it through to guests so they can adjust their mitigations.

This also requires corresponding qemu changes, which are available
separately.

[ tglx: Massaged changelog ]

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit 1789c4f11b6cefc067e405233084a6b9f072f579)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation/mds: Add BUG_MSBDS_ONLY
Thomas Gleixner [Fri, 1 Mar 2019 19:21:08 +0000 (20:21 +0100)]
x86/speculation/mds: Add BUG_MSBDS_ONLY

This bug bit is set on CPUs which are only affected by Microarchitectural
Store Buffer Data Sampling (MSBDS) and not by any other MDS variant.

This is important because the Store Buffers are partitioned between
Hyper-Threads so cross thread forwarding is not possible. But if a thread
enters or exits a sleep state the store buffer is repartitioned which can
expose data from one thread to the other. This transition can be mitigated.

That means that for CPUs which are only affected by MSBDS SMT can be
enabled, if the CPU is not affected by other SMT sensitive vulnerabilities,
e.g. L1TF. The XEON PHI variants fall into that category.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit ab12e2e20232e9b84e2b212346b9fe3956e91642)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation/mds: Add basic bug infrastructure for MDS
Andi Kleen [Sat, 19 Jan 2019 00:50:16 +0000 (16:50 -0800)]
x86/speculation/mds: Add basic bug infrastructure for MDS

Microarchitectural Data Sampling (MDS), is a class of side channel attacks
on internal buffers in Intel CPUs. The variants are:

 - Microarchitectural Store Buffer Data Sampling (MSBDS) (CVE-2018-12126)
 - Microarchitectural Fill Buffer Data Sampling (MFBDS) (CVE-2018-12130)
 - Microarchitectural Load Port Data Sampling (MLPDS) (CVE-2018-12127)

MSBDS leaks Store Buffer Entries which can be speculatively forwarded to a
dependent load (store-to-load forwarding) as an optimization. The forward
can also happen to a faulting or assisting load operation for a different
memory address, which can be exploited under certain conditions. Store
buffers are partitioned between Hyper-Threads so cross thread forwarding is
not possible. But if a thread enters or exits a sleep state the store
buffer is repartitioned which can expose data from one thread to the other.

MFBDS leaks Fill Buffer Entries. Fill buffers are used internally to manage
L1 miss situations and to hold data which is returned or sent in response
to a memory or I/O operation. Fill buffers can forward data to a load
operation and also write data to the cache. When the fill buffer is
deallocated it can retain the stale data of the preceding operations which
can then be forwarded to a faulting or assisting load operation, which can
be exploited under certain conditions. Fill buffers are shared between
Hyper-Threads so cross thread leakage is possible.

MLDPS leaks Load Port Data. Load ports are used to perform load operations
from memory or I/O. The received data is then forwarded to the register
file or a subsequent operation. In some implementations the Load Port can
contain stale data from a previous operation which can be forwarded to
faulting or assisting loads under certain conditions, which again can be
exploited eventually. Load ports are shared between Hyper-Threads so cross
thread leakage is possible.

All variants have the same mitigation for single CPU thread case (SMT off),
so the kernel can treat them as one MDS issue.

Add the basic infrastructure to detect if the current CPU is affected by
MDS.

[ tglx: Rewrote changelog ]

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(backported from commit 5edd28bac163689d3ab84c7545d9d0212504be86)
[tyhicks: Backport to 4.18:
 - X86_VENDOR_HYGON does not exist because commit c9661c1e80b6 is
   missing]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/speculation: Consolidate CPU whitelists
Thomas Gleixner [Wed, 27 Feb 2019 09:10:23 +0000 (10:10 +0100)]
x86/speculation: Consolidate CPU whitelists

The CPU vulnerability whitelists have some overlap and there are more
whitelists coming along.

Use the driver_data field in the x86_cpu_id struct to denote the
whitelisted vulnerabilities and combine all whitelists into one.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(backported from commit c01bba64427c723870372e97a82ae843ca14e876)
[tyhicks: Backport to 4.18:
 - X86_VENDOR_HYGON does not exist because commit c9661c1e80b6 is
   missing]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/msr-index: Cleanup bit defines
Thomas Gleixner [Thu, 21 Feb 2019 11:36:50 +0000 (12:36 +0100)]
x86/msr-index: Cleanup bit defines

Greg pointed out that speculation related bit defines are using (1 << N)
format instead of BIT(N). Aside of that (1 << N) is wrong as it should use
1UL at least.

Clean it up.

[ Josh Poimboeuf: Fix tools build ]

Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Borislav Petkov <bp@suse.de>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(backported from commit a4a931802e51223b3e0548fc31fb3f7dc8f6d032)
[tyhicks: Backport to 4.15:
 - The Makefiles do not contain override directives on the modified
   lines]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agotools include: Adopt linux/bits.h
Arnaldo Carvalho de Melo [Tue, 25 Sep 2018 13:55:59 +0000 (10:55 -0300)]
tools include: Adopt linux/bits.h

So that we reduce the difference of tools/include/linux/bitops.h to the
original kernel file, include/linux/bitops.h, trying to remove the need
to define BITS_PER_LONG, to avoid clashes with asm/bitsperlong.h.

And the things removed from tools/include/linux/bitops.h are really in
linux/bits.h, so that we can have a copy and then
tools/perf/check_headers.sh will tell us when new stuff gets added to
linux/bits.h so that we can check if it is useful and if any adjustment
needs to be done to the tools/{include,arch}/ copies.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: https://lkml.kernel.org/n/tip-y1sqyydvfzo0bjjoj4zsl562@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit ba4aa02b417f08a0bee5e7b8ed70cac788a7c854)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agolocking/atomics, asm-generic: Move some macros from <linux/bitops.h> to a new <linux...
Will Deacon [Tue, 19 Jun 2018 12:53:08 +0000 (13:53 +0100)]
locking/atomics, asm-generic: Move some macros from <linux/bitops.h> to a new <linux/bits.h> file

In preparation for implementing the asm-generic atomic bitops in terms
of atomic_long_*(), we need to prevent <asm/atomic.h> implementations from
pulling in <linux/bitops.h>. A common reason for this include is for the
BITS_PER_BYTE definition, so move this and some other BIT() and masking
macros into a new header file, <linux/bits.h>.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: yamada.masahiro@socionext.com
Link: https://lore.kernel.org/lkml/1529412794-17720-4-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit 8bd9cb51daac89337295b6f037b0486911e1b408)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agokvm: x86: Report STIBP on GET_SUPPORTED_CPUID
Eduardo Habkost [Wed, 5 Dec 2018 19:19:56 +0000 (17:19 -0200)]
kvm: x86: Report STIBP on GET_SUPPORTED_CPUID

Months ago, we have added code to allow direct access to MSR_IA32_SPEC_CTRL
to the guest, which makes STIBP available to guests.  This was implemented
by commits d28b387fb74d ("KVM/VMX: Allow direct access to
MSR_IA32_SPEC_CTRL") and b2ac58f90540 ("KVM/SVM: Allow direct access to
MSR_IA32_SPEC_CTRL").

However, we never updated GET_SUPPORTED_CPUID to let userspace know that
STIBP can be enabled in CPUID.  Fix that by updating
kvm_cpuid_8000_0008_ebx_x86_features and kvm_cpuid_7_0_edx_x86_features.

Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit d7b09c827a6cf291f66637a36f46928dd1423184)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agox86/cpu: Sanitize FAM6_ATOM naming
Peter Zijlstra [Tue, 7 Aug 2018 17:17:27 +0000 (10:17 -0700)]
x86/cpu: Sanitize FAM6_ATOM naming

Going primarily by:

  https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors

with additional information gleaned from other related pages; notably:

 - Bonnell shrink was called Saltwell
 - Moorefield is the Merriefield refresh which makes it Airmont

The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE

  for i in `git grep -l FAM6_ATOM` ; do
sed -i  -e 's/ATOM_PINEVIEW/ATOM_BONNELL/g' \
-e 's/ATOM_LINCROFT/ATOM_BONNELL_MID/' \
-e 's/ATOM_PENWELL/ATOM_SALTWELL_MID/g' \
-e 's/ATOM_CLOVERVIEW/ATOM_SALTWELL_TABLET/g' \
-e 's/ATOM_CEDARVIEW/ATOM_SALTWELL/g' \
-e 's/ATOM_SILVERMONT1/ATOM_SILVERMONT/g' \
-e 's/ATOM_SILVERMONT2/ATOM_SILVERMONT_X/g' \
-e 's/ATOM_MERRIFIELD/ATOM_SILVERMONT_MID/g' \
-e 's/ATOM_MOOREFIELD/ATOM_AIRMONT_MID/g' \
-e 's/ATOM_DENVERTON/ATOM_GOLDMONT_X/g' \
-e 's/ATOM_GEMINI_LAKE/ATOM_GOLDMONT_PLUS/g' ${i}
  done

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: dave.hansen@linux.intel.com
Cc: len.brown@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(backported from commit f2c4db1bd80720cd8cb2a5aa220d9bc9f374f04e)
[tyhicks: Backport to 4.15:
 - arch/x86/kernel/cpu/intel_rdt_pseudo_lock.c doesn't yet exist
 - arch/x86/kernel/tsc_msr.c doesn't use any FAM6_ATOM macros because it
   is missing commit 397d3ad18dc4
 - sound/soc/intel/boards/bytcr_rt5651.c doesn't use any FAM6_ATOM
   macros because it is missing commit fbea16dbc0a3
 - The FAM6_ATOM items in the intel_pstate_cpu_ids[] array use bxt_funcs
   due to missing commit dbd49b85eec7
 - Context change in process_cpuid() because SKYLAKE_X and ATOM_DENVERTON
   share a case block due to missing commit 733ef0f8e76e
 - Manually ran the for loop documented in the commit message to ensure
   that there were no additional uses of the old macros]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agoDocumentation/l1tf: Fix small spelling typo
Salvatore Bonaccorso [Wed, 15 Aug 2018 05:46:04 +0000 (07:46 +0200)]
Documentation/l1tf: Fix small spelling typo

Fix small typo (wiil -> will) in the "3.4. Nested virtual machines"
section.

Fixes: 5b76a3cff011 ("KVM: VMX: Tell the nested hypervisor to skip L1D flush on vmentry")
Cc: linux-kernel@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-doc@vger.kernel.org
Cc: trivial@kernel.org
Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
CVE-2018-12126
CVE-2018-12127
CVE-2018-12130

(cherry picked from commit 60ca05c3b44566b70d64fbb8e87a6e0c67725468)
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agoUBUNTU: Start new release
Stefan Bader [Mon, 6 May 2019 16:57:58 +0000 (18:57 +0200)]
UBUNTU: Start new release

Ignore: yes
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
2 weeks agoUBUNTU: [Packaging] resync git-ubuntu-log
Stefan Bader [Mon, 6 May 2019 16:57:45 +0000 (18:57 +0200)]
UBUNTU: [Packaging] resync git-ubuntu-log

BugLink: http://bugs.launchpad.net/bugs/1786013
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
3 weeks agoUBUNTU: Ubuntu-4.15.0-49.53 Ubuntu-4.15.0-49.53
Stefan Bader [Fri, 26 Apr 2019 06:28:41 +0000 (08:28 +0200)]
UBUNTU: Ubuntu-4.15.0-49.53

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
3 weeks agoUBUNTU: [Packaging] arm64: Drop snapdragon from kernel-versions
Stefan Bader [Fri, 26 Apr 2019 06:23:42 +0000 (08:23 +0200)]
UBUNTU: [Packaging] arm64: Drop snapdragon from kernel-versions

BugLink: https://bugs.launchpad.net/bugs/1820868
When dropping the snapdragon flavour from building, one also
must drop it from kernel-versions which controls the udeb
generation.

Fixes: 128e2a3e33d0 "UBUNTU: packaging: arm64: disable building
       the snapdragon flavour"
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
3 weeks agoUBUNTU: Ubuntu-4.15.0-49.52
Stefan Bader [Thu, 25 Apr 2019 08:40:22 +0000 (10:40 +0200)]
UBUNTU: Ubuntu-4.15.0-49.52

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
3 weeks agoUBUNTU: [Packaging] final-checks: Depend on makefile flavours
Stefan Bader [Thu, 25 Apr 2019 08:37:02 +0000 (10:37 +0200)]
UBUNTU: [Packaging] final-checks: Depend on makefile flavours

The available ABI files do not depend on the config flavours but
those actually built. So instead of looking at the config files,
parse the flavours variable of the <arch>.mk files.

This handles a special case which was found for the current
xenial/hwe tree. This is now based on bionic which builds a
snapdragon flavour for arm64. However that flavour is not done
in xenial because it is a separate tree there.

While the flavour gets removed from the .mk file, we rather would
like to preserve the snapdragon.flavour.config file because removing
it will cause re-arrangement of config options which would happen
everytime we update from the bionic master.

However the current final-checks would then fail because of course
there is no build and therefor no ABI files for that flavour.

Ignore: yes
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
3 weeks agoUBUNTU: [Config] Add CONFIG_PPC_BARRIER_NOSPEC
Stefan Bader [Thu, 25 Apr 2019 08:24:09 +0000 (10:24 +0200)]
UBUNTU: [Config] Add CONFIG_PPC_BARRIER_NOSPEC

BugLink: https://bugs.launchpad.net/bugs/1822870
This was introduced by: "powerpc/64: Add CONFIG_PPC_BARRIER_NOSPEC"
without updating the config definitions.

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
3 weeks agoUBUNTU: link-to-tracker: update tracking bug
Stefan Bader [Thu, 25 Apr 2019 08:20:56 +0000 (10:20 +0200)]
UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1826358
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
3 weeks agoUBUNTU: Start new release
Stefan Bader [Thu, 25 Apr 2019 08:19:02 +0000 (10:19 +0200)]
UBUNTU: Start new release

Ignore: yes
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
3 weeks agoUBUNTU: [Packaging] resync git-ubuntu-log
Stefan Bader [Thu, 25 Apr 2019 08:18:42 +0000 (10:18 +0200)]
UBUNTU: [Packaging] resync git-ubuntu-log

BugLink: http://bugs.launchpad.net/bugs/1786013
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
3 weeks agoUBUNTU: [Debian] Only run regression-suite, if requested to.
Dimitri John Ledkov [Thu, 7 Mar 2019 15:32:00 +0000 (16:32 +0100)]
UBUNTU: [Debian] Only run regression-suite, if requested to.

BugLink: https://bugs.launchpad.net/bugs/1823056
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
3 weeks agoUBUNTU: [Debian] make rebuild use skippable error codes when skipping.
Dimitri John Ledkov [Thu, 7 Mar 2019 15:32:00 +0000 (16:32 +0100)]
UBUNTU: [Debian] make rebuild use skippable error codes when skipping.

BugLink: https://bugs.launchpad.net/bugs/1823056
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
3 weeks agoUBUNTU: [Debian] Make ubuntu-regression-suite skippable on unbootable kernels.
Dimitri John Ledkov [Thu, 7 Mar 2019 15:32:00 +0000 (16:32 +0100)]
UBUNTU: [Debian] Make ubuntu-regression-suite skippable on unbootable kernels.

BugLink: https://bugs.launchpad.net/bugs/1823056
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
3 weeks agoUBUNTU: [Debian] Skip rebuild test, for regression-suite deps.
Dimitri John Ledkov [Thu, 7 Mar 2019 15:32:00 +0000 (16:32 +0100)]
UBUNTU: [Debian] Skip rebuild test, for regression-suite deps.

BugLink: https://bugs.launchpad.net/bugs/1823056
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
3 weeks agoUBUNTU: [Debian] Set +x on rebuild testcase.
Dimitri John Ledkov [Thu, 7 Mar 2019 15:32:00 +0000 (16:32 +0100)]
UBUNTU: [Debian] Set +x on rebuild testcase.

BugLink: https://bugs.launchpad.net/bugs/1823056
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
4 weeks agoUBUNTU: packaging: arm64: disable building the snapdragon flavour
Paolo Pisati [Wed, 20 Mar 2019 08:31:00 +0000 (09:31 +0100)]
UBUNTU: packaging: arm64: disable building the snapdragon flavour

BugLink: https://bugs.launchpad.net/bugs/1820868
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoALSA: seq: oss: Fix Spectre v1 vulnerability
Gustavo A. R. Silva [Wed, 20 Mar 2019 23:42:01 +0000 (18:42 -0500)]
ALSA: seq: oss: Fix Spectre v1 vulnerability

dev is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

sound/core/seq/oss/seq_oss_synth.c:626 snd_seq_oss_synth_make_info() warn: potential spectre issue 'dp->synths' [w] (local cap)

Fix this by sanitizing dev before using it to index dp->synths.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
CVE-2017-5753

(cherry picked from commit c709f14f0616482b67f9fbcb965e1493a03ff30b)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoALSA: rawmidi: Fix potential Spectre v1 vulnerability
Gustavo A. R. Silva [Wed, 20 Mar 2019 21:15:24 +0000 (16:15 -0500)]
ALSA: rawmidi: Fix potential Spectre v1 vulnerability

info->stream is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

sound/core/rawmidi.c:604 __snd_rawmidi_info_select() warn: potential spectre issue 'rmidi->streams' [r] (local cap)

Fix this by sanitizing info->stream before using it to index
rmidi->streams.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
CVE-2017-5753

(backported from commit 2b1d9c8f87235f593826b9cf46ec10247741fff9)
[juergh: Adjusted context.]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agocfg80211: prevent speculation on cfg80211_classify8021d() return
Johannes Berg [Wed, 6 Feb 2019 11:17:14 +0000 (13:17 +0200)]
cfg80211: prevent speculation on cfg80211_classify8021d() return

It's possible that the caller of cfg80211_classify8021d() uses the
value to index an array, like mac80211 in ieee80211_downgrade_queue().
Prevent speculation on the return value.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
CVE-2017-5753

(backported from commit 1fc9b7253382ce1a83d9a3e63e88d656eb63f263)
[juergh: Adjusted context.]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agopowerpc/ptrace: Mitigate potential Spectre v1
Breno Leitao [Wed, 30 Jan 2019 12:46:00 +0000 (10:46 -0200)]
powerpc/ptrace: Mitigate potential Spectre v1

'regno' is directly controlled by user space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.

On PTRACE_SETREGS and PTRACE_GETREGS requests, user space passes the
register number that would be read or written. This register number is
called 'regno' which is part of the 'addr' syscall parameter.

This 'regno' value is checked against the maximum pt_regs structure size,
and then used to dereference it, which matches the initial part of a
Spectre v1 (and Spectre v1.1) attack. The dereferenced value, then,
is returned to userspace in the GETREGS case.

This patch sanitizes 'regno' before using it to dereference pt_reg.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Breno Leitao <leitao@debian.org>
Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
CVE-2017-5753

(backported from commit ebb0e13ead2ddc186a80b1b0235deeefc5a1a667)
[juergh: Adjusted context.]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoipmi: msghandler: Fix potential Spectre v1 vulnerabilities
Gustavo A. R. Silva [Wed, 9 Jan 2019 23:39:06 +0000 (17:39 -0600)]
ipmi: msghandler: Fix potential Spectre v1 vulnerabilities

channel and addr->channel are indirectly controlled by user-space,
hence leading to a potential exploitation of the Spectre variant 1
vulnerability.

These issues were detected with the help of Smatch:

drivers/char/ipmi/ipmi_msghandler.c:1381 ipmi_set_my_address() warn: potential spectre issue 'user->intf->addrinfo' [w] (local cap)
drivers/char/ipmi/ipmi_msghandler.c:1401 ipmi_get_my_address() warn: potential spectre issue 'user->intf->addrinfo' [r] (local cap)
drivers/char/ipmi/ipmi_msghandler.c:1421 ipmi_set_my_LUN() warn: potential spectre issue 'user->intf->addrinfo' [w] (local cap)
drivers/char/ipmi/ipmi_msghandler.c:1441 ipmi_get_my_LUN() warn: potential spectre issue 'user->intf->addrinfo' [r] (local cap)
drivers/char/ipmi/ipmi_msghandler.c:2260 check_addr() warn: potential spectre issue 'intf->addrinfo' [r] (local cap)

Fix this by sanitizing channel and addr->channel before using them to
index user->intf->addrinfo and intf->addrinfo, correspondingly.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
CVE-2017-5753

(backported from commit a7102c7461794a5bb31af24b08e9e0f50038897a)
[juergh: Adjusted context.]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoapplicom: Fix potential Spectre v1 vulnerabilities
Gustavo A. R. Silva [Wed, 9 Jan 2019 22:05:10 +0000 (16:05 -0600)]
applicom: Fix potential Spectre v1 vulnerabilities

IndexCard is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/char/applicom.c:418 ac_write() warn: potential spectre issue 'apbs' [r]
drivers/char/applicom.c:728 ac_ioctl() warn: potential spectre issue 'apbs' [r] (local cap)

Fix this by sanitizing IndexCard before using it to index apbs.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2017-5753

(cherry picked from commit d7ac3c6ef5d8ce14b6381d52eb7adafdd6c8bb3c)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agochar/mwave: fix potential Spectre v1 vulnerability
Gustavo A. R. Silva [Wed, 9 Jan 2019 19:02:36 +0000 (13:02 -0600)]
char/mwave: fix potential Spectre v1 vulnerability

ipcnum is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/char/mwave/mwavedd.c:299 mwave_ioctl() warn: potential spectre issue 'pDrvData->IPCs' [w] (local cap)

Fix this by sanitizing ipcnum before using it to index pDrvData->IPCs.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2017-5753

(cherry picked from commit 701956d4018e5d5438570e39e8bda47edd32c489)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agodrm/ioctl: Fix Spectre v1 vulnerabilities
Gustavo A. R. Silva [Thu, 20 Dec 2018 00:00:15 +0000 (18:00 -0600)]
drm/ioctl: Fix Spectre v1 vulnerabilities

nr is indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/gpu/drm/drm_ioctl.c:805 drm_ioctl() warn: potential spectre issue 'dev->driver->ioctls' [r]
drivers/gpu/drm/drm_ioctl.c:810 drm_ioctl() warn: potential spectre issue 'drm_ioctls' [r] (local cap)
drivers/gpu/drm/drm_ioctl.c:892 drm_ioctl_flags() warn: potential spectre issue 'drm_ioctls' [r] (local cap)

Fix this by sanitizing nr before using it to index dev->driver->ioctls
and drm_ioctls.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181220000015.GA18973@embeddedor
CVE-2017-5753

(cherry picked from commit 505b5240329b922f21f91d5b5d1e535c805eca6d)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoKVM: arm/arm64: vgic: Fix off-by-one bug in vgic_get_irq()
Gustavo A. R. Silva [Wed, 12 Dec 2018 20:11:23 +0000 (14:11 -0600)]
KVM: arm/arm64: vgic: Fix off-by-one bug in vgic_get_irq()

When using the nospec API, it should be taken into account that:

"...if the CPU speculates past the bounds check then
 * array_index_nospec() will clamp the index within the range of [0,
 * size)."

The above is part of the header for macro array_index_nospec() in
linux/nospec.h

Now, in this particular case, if intid evaluates to exactly VGIC_MAX_SPI
or to exaclty VGIC_MAX_PRIVATE, the array_index_nospec() macro ends up
returning VGIC_MAX_SPI - 1 or VGIC_MAX_PRIVATE - 1 respectively, instead
of VGIC_MAX_SPI or VGIC_MAX_PRIVATE, which, based on the original logic:

/* SGIs and PPIs */
if (intid <= VGIC_MAX_PRIVATE)
  return &vcpu->arch.vgic_cpu.private_irqs[intid];

  /* SPIs */
if (intid <= VGIC_MAX_SPI)
  return &kvm->arch.vgic.spis[intid - VGIC_NR_PRIVATE_IRQS];

are valid values for intid.

Fix this by calling array_index_nospec() macro with VGIC_MAX_PRIVATE + 1
and VGIC_MAX_SPI + 1 as arguments for its parameter size.

Fixes: 41b87599c743 ("KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_get_irq()")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
[dropped the SPI part which was fixed separately]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
CVE-2017-5753

(cherry picked from commit c23b2e6fc4ca346018618266bcabd335c0a8a49e)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoALSA: emu10k1: Fix potential Spectre v1 vulnerabilities
Gustavo A. R. Silva [Tue, 18 Dec 2018 17:52:16 +0000 (11:52 -0600)]
ALSA: emu10k1: Fix potential Spectre v1 vulnerabilities

ipcm->substream is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

sound/pci/emu10k1/emufx.c:1031 snd_emu10k1_ipcm_poke() warn: potential spectre issue 'emu->fx8010.pcm' [r] (local cap)
sound/pci/emu10k1/emufx.c:1075 snd_emu10k1_ipcm_peek() warn: potential spectre issue 'emu->fx8010.pcm' [r] (local cap)

Fix this by sanitizing ipcm->substream before using it to index emu->fx8010.pcm

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
CVE-2017-5753

(cherry picked from commit 5ae4f61f012a097df93de2285070ec8e34716d29)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoALSA: rme9652: Fix potential Spectre v1 vulnerability
Gustavo A. R. Silva [Tue, 18 Dec 2018 17:18:34 +0000 (11:18 -0600)]
ALSA: rme9652: Fix potential Spectre v1 vulnerability

info->channel is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

sound/pci/rme9652/hdsp.c:4100 snd_hdsp_channel_info() warn: potential spectre issue 'hdsp->channel_map' [r] (local cap)

Fix this by sanitizing info->channel before using it to index hdsp->channel_map

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

Also, notice that I refactored the code a bit in order to get rid of the
following checkpatch warning:

ERROR: do not use assignment in if condition
FILE: sound/pci/rme9652/hdsp.c:4103:
if ((mapped_channel = hdsp->channel_map[info->channel]) < 0)

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
CVE-2017-5753

(cherry picked from commit 0b84304ef5da92add8dc75a1b07879c5374cdb05)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoip6mr: Fix potential Spectre v1 vulnerability
Gustavo A. R. Silva [Tue, 11 Dec 2018 20:10:08 +0000 (14:10 -0600)]
ip6mr: Fix potential Spectre v1 vulnerability

vr.mifi is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

net/ipv6/ip6mr.c:1845 ip6mr_ioctl() warn: potential spectre issue 'mrt->vif_table' [r] (local cap)
net/ipv6/ip6mr.c:1919 ip6mr_compat_ioctl() warn: potential spectre issue 'mrt->vif_table' [r] (local cap)

Fix this by sanitizing vr.mifi before using it to index mrt->vif_table'

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
CVE-2017-5753

(backported from commit 69d2c86766da2ded2b70281f1bf242cb0d58a778)
[juergh: Adjusted context.]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoALSA: pcm: Fix potential Spectre v1 vulnerability
Gustavo A. R. Silva [Wed, 12 Dec 2018 21:36:28 +0000 (15:36 -0600)]
ALSA: pcm: Fix potential Spectre v1 vulnerability

stream is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

sound/core/pcm.c:140 snd_pcm_control_ioctl() warn: potential spectre issue 'pcm->streams' [r] (local cap)

Fix this by sanitizing stream before using it to index pcm->streams

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
CVE-2017-5753

(cherry picked from commit 94ffb030b6d31ec840bb811be455dd2e26a4f43e)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoALSA: emux: Fix potential Spectre v1 vulnerabilities
Gustavo A. R. Silva [Wed, 12 Dec 2018 17:20:49 +0000 (11:20 -0600)]
ALSA: emux: Fix potential Spectre v1 vulnerabilities

info.mode and info.port are indirectly controlled by user-space,
hence leading to a potential exploitation of the Spectre variant 1
vulnerability.

These issues were detected with the help of Smatch:

sound/synth/emux/emux_hwdep.c:72 snd_emux_hwdep_misc_mode() warn: potential spectre issue 'emu->portptrs[i]->ctrls' [w] (local cap)
sound/synth/emux/emux_hwdep.c:75 snd_emux_hwdep_misc_mode() warn: potential spectre issue 'emu->portptrs' [w] (local cap)
sound/synth/emux/emux_hwdep.c:75 snd_emux_hwdep_misc_mode() warn: potential spectre issue 'emu->portptrs[info.port]->ctrls' [w] (local cap)

Fix this by sanitizing both info.mode and info.port before using them
to index emu->portptrs[i]->ctrls, emu->portptrs[info.port]->ctrls and
emu->portptrs.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
CVE-2017-5753

(cherry picked from commit 4aea96f4237cea0c51a8bc87c0db31f0f932f1f0)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoaio: fix spectre gadget in lookup_ioctx
Jeff Moyer [Tue, 11 Dec 2018 17:37:49 +0000 (12:37 -0500)]
aio: fix spectre gadget in lookup_ioctx

Matthew pointed out that the ioctx_table is susceptible to spectre v1,
because the index can be controlled by an attacker.  The below patch
should mitigate the attack for all of the aio system calls.

Cc: stable@vger.kernel.org
Reported-by: Matthew Wilcox <willy@infradead.org>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
CVE-2017-5753

(cherry picked from commit a538e3ff9dabcdf6c3f477a373c629213d1c3066)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoipv4: Fix potential Spectre v1 vulnerability
Gustavo A. R. Silva [Mon, 10 Dec 2018 18:41:24 +0000 (12:41 -0600)]
ipv4: Fix potential Spectre v1 vulnerability

vr.vifi is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

net/ipv4/ipmr.c:1616 ipmr_ioctl() warn: potential spectre issue 'mrt->vif_table' [r] (local cap)
net/ipv4/ipmr.c:1690 ipmr_compat_ioctl() warn: potential spectre issue 'mrt->vif_table' [r] (local cap)

Fix this by sanitizing vr.vifi before using it to index mrt->vif_table'

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
CVE-2017-5753

(cherry picked from commit 5648451e30a0d13d11796574919a359025d52cce)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agodrivers/misc/sgi-gru: fix Spectre v1 vulnerability
Gustavo A. R. Silva [Tue, 16 Oct 2018 10:59:44 +0000 (12:59 +0200)]
drivers/misc/sgi-gru: fix Spectre v1 vulnerability

req.gid can be indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

vers/misc/sgi-gru/grukdump.c:200 gru_dump_chiplet_request() warn:
potential spectre issue 'gru_base' [w]

Fix this by sanitizing req.gid before calling macro GID_TO_GRU, which
uses it to index gru_base.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2017-5753

(cherry picked from commit fee05f455ceb5c670cbe48e2f9454ebc4a388554)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agovhost: Fix Spectre V1 vulnerability
Jason Wang [Tue, 30 Oct 2018 06:10:49 +0000 (14:10 +0800)]
vhost: Fix Spectre V1 vulnerability

The idx in vhost_vring_ioctl() was controlled by userspace, hence a
potential exploitation of the Spectre variant 1 vulnerability.

Fixing this by sanitizing idx before using it to index d->vqs.

Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
CVE-2017-5753

(cherry picked from commit ff002269a4ee9c769dbf9365acef633ebcbd6cbe)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoHID: hiddev: fix potential Spectre v1
Breno Leitao [Fri, 19 Oct 2018 20:01:33 +0000 (17:01 -0300)]
HID: hiddev: fix potential Spectre v1

uref->usage_index can be indirectly controlled by userspace, hence leading
to a potential exploitation of the Spectre variant 1 vulnerability.

This field is used as an array index by the hiddev_ioctl_usage() function,
when 'cmd' is either HIDIOCGCOLLECTIONINDEX, HIDIOCGUSAGES or
HIDIOCSUSAGES.

For cmd == HIDIOCGCOLLECTIONINDEX case, uref->usage_index is compared to
field->maxusage and then used as an index to dereference field->usage
array. The same thing happens to the cmd == HIDIOC{G,S}USAGES cases, where
uref->usage_index is checked against an array maximum value and then it is
used as an index in an array.

This is a summary of the HIDIOCGCOLLECTIONINDEX case, which matches the
traditional Spectre V1 first load:

copy_from_user(uref, user_arg, sizeof(*uref))
if (uref->usage_index >= field->maxusage)
goto inval;
i = field->usage[uref->usage_index].collection_index;
return i;

This patch fixes this by sanitizing field uref->usage_index before using it
to index field->usage (HIDIOCGCOLLECTIONINDEX) or field->value in
HIDIOC{G,S}USAGES arrays, thus, avoiding speculation in the first load.

Cc: <stable@vger.kernel.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
--

v2: Contemplate cmd == HIDIOC{G,S}USAGES case
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
CVE-2017-5753

(cherry picked from commit f11274396a538b31bc010f782e05c2ce3f804c13)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoptp: fix Spectre v1 vulnerability
Gustavo A. R. Silva [Tue, 16 Oct 2018 13:06:41 +0000 (15:06 +0200)]
ptp: fix Spectre v1 vulnerability

pin_index can be indirectly controlled by user-space, hence leading
to a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/ptp/ptp_chardev.c:253 ptp_ioctl() warn: potential spectre issue
'ops->pin_config' [r] (local cap)

Fix this by sanitizing pin_index before using it to index
ops->pin_config, and before passing it as an argument to
function ptp_set_pinfunc(), in which it is used to index
info->pin_config.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
CVE-2017-5753

(cherry picked from commit efa61c8cf2950ab5c0e66cff3cabe2a2b24e81ba)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agousb: gadget: storage: Fix Spectre v1 vulnerability
Gustavo A. R. Silva [Tue, 16 Oct 2018 10:16:45 +0000 (12:16 +0200)]
usb: gadget: storage: Fix Spectre v1 vulnerability

num can be indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/usb/gadget/function/f_mass_storage.c:3177 fsg_lun_make() warn:
potential spectre issue 'fsg_opts->common->luns' [r] (local cap)

Fix this by sanitizing num before using it to index
fsg_opts->common->luns

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Felipe Balbi <felipe.balbi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2017-5753

(cherry picked from commit 9ae24af3669111d418242caec8dd4ebd9ba26860)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agodrm/bufs: Fix Spectre v1 vulnerability
Gustavo A. R. Silva [Tue, 16 Oct 2018 09:55:49 +0000 (11:55 +0200)]
drm/bufs: Fix Spectre v1 vulnerability

idx can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential
spectre issue 'dma->buflist' [r] (local cap)

Fix this by sanitizing idx before using it to index dma->buflist

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016095549.GA23586@embeddedor.com
CVE-2017-5753

(cherry picked from commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoRDMA/ucma: Fix Spectre v1 vulnerability
Gustavo A. R. Silva [Tue, 16 Oct 2018 14:59:01 +0000 (16:59 +0200)]
RDMA/ucma: Fix Spectre v1 vulnerability

hdr.cmd can be indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/infiniband/core/ucma.c:1686 ucma_write() warn: potential
spectre issue 'ucma_cmd_table' [r] (local cap)

Fix this by sanitizing hdr.cmd before using it to index
ucm_cmd_table.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
CVE-2017-5753

(cherry picked from commit a3671a4f973ee9d9621d60166cc3b037c397d604)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoIB/ucm: Fix Spectre v1 vulnerability
Gustavo A. R. Silva [Tue, 16 Oct 2018 14:32:40 +0000 (16:32 +0200)]
IB/ucm: Fix Spectre v1 vulnerability

hdr.cmd can be indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/infiniband/core/ucm.c:1127 ib_ucm_write() warn: potential
spectre issue 'ucm_cmd_table' [r] (local cap)

Fix this by sanitizing hdr.cmd before using it to index
ucm_cmd_table.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
CVE-2017-5753

(cherry picked from commit 0295e39595e1146522f2722715dba7f7fba42217)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agonl80211: Fix possible Spectre-v1 for CQM RSSI thresholds
Masashi Honma [Tue, 25 Sep 2018 02:15:01 +0000 (11:15 +0900)]
nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds

Use array_index_nospec() to sanitize i with respect to speculation.

Note that the user doesn't control i directly, but can make it out
of bounds by not finding a threshold in the array.

Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
[add note about user control, as explained by Masashi]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
CVE-2017-5753

(cherry picked from commit 1222a16014888ed9733c11e221730d4a8196222b)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agonl80211: Fix possible Spectre-v1 for NL80211_TXRATE_HT
Masashi Honma [Tue, 25 Sep 2018 02:15:00 +0000 (11:15 +0900)]
nl80211: Fix possible Spectre-v1 for NL80211_TXRATE_HT

Use array_index_nospec() to sanitize ridx with respect to speculation.

Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
CVE-2017-5753

(cherry picked from commit 30fe6d50eb088783c8729c7d930f65296b2b3fa7)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agotty: vt_ioctl: fix potential Spectre v1
Gustavo A. R. Silva [Thu, 16 Aug 2018 20:30:38 +0000 (15:30 -0500)]
tty: vt_ioctl: fix potential Spectre v1

vsa.console is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/tty/vt/vt_ioctl.c:711 vt_ioctl() warn: potential spectre issue
'vc_cons' [r]

Fix this by sanitizing vsa.console before using it to index vc_cons

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2017-5753

(cherry picked from commit e97267cb4d1ee01ca0929638ec0fcbb0904f903d)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agomisc: hmc6352: fix potential Spectre v1
Gustavo A. R. Silva [Wed, 15 Aug 2018 15:50:41 +0000 (10:50 -0500)]
misc: hmc6352: fix potential Spectre v1

val is indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/misc/hmc6352.c:54 compass_store() warn: potential spectre issue
'map' [r]

Fix this by sanitizing val before using it to index map

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CVE-2017-5753

(cherry picked from commit de916736aaaadddbd6061472969f667b14204aa9)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoswitchtec: Fix Spectre v1 vulnerability
Gustavo A. R. Silva [Thu, 16 Aug 2018 19:06:46 +0000 (14:06 -0500)]
switchtec: Fix Spectre v1 vulnerability

p.port can is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

  drivers/pci/switch/switchtec.c:912 ioctl_port_to_pff() warn: potential spectre issue 'pcfg->dsp_pff_inst_id' [r]

Fix this by sanitizing p.port before using it to index
pcfg->dsp_pff_inst_id

Notice that given that speculation windows are large, the policy is to kill
the speculation on the first load and not worry if it can be completed with
a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Logan Gunthorpe <logang@deltatee.com>
Cc: stable@vger.kernel.org
CVE-2017-5753

(cherry picked from commit 46feb6b495f7628a6dbf36c4e6d80faf378372d4)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agomac80211_hwsim: Fix possible Spectre-v1 for hwsim_world_regdom_custom
Jinbum Park [Tue, 31 Jul 2018 14:10:40 +0000 (23:10 +0900)]
mac80211_hwsim: Fix possible Spectre-v1 for hwsim_world_regdom_custom

User controls @idx which to be used as index of hwsim_world_regdom_custom.
So, It can be exploited via Spectre-like attack. (speculative execution)

This kind of attack leaks address of hwsim_world_regdom_custom,
It leads an attacker to bypass security mechanism such as KASLR.

So sanitize @idx before using it to prevent attack.

I leveraged strategy [1] to find and exploit this gadget.

[1] https://github.com/jinb-park/linux-exploit/tree/master/exploit-remaining-spectre-gadget/

Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
[johannes: unwrap URL]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
CVE-2017-5753

(backported from commit 3a2af7cccbbaf2362db9053a946a6084e12bfa73)
[juergh: Adjusted context.]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agohwmon: (nct6775) Fix potential Spectre v1
Gustavo A. R. Silva [Wed, 15 Aug 2018 13:14:37 +0000 (08:14 -0500)]
hwmon: (nct6775) Fix potential Spectre v1

val can be indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

vers/hwmon/nct6775.c:2698 store_pwm_weight_temp_sel() warn: potential
spectre issue 'data->temp_src' [r]

Fix this by sanitizing val before using it to index data->temp_src

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
CVE-2017-5753

(cherry picked from commit d49dbfade96d5b0863ca8a90122a805edd5ef50a)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agofs/quota: Fix spectre gadget in do_quotactl
Jeremy Cline [Tue, 31 Jul 2018 01:37:31 +0000 (01:37 +0000)]
fs/quota: Fix spectre gadget in do_quotactl

'type' is user-controlled, so sanitize it after the bounds check to
avoid using it in speculative execution. This covers the following
potential gadgets detected with the help of smatch:

* fs/ext4/super.c:5741 ext4_quota_read() warn: potential spectre issue
  'sb_dqopt(sb)->files' [r]
* fs/ext4/super.c:5778 ext4_quota_write() warn: potential spectre issue
  'sb_dqopt(sb)->files' [r]
* fs/f2fs/super.c:1552 f2fs_quota_read() warn: potential spectre issue
  'sb_dqopt(sb)->files' [r]
* fs/f2fs/super.c:1608 f2fs_quota_write() warn: potential spectre issue
  'sb_dqopt(sb)->files' [r]
* fs/quota/dquot.c:412 mark_info_dirty() warn: potential spectre issue
  'sb_dqopt(sb)->info' [w]
* fs/quota/dquot.c:933 dqinit_needed() warn: potential spectre issue
  'dquots' [r]
* fs/quota/dquot.c:2112 dquot_commit_info() warn: potential spectre
  issue 'dqopt->ops' [r]
* fs/quota/dquot.c:2362 vfs_load_quota_inode() warn: potential spectre
  issue 'dqopt->files' [w] (local cap)
* fs/quota/dquot.c:2369 vfs_load_quota_inode() warn: potential spectre
  issue 'dqopt->ops' [w] (local cap)
* fs/quota/dquot.c:2370 vfs_load_quota_inode() warn: potential spectre
  issue 'dqopt->info' [w] (local cap)
* fs/quota/quota.c:110 quota_getfmt() warn: potential spectre issue
  'sb_dqopt(sb)->info' [r]
* fs/quota/quota_v2.c:84 v2_check_quota_file() warn: potential spectre
  issue 'quota_magics' [w]
* fs/quota/quota_v2.c:85 v2_check_quota_file() warn: potential spectre
  issue 'quota_versions' [w]
* fs/quota/quota_v2.c:96 v2_read_file_info() warn: potential spectre
  issue 'dqopt->info' [r]
* fs/quota/quota_v2.c:172 v2_write_file_info() warn: potential spectre
  issue 'dqopt->info' [r]

Additionally, a quick inspection indicates there are array accesses with
'type' in quota_on() and quota_off() functions which are also addressed
by this.

Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jeremy Cline <jcline@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
CVE-2017-5753

(cherry picked from commit 7b6924d94a60c6b8c1279ca003e8744e6cd9e8b1)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agonet: sock_diag: Fix spectre v1 gadget in __sock_diag_cmd()
Jeremy Cline [Mon, 13 Aug 2018 22:23:13 +0000 (22:23 +0000)]
net: sock_diag: Fix spectre v1 gadget in __sock_diag_cmd()

req->sdiag_family is a user-controlled value that's used as an array
index. Sanitize it after the bounds check to avoid speculative
out-of-bounds array access.

This also protects the sock_is_registered() call, so this removes the
sanitize call there.

Fixes: e978de7a6d38 ("net: socket: Fix potential spectre v1 gadget in sock_is_registered")
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: konrad.wilk@oracle.com
Cc: jamie.iles@oracle.com
Cc: liran.alon@oracle.com
Cc: stable@vger.kernel.org
Signed-off-by: Jeremy Cline <jcline@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
CVE-2017-5753

(backported from commit 66b51b0a0341fd42ce657739bdae0561b0410a85)
[juergh: Adjusted for missing sock_is_registered().]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agodrm/i915/kvmgt: Fix potential Spectre v1
Gustavo A. R. Silva [Fri, 3 Aug 2018 03:40:19 +0000 (22:40 -0500)]
drm/i915/kvmgt: Fix potential Spectre v1

info.index can be indirectly controlled by user-space, hence leading
to a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/gpu/drm/i915/gvt/kvmgt.c:1232 intel_vgpu_ioctl() warn:
potential spectre issue 'vgpu->vdev.region' [r]

Fix this by sanitizing info.index before indirectly using it to index
vgpu->vdev.region

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
CVE-2017-5753

(cherry picked from commit de5372da605d3bca46e3102bab51b7e1c0e0a6f6)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoext4: fix spectre gadget in ext4_mb_regular_allocator()
Jeremy Cline [Thu, 2 Aug 2018 04:03:40 +0000 (00:03 -0400)]
ext4: fix spectre gadget in ext4_mb_regular_allocator()

'ac->ac_g_ex.fe_len' is a user-controlled value which is used in the
derivation of 'ac->ac_2order'. 'ac->ac_2order', in turn, is used to
index arrays which makes it a potential spectre gadget. Fix this by
sanitizing the value assigned to 'ac->ac2_order'.  This covers the
following accesses found with the help of smatch:

* fs/ext4/mballoc.c:1896 ext4_mb_simple_scan_group() warn: potential
  spectre issue 'grp->bb_counters' [w] (local cap)

* fs/ext4/mballoc.c:445 mb_find_buddy() warn: potential spectre issue
  'EXT4_SB(e4b->bd_sb)->s_mb_offsets' [r] (local cap)

* fs/ext4/mballoc.c:446 mb_find_buddy() warn: potential spectre issue
  'EXT4_SB(e4b->bd_sb)->s_mb_maxs' [r] (local cap)

Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Jeremy Cline <jcline@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
CVE-2017-5753

(cherry picked from commit 1a5d5e5d51e75a5bca67dadbcea8c841934b7b85)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agonetlink: Fix spectre v1 gadget in netlink_create()
Jeremy Cline [Tue, 31 Jul 2018 21:13:16 +0000 (21:13 +0000)]
netlink: Fix spectre v1 gadget in netlink_create()

'protocol' is a user-controlled value, so sanitize it after the bounds
check to avoid using it for speculative out-of-bounds access to arrays
indexed by it.

This addresses the following accesses detected with the help of smatch:

* net/netlink/af_netlink.c:654 __netlink_create() warn: potential
  spectre issue 'nlk_cb_mutex_keys' [w]

* net/netlink/af_netlink.c:654 __netlink_create() warn: potential
  spectre issue 'nlk_cb_mutex_key_strings' [w]

* net/netlink/af_netlink.c:685 netlink_create() warn: potential spectre
  issue 'nl_table' [w] (local cap)

Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Jeremy Cline <jcline@redhat.com>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
CVE-2017-5753

(cherry picked from commit bc5b6c0b62b932626a135f516a41838c510c6eba)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agodrm/amdgpu/pm: Fix potential Spectre v1
Gustavo A. R. Silva [Mon, 23 Jul 2018 16:32:32 +0000 (11:32 -0500)]
drm/amdgpu/pm: Fix potential Spectre v1

idx can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:408 amdgpu_set_pp_force_state()
warn: potential spectre issue 'data.states'

Fix this by sanitizing idx before using it to index data.states

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
CVE-2017-5753

(backported from commit ddf74e79a54070f277ae520722d3bab7f7a6c67a)
[juergh: Adjusted context.]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agonet: socket: Fix potential spectre v1 gadget in sock_is_registered
Jeremy Cline [Fri, 27 Jul 2018 22:43:02 +0000 (22:43 +0000)]
net: socket: Fix potential spectre v1 gadget in sock_is_registered

'family' can be a user-controlled value, so sanitize it after the bounds
check to avoid speculative out-of-bounds access.

Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jeremy Cline <jcline@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
CVE-2017-5753

(backported from commit e978de7a6d382ec378830ca2cf38e902df0b6d84)
[juergh: Adjusted for missing sock_is_registered().]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agonet: socket: fix potential spectre v1 gadget in socketcall
Jeremy Cline [Fri, 27 Jul 2018 22:43:01 +0000 (22:43 +0000)]
net: socket: fix potential spectre v1 gadget in socketcall

'call' is a user-controlled value, so sanitize the array index after the
bounds check to avoid speculating past the bounds of the 'nargs' array.

Found with the help of Smatch:

net/socket.c:2508 __do_sys_socketcall() warn: potential spectre issue
'nargs' [r] (local cap)

Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jeremy Cline <jcline@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
CVE-2017-5753

(cherry picked from commit c8e8cd579bb4265651df8223730105341e61a2d1)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agopktcdvd: Fix possible Spectre-v1 for pkt_devs
Jinbum Park [Sat, 28 Jul 2018 04:20:44 +0000 (13:20 +0900)]
pktcdvd: Fix possible Spectre-v1 for pkt_devs

User controls @dev_minor which to be used as index of pkt_devs.
So, It can be exploited via Spectre-like attack. (speculative execution)

This kind of attack leaks address of pkt_devs, [1]
It leads an attacker to bypass security mechanism such as KASLR.

So sanitize @dev_minor before using it to prevent attack.

[1] https://github.com/jinb-park/linux-exploit/
tree/master/exploit-remaining-spectre-gadget/leak_pkt_devs.c

Signed-off-by: Jinbum Park <jinb.park7@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
CVE-2017-5753

(cherry picked from commit 55690c07b44a82cc3359ce0c233f4ba7d80ba145)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoKVM: arm/arm64: vgic: Fix possible spectre-v1 write in vgic_mmio_write_apr()
Mark Rutland [Tue, 10 Jul 2018 18:01:23 +0000 (19:01 +0100)]
KVM: arm/arm64: vgic: Fix possible spectre-v1 write in vgic_mmio_write_apr()

It's possible for userspace to control n. Sanitize n when using it as an
array index, to inhibit the potential spectre-v1 write gadget.

Note that while it appears that n must be bound to the interval [0,3]
due to the way it is extracted from addr, we cannot guarantee that
compiler transformations (and/or future refactoring) will ensure this is
the case, and given this is a slow path it's better to always perform
the masking.

Found by smatch.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Christoffer Dall <christoffer.dall@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: kvmarm@lists.cs.columbia.edu
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
CVE-2017-5753

(cherry picked from commit 6b8b9a48545e08345b8ff77c9fd51b1aebdbefb3)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoarm64: fix possible spectre-v1 write in ptrace_hbp_set_event()
Mark Rutland [Tue, 10 Jul 2018 18:01:22 +0000 (19:01 +0100)]
arm64: fix possible spectre-v1 write in ptrace_hbp_set_event()

It's possible for userspace to control idx. Sanitize idx when using it
as an array index, to inhibit the potential spectre-v1 write gadget.

Found by smatch.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
CVE-2017-5753

(cherry picked from commit 14d6e289a89780377f8bb09de8926d3c62d763cd)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agos390/keyboard: sanitize array index in do_kdsk_ioctl
Martin Schwidefsky [Thu, 19 Jul 2018 08:27:33 +0000 (10:27 +0200)]
s390/keyboard: sanitize array index in do_kdsk_ioctl

The kbd_ioctl uses two user controlled indexes for KDGKBENT/KDSKBENT.
Use array_index_nospec to prevent any out of bounds speculation.

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
CVE-2017-5753

(cherry picked from commit 054732837c312c6007994badbc86b0976b228f77)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agolibahci: Fix possible Spectre-v1 pmp indexing in ahci_led_store()
John Garry [Fri, 8 Jun 2018 10:26:33 +0000 (18:26 +0800)]
libahci: Fix possible Spectre-v1 pmp indexing in ahci_led_store()

Currently smatch warns of possible Spectre-V1 issue in ahci_led_store():
drivers/ata/libahci.c:1150 ahci_led_store() warn: potential spectre issue 'pp->em_priv' (local cap)

Userspace controls @pmp from following callchain:
em_message->store()
->ata_scsi_em_message_store()
-->ap->ops->em_store()
--->ahci_led_store()

After the mask+shift @pmp is effectively an 8b value, which is used to
index into an array of length 8, so sanitize the array index.

Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
CVE-2017-5753

(cherry picked from commit fae2a63737e5973f1426bc139935a0f42e232844)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agosysvipc/sem: mitigate semnum index against spectre v1
Davidlohr Bueso [Thu, 14 Jun 2018 22:27:51 +0000 (15:27 -0700)]
sysvipc/sem: mitigate semnum index against spectre v1

Both smatch and coverity are reporting potential issues with spectre
variant 1 with the 'semnum' index within the sma->sems array, ie:

  ipc/sem.c:388 sem_lock() warn: potential spectre issue 'sma->sems'
  ipc/sem.c:641 perform_atomic_semop_slow() warn: potential spectre issue 'sma->sems'
  ipc/sem.c:721 perform_atomic_semop() warn: potential spectre issue 'sma->sems'

Avoid any possible speculation by using array_index_nospec() thus
ensuring the semnum value is bounded to [0, sma->sem_nsems).  With the
exception of sem_lock() all of these are slowpaths.

Link: http://lkml.kernel.org/r/20180423171131.njs4rfm2yzyeg6do@linux-n805
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
CVE-2017-5753

(cherry picked from commit ec67aaa46dce26d671b46c94ac674ad0b67d044c)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agomedia: dvb_ca_en50221: prevent using slot_info for Spectre attacs
Mauro Carvalho Chehab [Tue, 15 May 2018 12:31:38 +0000 (08:31 -0400)]
media: dvb_ca_en50221: prevent using slot_info for Spectre attacs

slot can be controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability,
as warned by smatch:
drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() warn: potential spectre issue 'ca->slot_info' (local cap)

Acked-by: "Jasmin J." <jasmin@anw.at>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
CVE-2017-5753

(backported from commit 4f5ab5d7a5e765ad231a132f82cec71de88b9aad)
[juergh:
 - Adjusted context.
 - Folded in a24e6348e5a0 ("media: dvb_ca_en50221: sanity check slot number from userspace").]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoKVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_get_irq()
Mark Rutland [Wed, 25 Apr 2018 16:13:41 +0000 (17:13 +0100)]
KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_get_irq()

It's possible for userspace to control intid. Sanitize intid when using
it as an array index.

At the same time, sort the includes when adding <linux/nospec.h>.

Found by smatch.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: kvmarm@lists.cs.columbia.edu
Signed-off-by: Will Deacon <will.deacon@arm.com>
CVE-2017-5753

(backported from commit 41b87599c74300027f305d7b34368ec558978ff2)
[juergh: Adjusted context.]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoUBUNTU: SAUCE: [Fix] x86/speculation: Use ARCH_CAPABILITIES to skip L1D flush on...
Juerg Haefliger [Wed, 10 Apr 2019 10:10:00 +0000 (12:10 +0200)]
UBUNTU: SAUCE: [Fix] x86/speculation: Use ARCH_CAPABILITIES to skip L1D flush on vmentry

BugLink: https://bugs.launchpad.net/bugs/1822760
Replace whitespaces with tabs to match upstream.

Fixes: 364a4311f8c6 ("x86/speculation: Use ARCH_CAPABILITIES to skip L1D flush on vmentry")
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoUBUNTU: SAUCE: [Fix] x86/KVM/VMX: Add L1D flush logic
Juerg Haefliger [Wed, 10 Apr 2019 10:10:00 +0000 (12:10 +0200)]
UBUNTU: SAUCE: [Fix] x86/KVM/VMX: Add L1D flush logic

BugLink: https://bugs.launchpad.net/bugs/1822760
The backport of upstream commit c595ceee4570 ("x86/KVM/VMX: Add L1D flush
logic") incorrectly put the enabling of L1D flushing in
kvm_write_guest_virt_helper() instead of kvm_write_guest_virt_system().

Fixes: f0ace387064d ("x86/KVM/VMX: Add L1D flush logic")
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoKVM: X86: Allow userspace to define the microcode version
Wanpeng Li [Wed, 10 Apr 2019 10:10:00 +0000 (12:10 +0200)]
KVM: X86: Allow userspace to define the microcode version

BugLink: https://bugs.launchpad.net/bugs/1822760
Linux (among the others) has checks to make sure that certain features
aren't enabled on a certain family/model/stepping if the microcode version
isn't greater than or equal to a known good version.

By exposing the real microcode version, we're preventing buggy guests that
don't check that they are running virtualized (i.e., they should trust the
hypervisor) from disabling features that are effectively not buggy.

Suggested-by: Filippo Sironi <sironi@amazon.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Liran Alon <liran.alon@oracle.com>
Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
(backported from commit 518e7b94817abed94becfe6a44f1ece0d4745afe)
[juergh:
 - Adjusted context.
 - rdmsrl -> rdmsrl_safe (to match final upstream).]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoKVM: VMX: fixes for vmentry_l1d_flush module parameter
Paolo Bonzini [Wed, 10 Apr 2019 10:10:00 +0000 (12:10 +0200)]
KVM: VMX: fixes for vmentry_l1d_flush module parameter

BugLink: https://bugs.launchpad.net/bugs/1822760
Two bug fixes:

1) missing entries in the l1d_param array; this can cause a host crash
if an access attempts to reach the missing entry. Future-proof the get
function against any overflows as well.  However, the two entries
VMENTER_L1D_FLUSH_EPT_DISABLED and VMENTER_L1D_FLUSH_NOT_REQUIRED must
not be accepted by the parse function, so disable them there.

2) invalid values must be rejected even if the CPU does not have the
bug, so test for them before checking boot_cpu_has(X86_BUG_L1TF)

... and a small refactoring, since the .cmd field is redundant with
the index in the array.

Reported-by: Bandan Das <bsd@redhat.com>
Cc: stable@vger.kernel.org
Fixes: a7b9020b06ec6d7c3f3b0d4ef1a9eba12654f4f7
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 0027ff2a75f9dcf0537ac0a65c5840b0e21a4950)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoKVM: SVM: Add MSR-based feature support for serializing LFENCE
Tom Lendacky [Wed, 10 Apr 2019 10:10:00 +0000 (12:10 +0200)]
KVM: SVM: Add MSR-based feature support for serializing LFENCE

BugLink: https://bugs.launchpad.net/bugs/1822760
In order to determine if LFENCE is a serializing instruction on AMD
processors, MSR 0xc0011029 (MSR_F10H_DECFG) must be read and the state
of bit 1 checked.  This patch will add support to allow a guest to
properly make this determination.

Add the MSR feature callback operation to svm.c and add MSR 0xc0011029
to the list of MSR-based features.  If LFENCE is serializing, then the
feature is supported, allowing the hypervisor to set the value of the
MSR that guest will see.  Support is also added to write (hypervisor only)
and read the MSR value for the guest.  A write by the guest will result in
a #GP.  A read by the guest will return the value as set by the host.  In
this way, the support to expose the feature to the guest is controlled by
the hypervisor.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
(backported from commit d1d93fa90f1afa926cb060b7f78ab01a65705b4d)
[juergh: Adjusted context.]
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agox86/speculation/l1tf: Suggest what to do on systems with too much RAM
Vlastimil Babka [Wed, 10 Apr 2019 10:10:00 +0000 (12:10 +0200)]
x86/speculation/l1tf: Suggest what to do on systems with too much RAM

BugLink: https://bugs.launchpad.net/bugs/1822760
Two users have reported [1] that they have an "extremely unlikely" system
with more than MAX_PA/2 memory and L1TF mitigation is not effective.

Make the warning more helpful by suggesting the proper mem=X kernel boot
parameter to make it effective and a link to the L1TF document to help
decide if the mitigation is worth the unusable RAM.

[1] https://bugzilla.suse.com/show_bug.cgi?id=1105536

Suggested-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/966571f0-9d7f-43dc-92c6-a10eec7a1254@suse.cz
(cherry picked from commit 6a012288d6906fee1dbc244050ade1dafe4a9c8d)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
4 weeks agoUBUNTU: SAUCE: ACPI / bus: Add some Lenovo laptops in list of acpi table term list
Aaron Ma [Tue, 2 Apr 2019 04:10:13 +0000 (12:10 +0800)]
UBUNTU: SAUCE: ACPI / bus: Add some Lenovo laptops in list of acpi table term list

BugLink: https://bugs.launchpad.net/bugs/1819921
Some Lenovo laptops failed to boot because of no package handling
with module-level code which is supported from v4.17-rc1.

Due to the regression concerns, add these series of laptops in a quirk
list to be handled.

V2:
Fix non-x86 building error.

Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Acked-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: hwang4 <hui.wang@canonical.com>
Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>