--- /dev/null
+From 9a00674213a3f00394f4e3221b88f2d21fc05789 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Fri, 29 Dec 2017 14:30:19 -0600
+Subject: crypto: algapi - fix NULL dereference in crypto_remove_spawns()
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 9a00674213a3f00394f4e3221b88f2d21fc05789 upstream.
+
+syzkaller triggered a NULL pointer dereference in crypto_remove_spawns()
+via a program that repeatedly and concurrently requests AEADs
+"authenc(cmac(des3_ede-asm),pcbc-aes-aesni)" and hashes "cmac(des3_ede)"
+through AF_ALG, where the hashes are requested as "untested"
+(CRYPTO_ALG_TESTED is set in ->salg_mask but clear in ->salg_feat; this
+causes the template to be instantiated for every request).
+
+Although AF_ALG users really shouldn't be able to request an "untested"
+algorithm, the NULL pointer dereference is actually caused by a
+longstanding race condition where crypto_remove_spawns() can encounter
+an instance which has had spawn(s) "grabbed" but hasn't yet been
+registered, resulting in ->cra_users still being NULL.
+
+We probably should properly initialize ->cra_users earlier, but that
+would require updating many templates individually. For now just fix
+the bug in a simple way that can easily be backported: make
+crypto_remove_spawns() treat a NULL ->cra_users list as empty.
+
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ crypto/algapi.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/crypto/algapi.c
++++ b/crypto/algapi.c
+@@ -167,6 +167,18 @@ void crypto_remove_spawns(struct crypto_
+
+ spawn->alg = NULL;
+ spawns = &inst->alg.cra_users;
++
++ /*
++ * We may encounter an unregistered instance here, since
++ * an instance's spawns are set up prior to the instance
++ * being registered. An unregistered instance will have
++ * NULL ->cra_users.next, since ->cra_users isn't
++ * properly initialized until registration. But an
++ * unregistered instance cannot have any users, so treat
++ * it the same as ->cra_users being empty.
++ */
++ if (spawns->next == NULL)
++ break;
+ }
+ } while ((spawns = crypto_more_spawns(alg, &stack, &top,
+ &secondary_spawns)));
--- /dev/null
+From 0d9cac0ca0429830c40fe1a4e50e60f6221fd7b6 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Wed, 10 Jan 2018 12:40:04 +0300
+Subject: drm/vmwgfx: Potential off by one in vmw_view_add()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit 0d9cac0ca0429830c40fe1a4e50e60f6221fd7b6 upstream.
+
+The vmw_view_cmd_to_type() function returns vmw_view_max (3) on error.
+It's one element beyond the end of the vmw_view_cotables[] table.
+
+My read on this is that it's possible to hit this failure. header->id
+comes from vmw_cmd_check() and it's a user controlled number between
+1040 and 1225 so we can hit that error. But I don't have the hardware
+to test this code.
+
+Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+@@ -2729,6 +2729,8 @@ static int vmw_cmd_dx_view_define(struct
+ }
+
+ view_type = vmw_view_cmd_to_type(header->id);
++ if (view_type == vmw_view_max)
++ return -EINVAL;
+ cmd = container_of(header, typeof(*cmd), header);
+ ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface,
+ user_surface_converter,
--- /dev/null
+From ytht.net@gmail.com Sat Jan 13 15:46:36 2018
+From: Lepton Wu <ytht.net@gmail.com>
+Date: Fri, 12 Jan 2018 13:42:56 -0800
+Subject: kaiser: Set _PAGE_NX only if supported
+To: stable@vger.kernel.org
+Cc: gregkh@linuxfoundation.org, groeck@chromium.org, hshan@google.com, Lepton Wu <ytht.net@gmail.com>
+Message-ID: <20180112214256.257463-1-ytht.net@gmail.com>
+
+From: Lepton Wu <ytht.net@gmail.com>
+
+This finally resolve crash if loaded under qemu + haxm. Haitao Shan pointed
+out that the reason of that crash is that NX bit get set for page tables.
+It seems we missed checking if _PAGE_NX is supported in kaiser_add_user_map
+
+Link: https://www.spinics.net/lists/kernel/msg2689835.html
+
+Reviewed-by: Guenter Roeck <groeck@chromium.org>
+Signed-off-by: Lepton Wu <ytht.net@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/mm/kaiser.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/mm/kaiser.c
++++ b/arch/x86/mm/kaiser.c
+@@ -197,6 +197,8 @@ static int kaiser_add_user_map(const voi
+ * requires that not to be #defined to 0): so mask it off here.
+ */
+ flags &= ~_PAGE_GLOBAL;
++ if (!(__supported_pte_mask & _PAGE_NX))
++ flags &= ~_PAGE_NX;
+
+ for (; address < end_addr; address += PAGE_SIZE) {
+ target_address = get_pa_from_mapping(address);
--- /dev/null
+From 75f139aaf896d6fdeec2e468ddfa4b2fe469bf40 Mon Sep 17 00:00:00 2001
+From: Andrew Honig <ahonig@google.com>
+Date: Wed, 10 Jan 2018 10:12:03 -0800
+Subject: KVM: x86: Add memory barrier on vmcs field lookup
+
+From: Andrew Honig <ahonig@google.com>
+
+commit 75f139aaf896d6fdeec2e468ddfa4b2fe469bf40 upstream.
+
+This adds a memory barrier when performing a lookup into
+the vmcs_field_to_offset_table. This is related to
+CVE-2017-5753.
+
+Signed-off-by: Andrew Honig <ahonig@google.com>
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/vmx.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/vmx.c
++++ b/arch/x86/kvm/vmx.c
+@@ -857,8 +857,16 @@ static inline short vmcs_field_to_offset
+ {
+ BUILD_BUG_ON(ARRAY_SIZE(vmcs_field_to_offset_table) > SHRT_MAX);
+
+- if (field >= ARRAY_SIZE(vmcs_field_to_offset_table) ||
+- vmcs_field_to_offset_table[field] == 0)
++ if (field >= ARRAY_SIZE(vmcs_field_to_offset_table))
++ return -ENOENT;
++
++ /*
++ * FIXME: Mitigation for CVE-2017-5753. To be replaced with a
++ * generic mechanism.
++ */
++ asm("lfence");
++
++ if (vmcs_field_to_offset_table[field] == 0)
+ return -ENOENT;
+
+ return vmcs_field_to_offset_table[field];
--- /dev/null
+From 21acdf45f4958135940f0b4767185cf911d4b010 Mon Sep 17 00:00:00 2001
+From: Ilya Dryomov <idryomov@gmail.com>
+Date: Thu, 21 Dec 2017 15:35:11 +0100
+Subject: rbd: set max_segments to USHRT_MAX
+
+From: Ilya Dryomov <idryomov@gmail.com>
+
+commit 21acdf45f4958135940f0b4767185cf911d4b010 upstream.
+
+Commit d3834fefcfe5 ("rbd: bump queue_max_segments") bumped
+max_segments (unsigned short) to max_hw_sectors (unsigned int).
+max_hw_sectors is set to the number of 512-byte sectors in an object
+and overflows unsigned short for 32M (largest possible) objects, making
+the block layer resort to handing us single segment (i.e. single page
+or even smaller) bios in that case.
+
+Fixes: d3834fefcfe5 ("rbd: bump queue_max_segments")
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Reviewed-by: Alex Elder <elder@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/rbd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/block/rbd.c
++++ b/drivers/block/rbd.c
+@@ -4511,7 +4511,7 @@ static int rbd_init_disk(struct rbd_devi
+ segment_size = rbd_obj_bytes(&rbd_dev->header);
+ blk_queue_max_hw_sectors(q, segment_size / SECTOR_SIZE);
+ q->limits.max_sectors = queue_max_hw_sectors(q);
+- blk_queue_max_segments(q, segment_size / SECTOR_SIZE);
++ blk_queue_max_segments(q, USHRT_MAX);
+ blk_queue_max_segment_size(q, segment_size);
+ blk_queue_io_min(q, segment_size);
+ blk_queue_io_opt(q, segment_size);
mlxsw-spectrum_router-fix-null-pointer-deref.patch
net-sched-fix-update-of-lastuse-in-act-modules-implementing-stats_update.patch
x86-pti-efi-broken-conversion-from-efi-to-kernel-page-table.patch
+crypto-algapi-fix-null-dereference-in-crypto_remove_spawns.patch
+rbd-set-max_segments-to-ushrt_max.patch
+x86-microcode-intel-extend-bdw-late-loading-with-a-revision-check.patch
+kvm-x86-add-memory-barrier-on-vmcs-field-lookup.patch
+drm-vmwgfx-potential-off-by-one-in-vmw_view_add.patch
+kaiser-set-_page_nx-only-if-supported.patch
--- /dev/null
+From b94b7373317164402ff7728d10f7023127a02b60 Mon Sep 17 00:00:00 2001
+From: Jia Zhang <qianyue.zj@alibaba-inc.com>
+Date: Mon, 1 Jan 2018 10:04:47 +0800
+Subject: x86/microcode/intel: Extend BDW late-loading with a revision check
+
+From: Jia Zhang <qianyue.zj@alibaba-inc.com>
+
+commit b94b7373317164402ff7728d10f7023127a02b60 upstream.
+
+Instead of blacklisting all model 79 CPUs when attempting a late
+microcode loading, limit that only to CPUs with microcode revisions <
+0x0b000021 because only on those late loading may cause a system hang.
+
+For such processors either:
+
+a) a BIOS update which might contain a newer microcode revision
+
+or
+
+b) the early microcode loading method
+
+should be considered.
+
+Processors with revisions 0x0b000021 or higher will not experience such
+hangs.
+
+For more details, see erratum BDF90 in document #334165 (Intel Xeon
+Processor E7-8800/4800 v4 Product Family Specification Update) from
+September 2017.
+
+[ bp: Heavily massage commit message and pr_* statements. ]
+
+Fixes: 723f2828a98c ("x86/microcode/intel: Disable late loading on model 79")
+Signed-off-by: Jia Zhang <qianyue.zj@alibaba-inc.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Acked-by: Tony Luck <tony.luck@intel.com>
+Cc: x86-ml <x86@kernel.org>
+Link: http://lkml.kernel.org/r/1514772287-92959-1-git-send-email-qianyue.zj@alibaba-inc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/microcode/intel.c | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/cpu/microcode/intel.c
++++ b/arch/x86/kernel/cpu/microcode/intel.c
+@@ -1051,8 +1051,17 @@ static bool is_blacklisted(unsigned int
+ {
+ struct cpuinfo_x86 *c = &cpu_data(cpu);
+
+- if (c->x86 == 6 && c->x86_model == INTEL_FAM6_BROADWELL_X) {
+- pr_err_once("late loading on model 79 is disabled.\n");
++ /*
++ * Late loading on model 79 with microcode revision less than 0x0b000021
++ * may result in a system hang. This behavior is documented in item
++ * BDF90, #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family).
++ */
++ if (c->x86 == 6 &&
++ c->x86_model == INTEL_FAM6_BROADWELL_X &&
++ c->x86_mask == 0x01 &&
++ c->microcode < 0x0b000021) {
++ pr_err_once("Erratum BDF90: late loading with revision < 0x0b000021 (0x%x) disabled.\n", c->microcode);
++ pr_err_once("Please consider either early loading through initrd/built-in or a potential BIOS update.\n");
+ return true;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
