William Grant [Tue, 30 Jan 2018 11:22:55 +0000 (22:22 +1100)]
x86/mm: Fix overlap of i386 CPU_ENTRY_AREA with FIX_BTMAP
BugLink: http://bugs.launchpad.net/bugs/1745118
Since commit 92a0f81d8957 ("x86/cpu_entry_area: Move it out of the
fixmap"), i386's CPU_ENTRY_AREA has been mapped to the memory area just
below FIXADDR_START. But already immediately before FIXADDR_START is the
FIX_BTMAP area, which means that early_ioremap can collide with the entry
area.
It's especially bad on PAE where FIX_BTMAP_BEGIN gets aligned to exactly
match CPU_ENTRY_AREA_BASE, so the first early_ioremap slot clobbers the
IDT and causes interrupts during early boot to reset the system.
The overlap wasn't a problem before the CPU entry area was introduced,
as the fixmap has classically been preceded by the pkmap or vmalloc
areas, neither of which is used until early_ioremap is out of the
picture.
Relocate CPU_ENTRY_AREA to below FIX_BTMAP, not just below the permanent
fixmap area.
Fixes: commit 92a0f81d8957 ("x86/cpu_entry_area: Move it out of the fixmap") Signed-off-by: William Grant <william.grant@canonical.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/7041d181-a019-e8b9-4e4e-48215f841e2c@canonical.com
(cherry picked from commit 55f49fcb879fbeebf2a8c1ac7c9e6d90df55f798 git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git) Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Xin Long [Fri, 19 Jan 2018 15:54:00 +0000 (16:54 +0100)]
ip_gre: remove the incorrect mtu limit for ipgre tap
BugLink: http://bugs.launchpad.net/bugs/1743746
ipgre tap driver calls ether_setup(), after commit 61e84623ace3
("net: centralize net_device min/max MTU checking"), the range
of mtu is [min_mtu, max_mtu], which is [68, 1500] by default.
It causes the dev mtu of the ipgre tap device to not be greater
than 1500, this limit value is not correct for ipgre tap device.
Besides, it's .change_mtu already does the right check. So this
patch is just to set max_mtu as 0, and leave the check to it's
.change_mtu.
Fixes: 61e84623ace3 ("net: centralize net_device min/max MTU checking") Reported-by: Jianlin Shi <jishi@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit cfddd4c33c254954927942599d299b3865743146) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Mohamed Ghannam [Sun, 10 Dec 2017 03:50:58 +0000 (03:50 +0000)]
net: ipv4: fix for a race condition in raw_sendmsg
inet->hdrincl is racy, and could lead to uninitialized stack pointer
usage, so its value should be read only once.
Fixes: c008ba5bdc9f ("ipv4: Avoid reading user iov twice after raw_probe_proto_opt") Signed-off-by: Mohamed Ghannam <simo.ghannam@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
CVE-2017-17712
(cherry picked from commit 8f659a03a0ba9289b9aeb9b4470e6fb263d6f483) Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Khalid Elmously <khalid.elmously@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Andy Whitcroft [Thu, 25 Jan 2018 10:27:00 +0000 (11:27 +0100)]
UBUNTU: [Packaging] update urgency to medium by default
BugLink: http://bugs.launchpad.net/bugs/1745338 Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Xin Long [Thu, 7 Dec 2017 15:07:00 +0000 (16:07 +0100)]
sctp: do not peel off an assoc from one netns to another one
Now when peeling off an association to the sock in another netns, all
transports in this assoc are not to be rehashed and keep use the old
key in hashtable.
As a transport uses sk->net as the hash key to insert into hashtable,
it would miss removing these transports from hashtable due to the new
netns when closing the sock and all transports are being freeed, then
later an use-after-free issue could be caused when looking up an asoc
and dereferencing those transports.
This is a very old issue since very beginning, ChunYu found it with
syzkaller fuzz testing with this series:
This patch is to block this call when peeling one assoc off from one
netns to another one, so that the netns of all transport would not
go out-sync with the key in hashtable.
Note that this patch didn't fix it by rehashing transports, as it's
difficult to handle the situation when the tuple is already in use
in the new netns. Besides, no one would like to peel off one assoc
to another netns, considering ipaddrs, ifaces, etc. are usually
different.
Reported-by: ChunYu Wang <chunwang@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
CVE-2017-15115
(cherry picked from commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74) Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Mohamed Ghannam [Fri, 8 Dec 2017 14:39:50 +0000 (15:39 +0100)]
dccp: CVE-2017-8824: use-after-free in DCCP code
Whenever the sock object is in DCCP_CLOSED state,
dccp_disconnect() must free dccps_hc_tx_ccid and
dccps_hc_rx_ccid and set to NULL.
Signed-off-by: Mohamed Ghannam <simo.ghannam@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
CVE-2017-8824
(cherry picked from commit 69c64866ce072dea1d1e59a0d61e0f66c0dffb76 linux-next) Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Jay Vosburgh [Thu, 25 Jan 2018 05:43:56 +0000 (21:43 -0800)]
UBUNTU: SAUCE: x86/entry: Fix up retpoline assembler labels
The extant assembler labels in entry_SYSCALL_64_fastpath
result in the error path incorrectly entering the retpoline logic.
This results in that logic jumping to whatever address is in %r10,
which is the fourth system call argument.
This enables a trivial means to instruct the kernel to jump
to any arbitrary address. Non-malicious executables making invalid
system calls may also cause the system to crash.
Resolve this by renumbering the assembler labels as is found
in other kernels.
CVE-2017-5753
CVE-2017-5715
Fixes: d2e0236 ("x86/entry: Use retpoline for syscall's indirect calls") Signed-off-by: Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Guest GPR values are live in the hardware GPRs at VM-exit. Do not
leave any guest values in hardware GPRs after the guest GPR values are
saved to the vcpu_vmx structure.
This is a partial mitigation for CVE 2017-5715 and CVE 2017-5753.
Specifically, it defeats the Project Zero PoC for CVE 2017-5715.
Suggested-by: Eric Northup <digitaleric@google.com> Signed-off-by: Jim Mattson <jmattson@google.com> Reviewed-by: Eric Northup <digitaleric@google.com> Reviewed-by: Benjamin Serebrin <serebrin@google.com> Reviewed-by: Andrew Honig <ahonig@google.com>
[Paolo: Add AMD bits, Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
William Grant [Thu, 11 Jan 2018 23:05:42 +0000 (17:05 -0600)]
UBUNTU: SAUCE: x86/kvm: Fix stuff_RSB() for 32-bit
CVE-2017-5753
CVE-2017-5715
Signed-off-by: William Grant <wgrant@ubuntu.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Tom Lendacky [Thu, 30 Nov 2017 22:46:40 +0000 (16:46 -0600)]
x86/microcode/AMD: Add support for fam17h microcode loading
CVE-2017-5753
CVE-2017-5715
The size for the Microcode Patch Block (MPB) for an AMD family 17h
processor is 3200 bytes. Add a #define for fam17h so that it does
not default to 2048 bytes and fail a microcode load/update.
UBUNTU: SAUCE: rfi-flush: Make the fallback robust against memory corruption
CVE-2017-5754
BugLink: http://bugs.launchpad.net/bugs/1742772
The load dependency we add in the fallback flush relies on the value
we loaded from the fallback area being zero. Although that should
always be the case, bugs happen, so make the code robust against any
corruption by xor'ing it with itself.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1742772
Add a data dependency on loads for the fallback flush. This
reduces or eliminates instances of incomplete flushing on P8 and
P9.
UBUNTU: SAUCE: rfi-flush: Add no_rfi_flush and nopti comandline options
CVE-2017-5754
BugLink: http://bugs.launchpad.net/bugs/1742772
We use the x86 'nopti' option because all the documenation on earth is
going to refer to that, and we can guess what users mean when they
specify that - they want to avoid any overhead due to Meltdown
mitigations.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1742772
We forgot to expand the number of nops in HRFI_TO_UNKNOWN when we
expanded the number of nops. The result is we actually overwrite the
rfid with a nop, which is not good. Luckily this is only used in
denorm_done, which is not hit often.
Spotted by Ram.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
UBUNTU: SAUCE: rfi-flush: Fix the fallback flush to actually activate
CVE-2017-5754
BugLink: http://bugs.launchpad.net/bugs/1742772
Since we now have three nops, we need to branch further to get over
the nops to the branch to the fallback flush.
Instead of putting the branch in slot 1 and branching by 8, put it in
0 and branch all the way to keep it simple.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
UBUNTU: SAUCE: rfi-flush: Put the fallback flushes in the real trampoline section
CVE-2017-5754
BugLink: http://bugs.launchpad.net/bugs/1742772
Otherwise they end up somewhere random depending on what code preceeds
them, which varies depending on CONFIG options. The HRFI version at
least needs to be below __end_interrupts so that the HMI early handler
can call it.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
UBUNTU: SAUCE: rfi-flush: Rework pseries logic to be more cautious
CVE-2017-5754
BugLink: http://bugs.launchpad.net/bugs/1742772
Rather than assuming a successful return from the hcall will tell us a
valid flush type, if the hcall doesn't select one of the known flush
types use the fallback.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
UBUNTU: SAUCE: rfi-flush: Rework powernv logic to be more cautious
CVE-2017-5754
BugLink: http://bugs.launchpad.net/bugs/1742772
Assume we need to do the fallback flush, unless firmware tells us
explicitly not to, by having the two needs-l1d-flush properties set to
disabled.
The previous logic assumed that the existence of a "fw-features"
node with no further properties was sufficient to indicate the flush
wasn't needed.
This should make no difference in practice with current firmwares,
because the "fw-features" node has only just been introduced, so there
are no machines in the wild which have an empty "fw-features" node.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Balbir Singh [Fri, 5 Jan 2018 17:25:48 +0000 (22:55 +0530)]
UBUNTU: SAUCE: rfi-flush: Add barriers to the fallback L1D flushing
CVE-2017-5754
BugLink: http://bugs.launchpad.net/bugs/1742772
Add a hwsync after DCBT_STOP_ALL_STREAM_IDS to order loads/
stores prior to stopping prefetch with loads and stores
as a part of the flushing. A lwsync is needed to ensure
that after we don't mix the flushing of one congruence class
with another
Nicholas Piggin [Fri, 5 Jan 2018 13:50:48 +0000 (19:20 +0530)]
UBUNTU: SAUCE: rfi-flush: Add speculation barrier before ori 30,30,0 flush
CVE-2017-5754
BugLink: http://bugs.launchpad.net/bugs/1742772
add an ori 31,31,0 speculation barrier ahead of the ori 30,30,0 flush
type, which was found necessary to completely flush out all lines.
UBUNTU: SAUCE: rfi-flush: Allow HV to advertise multiple flush types
CVE-2017-5754
BugLink: http://bugs.launchpad.net/bugs/1742772
To enable migration between machines with different flush types
enabled, allow the hypervisor to advertise more than one flush type,
and if we see that we patch both in. On any given machine only one
will be active (due to firmware configuration), but a kernel will be
able to migrate between machines with different flush instructions
enabled without modification.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com> Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1742772
This patch chnages the fallback flush to load all ways of a set,
then move to the next set. This is the best way to flush the cache,
accoring to HW people.
Vasily Gorbik [Tue, 2 Jan 2018 10:26:25 +0000 (10:26 +0000)]
s390: introduce CPU alternatives
CVE-2017-5754
BugLink: http://bugs.launchpad.net/bugs/1742771
Implement CPU alternatives, which allows to optionally patch newer
instructions at runtime, based on CPU facilities availability.
A new kernel boot parameter "noaltinstr" disables patching.
Current implementation is derived from x86 alternatives. Although
ideal instructions padding (when altinstr is longer then oldinstr)
is added at compile time, and no oldinstr nops optimization has to be
done at runtime. Also couple of compile time sanity checks are done:
1. oldinstr and altinstr must be <= 254 bytes long,
2. oldinstr and altinstr must not have an odd length.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Tom Lendacky [Wed, 20 Dec 2017 10:55:48 +0000 (10:55 +0000)]
x86/cpu/AMD: Remove now unused definition of MFENCE_RDTSC feature
CVE-2017-5753
CVE-2017-5715
With the switch to using LFENCE_RDTSC on AMD platforms there is no longer
a need for the MFENCE_RDTSC feature. Remove it usage and definition.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Tom Lendacky [Wed, 20 Dec 2017 10:55:47 +0000 (10:55 +0000)]
x86/svm: Add code to clear registers on VM exit
CVE-2017-5753
CVE-2017-5715
Clear registers on VM exit to prevent speculative use of them.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Tom Lendacky [Wed, 20 Dec 2017 10:55:47 +0000 (10:55 +0000)]
x86/svm: Add code to clobber the RSB on VM exit
CVE-2017-5753
CVE-2017-5715
Add code to overwrite the local CPU RSB entries from the previous less
privileged mode.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Tom Lendacky [Wed, 20 Dec 2017 10:55:47 +0000 (10:55 +0000)]
KVM: x86: Add speculative control CPUID support for guests
CVE-2017-5753
CVE-2017-5715
Provide the guest with the speculative control CPUID related values.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Tom Lendacky [Wed, 20 Dec 2017 10:55:47 +0000 (10:55 +0000)]
x86/svm: Set IBPB when running a different VCPU
CVE-2017-5753
CVE-2017-5715
Set IBPB (Indirect Branch Prediction Barrier) when the current CPU is
going to run a VCPU different from what was previously run.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
projects / mirror_ubuntu-artful-kernel.git / log