--- /dev/null
+From bd6227a150fdb56e7bb734976ef6e53a2c1cb334 Mon Sep 17 00:00:00 2001
+From: Stephan Mueller <smueller@chronox.de>
+Date: Thu, 14 Sep 2017 17:10:28 +0200
+Subject: crypto: drbg - fix freeing of resources
+
+From: Stephan Mueller <smueller@chronox.de>
+
+commit bd6227a150fdb56e7bb734976ef6e53a2c1cb334 upstream.
+
+During the change to use aligned buffers, the deallocation code path was
+not updated correctly. The current code tries to free the aligned buffer
+pointer and not the original buffer pointer as it is supposed to.
+
+Thus, the code is updated to free the original buffer pointer and set
+the aligned buffer pointer that is used throughout the code to NULL.
+
+Fixes: 3cfc3b9721123 ("crypto: drbg - use aligned buffers")
+CC: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Stephan Mueller <smueller@chronox.de>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ crypto/drbg.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/crypto/drbg.c
++++ b/crypto/drbg.c
+@@ -1133,10 +1133,10 @@ static inline void drbg_dealloc_state(st
+ {
+ if (!drbg)
+ return;
+- kzfree(drbg->V);
+- drbg->Vbuf = NULL;
+- kzfree(drbg->C);
+- drbg->Cbuf = NULL;
++ kzfree(drbg->Vbuf);
++ drbg->V = NULL;
++ kzfree(drbg->Cbuf);
++ drbg->C = NULL;
+ kzfree(drbg->scratchpadbuf);
+ drbg->scratchpadbuf = NULL;
+ drbg->reseed_ctr = 0;
--- /dev/null
+From 56136631573baa537a15e0012055ffe8cfec1a33 Mon Sep 17 00:00:00 2001
+From: LEROY Christophe <christophe.leroy@c-s.fr>
+Date: Tue, 12 Sep 2017 11:03:39 +0200
+Subject: crypto: talitos - Don't provide setkey for non hmac hashing algs.
+
+From: LEROY Christophe <christophe.leroy@c-s.fr>
+
+commit 56136631573baa537a15e0012055ffe8cfec1a33 upstream.
+
+Today, md5sum fails with error -ENOKEY because a setkey
+function is set for non hmac hashing algs, see strace output below:
+
+mmap(NULL, 378880, PROT_READ, MAP_SHARED, 6, 0) = 0x77f50000
+accept(3, 0, NULL) = 7
+vmsplice(5, [{"bin/\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 378880}], 1, SPLICE_F_MORE|SPLICE_F_GIFT) = 262144
+splice(4, NULL, 7, NULL, 262144, SPLICE_F_MORE) = -1 ENOKEY (Required key not available)
+write(2, "Generation of hash for file kcap"..., 50) = 50
+munmap(0x77f50000, 378880) = 0
+
+This patch ensures that setkey() function is set only
+for hmac hashing.
+
+Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/talitos.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/crypto/talitos.c
++++ b/drivers/crypto/talitos.c
+@@ -3057,7 +3057,8 @@ static struct talitos_crypto_alg *talito
+ t_alg->algt.alg.hash.final = ahash_final;
+ t_alg->algt.alg.hash.finup = ahash_finup;
+ t_alg->algt.alg.hash.digest = ahash_digest;
+- t_alg->algt.alg.hash.setkey = ahash_setkey;
++ if (!strncmp(alg->cra_name, "hmac", 4))
++ t_alg->algt.alg.hash.setkey = ahash_setkey;
+ t_alg->algt.alg.hash.import = ahash_import;
+ t_alg->algt.alg.hash.export = ahash_export;
+
--- /dev/null
+From 886a27c0fc8a34633aadb0986dba11d8c150ae2e Mon Sep 17 00:00:00 2001
+From: LEROY Christophe <christophe.leroy@c-s.fr>
+Date: Wed, 13 Sep 2017 12:44:57 +0200
+Subject: crypto: talitos - fix hashing
+
+From: LEROY Christophe <christophe.leroy@c-s.fr>
+
+commit 886a27c0fc8a34633aadb0986dba11d8c150ae2e upstream.
+
+md5sum on some files gives wrong result
+
+Exemple:
+
+With the md5sum from libkcapi:
+c15115c05bad51113f81bdaee735dd09 test
+
+With the original md5sum:
+bbdf41d80ba7e8b2b7be3a0772be76cb test
+
+This patch fixes this issue
+
+Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/talitos.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/crypto/talitos.c
++++ b/drivers/crypto/talitos.c
+@@ -1769,7 +1769,7 @@ static int common_nonsnoop_hash(struct t
+
+ sg_count = edesc->src_nents ?: 1;
+ if (is_sec1 && sg_count > 1)
+- sg_copy_to_buffer(areq->src, sg_count, edesc->buf, length);
++ sg_copy_to_buffer(req_ctx->psrc, sg_count, edesc->buf, length);
+ else
+ sg_count = dma_map_sg(dev, req_ctx->psrc, sg_count,
+ DMA_TO_DEVICE);
--- /dev/null
+From afd62fa26343be6445479e75de9f07092a061459 Mon Sep 17 00:00:00 2001
+From: LEROY Christophe <christophe.leroy@c-s.fr>
+Date: Wed, 13 Sep 2017 12:44:51 +0200
+Subject: crypto: talitos - fix sha224
+
+From: LEROY Christophe <christophe.leroy@c-s.fr>
+
+commit afd62fa26343be6445479e75de9f07092a061459 upstream.
+
+Kernel crypto tests report the following error at startup
+
+[ 2.752626] alg: hash: Test 4 failed for sha224-talitos
+[ 2.757907] 00000000: 30 e2 86 e2 e7 8a dd 0d d7 eb 9f d5 83 fe f1 b0
+00000010: 2d 5a 6c a5 f9 55 ea fd 0e 72 05 22
+
+This patch fixes it
+
+Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/talitos.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/crypto/talitos.c
++++ b/drivers/crypto/talitos.c
+@@ -1756,9 +1756,9 @@ static int common_nonsnoop_hash(struct t
+ req_ctx->swinit = 0;
+ } else {
+ desc->ptr[1] = zero_entry;
+- /* Indicate next op is not the first. */
+- req_ctx->first = 0;
+ }
++ /* Indicate next op is not the first. */
++ req_ctx->first = 0;
+
+ /* HMAC key */
+ if (ctx->keylen)
--- /dev/null
+From 820608548737e315c6f93e3099b4e65bde062334 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Fri, 15 Sep 2017 11:55:27 -0400
+Subject: drm/radeon: disable hard reset in hibernate for APUs
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 820608548737e315c6f93e3099b4e65bde062334 upstream.
+
+Fixes a hibernation regression on APUs.
+
+Bug: https://bugzilla.kernel.org/show_bug.cgi?id=191571
+Fixes: 274ad65c9d02bdc (drm/radeon: hard reset r600 and newer GPU when hibernating.)
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/radeon_device.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/radeon/radeon_device.c
++++ b/drivers/gpu/drm/radeon/radeon_device.c
+@@ -1674,7 +1674,7 @@ int radeon_suspend_kms(struct drm_device
+ radeon_agp_suspend(rdev);
+
+ pci_save_state(dev->pdev);
+- if (freeze && rdev->family >= CHIP_CEDAR) {
++ if (freeze && rdev->family >= CHIP_CEDAR && !(rdev->flags & RADEON_IS_IGP)) {
+ rdev->asic->asic_reset(rdev, true);
+ pci_restore_state(dev->pdev);
+ } else if (suspend) {
--- /dev/null
+From paulus@ozlabs.org Mon Oct 2 11:15:01 2017
+From: Paul Mackerras <paulus@ozlabs.org>
+Date: Tue, 12 Sep 2017 15:41:49 +1000
+Subject: KVM: PPC: Book3S: Fix race and leak in kvm_vm_ioctl_create_spapr_tce()
+To: stable@vger.kernel.org
+Message-ID: <20170912054149.3vrf3mcbtp4jodr6@oak.ozlabs.ibm.com>
+Content-Disposition: inline
+
+From: Paul Mackerras <paulus@ozlabs.org>
+
+commit 47c5310a8dbe7c2cb9f0083daa43ceed76c257fa upstream, with part
+of commit edd03602d97236e8fea13cd76886c576186aa307 folded in.
+
+Nixiaoming pointed out that there is a memory leak in
+kvm_vm_ioctl_create_spapr_tce() if the call to anon_inode_getfd()
+fails; the memory allocated for the kvmppc_spapr_tce_table struct
+is not freed, and nor are the pages allocated for the iommu
+tables. In addition, we have already incremented the process's
+count of locked memory pages, and this doesn't get restored on
+error.
+
+David Hildenbrand pointed out that there is a race in that the
+function checks early on that there is not already an entry in the
+stt->iommu_tables list with the same LIOBN, but an entry with the
+same LIOBN could get added between then and when the new entry is
+added to the list.
+
+This fixes all three problems. To simplify things, we now call
+anon_inode_getfd() before placing the new entry in the list. The
+check for an existing entry is done while holding the kvm->lock
+mutex, immediately before adding the new entry to the list.
+Finally, on failure we now call kvmppc_account_memlimit to
+decrement the process's count of locked memory pages.
+
+[paulus@ozlabs.org - folded in that part of edd03602d972 ("KVM:
+ PPC: Book3S HV: Protect updates to spapr_tce_tables list", 2017-08-28)
+ which restructured the code that 47c5310a8dbe modified, to avoid
+ a build failure caused by the absence of put_unused_fd().]
+
+Fixes: 54738c097163 ("KVM: PPC: Accelerate H_PUT_TCE by implementing it in real mode")
+Fixes: f8626985c7c2 ("KVM: PPC: Account TCE-containing pages in locked_vm")
+Reported-by: Nixiaoming <nixiaoming@huawei.com>
+Reported-by: David Hildenbrand <david@redhat.com>
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/book3s_64_vio.c | 56 ++++++++++++++++++++++-----------------
+ 1 file changed, 32 insertions(+), 24 deletions(-)
+
+--- a/arch/powerpc/kvm/book3s_64_vio.c
++++ b/arch/powerpc/kvm/book3s_64_vio.c
+@@ -150,6 +150,7 @@ long kvm_vm_ioctl_create_spapr_tce(struc
+ struct kvm_create_spapr_tce_64 *args)
+ {
+ struct kvmppc_spapr_tce_table *stt = NULL;
++ struct kvmppc_spapr_tce_table *siter;
+ unsigned long npages, size;
+ int ret = -ENOMEM;
+ int i;
+@@ -157,24 +158,16 @@ long kvm_vm_ioctl_create_spapr_tce(struc
+ if (!args->size)
+ return -EINVAL;
+
+- /* Check this LIOBN hasn't been previously allocated */
+- list_for_each_entry(stt, &kvm->arch.spapr_tce_tables, list) {
+- if (stt->liobn == args->liobn)
+- return -EBUSY;
+- }
+-
+ size = args->size;
+ npages = kvmppc_tce_pages(size);
+ ret = kvmppc_account_memlimit(kvmppc_stt_pages(npages), true);
+- if (ret) {
+- stt = NULL;
+- goto fail;
+- }
++ if (ret)
++ return ret;
+
+ stt = kzalloc(sizeof(*stt) + npages * sizeof(struct page *),
+ GFP_KERNEL);
+ if (!stt)
+- goto fail;
++ goto fail_acct;
+
+ stt->liobn = args->liobn;
+ stt->page_shift = args->page_shift;
+@@ -188,24 +181,39 @@ long kvm_vm_ioctl_create_spapr_tce(struc
+ goto fail;
+ }
+
+- kvm_get_kvm(kvm);
+-
+ mutex_lock(&kvm->lock);
+- list_add_rcu(&stt->list, &kvm->arch.spapr_tce_tables);
+
+- mutex_unlock(&kvm->lock);
++ /* Check this LIOBN hasn't been previously allocated */
++ ret = 0;
++ list_for_each_entry(siter, &kvm->arch.spapr_tce_tables, list) {
++ if (siter->liobn == args->liobn) {
++ ret = -EBUSY;
++ break;
++ }
++ }
++
++ if (!ret)
++ ret = anon_inode_getfd("kvm-spapr-tce", &kvm_spapr_tce_fops,
++ stt, O_RDWR | O_CLOEXEC);
++
++ if (ret >= 0) {
++ list_add_rcu(&stt->list, &kvm->arch.spapr_tce_tables);
++ kvm_get_kvm(kvm);
++ }
+
+- return anon_inode_getfd("kvm-spapr-tce", &kvm_spapr_tce_fops,
+- stt, O_RDWR | O_CLOEXEC);
++ mutex_unlock(&kvm->lock);
+
+-fail:
+- if (stt) {
+- for (i = 0; i < npages; i++)
+- if (stt->pages[i])
+- __free_page(stt->pages[i]);
++ if (ret >= 0)
++ return ret;
+
+- kfree(stt);
+- }
++ fail:
++ for (i = 0; i < npages; i++)
++ if (stt->pages[i])
++ __free_page(stt->pages[i]);
++
++ kfree(stt);
++ fail_acct:
++ kvmppc_account_memlimit(kvmppc_stt_pages(npages), false);
+ return ret;
+ }
+
--- /dev/null
+From paulus@ozlabs.org Mon Oct 2 11:15:17 2017
+From: Paul Mackerras <paulus@ozlabs.org>
+Date: Tue, 12 Sep 2017 15:42:38 +1000
+Subject: KVM: PPC: Book3S HV: Protect updates to spapr_tce_tables list
+To: stable@vger.kernel.org
+Message-ID: <20170912054238.ori4majx46kxpz5m@oak.ozlabs.ibm.com>
+Content-Disposition: inline
+
+From: Paul Mackerras <paulus@ozlabs.org>
+
+commit edd03602d97236e8fea13cd76886c576186aa307 upstream.
+
+Al Viro pointed out that while one thread of a process is executing
+in kvm_vm_ioctl_create_spapr_tce(), another thread could guess the
+file descriptor returned by anon_inode_getfd() and close() it before
+the first thread has added it to the kvm->arch.spapr_tce_tables list.
+That highlights a more general problem: there is no mutual exclusion
+between writers to the spapr_tce_tables list, leading to the
+possibility of the list becoming corrupted, which could cause a
+host kernel crash.
+
+To fix the mutual exclusion problem, we add a mutex_lock/unlock
+pair around the list_del_rce in kvm_spapr_tce_release().
+
+If another thread does guess the file descriptor returned by the
+anon_inode_getfd() call in kvm_vm_ioctl_create_spapr_tce() and closes
+it, its call to kvm_spapr_tce_release() will not do any harm because
+it will have to wait until the first thread has released kvm->lock.
+
+The other things that the second thread could do with the guessed
+file descriptor are to mmap it or to pass it as a parameter to a
+KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE ioctl on a KVM device fd. An mmap
+call won't cause any harm because kvm_spapr_tce_mmap() and
+kvm_spapr_tce_fault() don't access the spapr_tce_tables list or
+the kvmppc_spapr_tce_table.list field, and the fields that they do use
+have been properly initialized by the time of the anon_inode_getfd()
+call.
+
+The KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE ioctl calls
+kvm_spapr_tce_attach_iommu_group(), which scans the spapr_tce_tables
+list looking for the kvmppc_spapr_tce_table struct corresponding to
+the fd given as the parameter. Either it will find the new entry
+or it won't; if it doesn't, it just returns an error, and if it
+does, it will function normally. So, in each case there is no
+harmful effect.
+
+[paulus@ozlabs.org - moved parts of the upstream patch into the backport
+ of 47c5310a8dbe, adjusted this commit message accordingly.]
+
+Fixes: 366baf28ee3f ("KVM: PPC: Use RCU for arch.spapr_tce_tables")
+Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/book3s_64_vio.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/powerpc/kvm/book3s_64_vio.c
++++ b/arch/powerpc/kvm/book3s_64_vio.c
+@@ -129,8 +129,11 @@ static int kvm_spapr_tce_mmap(struct fil
+ static int kvm_spapr_tce_release(struct inode *inode, struct file *filp)
+ {
+ struct kvmppc_spapr_tce_table *stt = filp->private_data;
++ struct kvm *kvm = stt->kvm;
+
++ mutex_lock(&kvm->lock);
+ list_del_rcu(&stt->list);
++ mutex_unlock(&kvm->lock);
+
+ kvm_put_kvm(stt->kvm);
+
--- /dev/null
+From 3664847d95e60a9a943858b7800f8484669740fc Mon Sep 17 00:00:00 2001
+From: Shaohua Li <shli@fb.com>
+Date: Fri, 25 Aug 2017 10:40:02 -0700
+Subject: md/raid5: fix a race condition in stripe batch
+
+From: Shaohua Li <shli@fb.com>
+
+commit 3664847d95e60a9a943858b7800f8484669740fc upstream.
+
+We have a race condition in below scenario, say have 3 continuous stripes, sh1,
+sh2 and sh3, sh1 is the stripe_head of sh2 and sh3:
+
+CPU1 CPU2 CPU3
+handle_stripe(sh3)
+ stripe_add_to_batch_list(sh3)
+ -> lock(sh2, sh3)
+ -> lock batch_lock(sh1)
+ -> add sh3 to batch_list of sh1
+ -> unlock batch_lock(sh1)
+ clear_batch_ready(sh1)
+ -> lock(sh1) and batch_lock(sh1)
+ -> clear STRIPE_BATCH_READY for all stripes in batch_list
+ -> unlock(sh1) and batch_lock(sh1)
+->clear_batch_ready(sh3)
+-->test_and_clear_bit(STRIPE_BATCH_READY, sh3)
+--->return 0 as sh->batch == NULL
+ -> sh3->batch_head = sh1
+ -> unlock (sh2, sh3)
+
+In CPU1, handle_stripe will continue handle sh3 even it's in batch stripe list
+of sh1. By moving sh3->batch_head assignment in to batch_lock, we make it
+impossible to clear STRIPE_BATCH_READY before batch_head is set.
+
+Thanks Stephane for helping debug this tricky issue.
+
+Reported-and-tested-by: Stephane Thiell <sthiell@stanford.edu>
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid5.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -829,6 +829,14 @@ static void stripe_add_to_batch_list(str
+ spin_unlock(&head->batch_head->batch_lock);
+ goto unlock_out;
+ }
++ /*
++ * We must assign batch_head of this stripe within the
++ * batch_lock, otherwise clear_batch_ready of batch head
++ * stripe could clear BATCH_READY bit of this stripe and
++ * this stripe->batch_head doesn't get assigned, which
++ * could confuse clear_batch_ready for this stripe
++ */
++ sh->batch_head = head->batch_head;
+
+ /*
+ * at this point, head's BATCH_READY could be cleared, but we
+@@ -836,8 +844,6 @@ static void stripe_add_to_batch_list(str
+ */
+ list_add(&sh->batch_list, &head->batch_list);
+ spin_unlock(&head->batch_head->batch_lock);
+-
+- sh->batch_head = head->batch_head;
+ } else {
+ head->batch_head = head;
+ sh->batch_head = head->batch_head;
--- /dev/null
+From 184a09eb9a2fe425e49c9538f1604b05ed33cfef Mon Sep 17 00:00:00 2001
+From: Dennis Yang <dennisyang@qnap.com>
+Date: Wed, 6 Sep 2017 11:02:35 +0800
+Subject: md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list
+
+From: Dennis Yang <dennisyang@qnap.com>
+
+commit 184a09eb9a2fe425e49c9538f1604b05ed33cfef upstream.
+
+In release_stripe_plug(), if a stripe_head has its STRIPE_ON_UNPLUG_LIST
+set, it indicates that this stripe_head is already in the raid5_plug_cb
+list and release_stripe() would be called instead to drop a reference
+count. Otherwise, the STRIPE_ON_UNPLUG_LIST bit would be set for this
+stripe_head and it will get queued into the raid5_plug_cb list.
+
+Since break_stripe_batch_list() did not preserve STRIPE_ON_UNPLUG_LIST,
+A stripe could be re-added to plug list while it is still on that list
+in the following situation. If stripe_head A is added to another
+stripe_head B's batch list, in this case A will have its
+batch_head != NULL and be added into the plug list. After that,
+stripe_head B gets handled and called break_stripe_batch_list() to
+reset all the batched stripe_head(including A which is still on
+the plug list)'s state and reset their batch_head to NULL.
+Before the plug list gets processed, if there is another write request
+comes in and get stripe_head A, A will have its batch_head == NULL
+(cleared by calling break_stripe_batch_list() on B) and be added to
+plug list once again.
+
+Signed-off-by: Dennis Yang <dennisyang@qnap.com>
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid5.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -4283,7 +4283,8 @@ static void break_stripe_batch_list(stru
+
+ set_mask_bits(&sh->state, ~(STRIPE_EXPAND_SYNC_FLAGS |
+ (1 << STRIPE_PREREAD_ACTIVE) |
+- (1 << STRIPE_DEGRADED)),
++ (1 << STRIPE_DEGRADED) |
++ (1 << STRIPE_ON_UNPLUG_LIST)),
+ head_sh->state & (1 << STRIPE_INSYNC));
+
+ sh->check_state = head_sh->check_state;
--- /dev/null
+From c88f0e6b06f4092995688211a631bb436125d77b Mon Sep 17 00:00:00 2001
+From: Xin Long <lucien.xin@gmail.com>
+Date: Sun, 27 Aug 2017 20:25:26 +0800
+Subject: scsi: scsi_transport_iscsi: fix the issue that iscsi_if_rx doesn't parse nlmsg properly
+
+From: Xin Long <lucien.xin@gmail.com>
+
+commit c88f0e6b06f4092995688211a631bb436125d77b upstream.
+
+ChunYu found a kernel crash by syzkaller:
+
+[ 651.617875] kasan: CONFIG_KASAN_INLINE enabled
+[ 651.618217] kasan: GPF could be caused by NULL-ptr deref or user memory access
+[ 651.618731] general protection fault: 0000 [#1] SMP KASAN
+[ 651.621543] CPU: 1 PID: 9539 Comm: scsi Not tainted 4.11.0.cov #32
+[ 651.621938] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
+[ 651.622309] task: ffff880117780000 task.stack: ffff8800a3188000
+[ 651.622762] RIP: 0010:skb_release_data+0x26c/0x590
+[...]
+[ 651.627260] Call Trace:
+[ 651.629156] skb_release_all+0x4f/0x60
+[ 651.629450] consume_skb+0x1a5/0x600
+[ 651.630705] netlink_unicast+0x505/0x720
+[ 651.632345] netlink_sendmsg+0xab2/0xe70
+[ 651.633704] sock_sendmsg+0xcf/0x110
+[ 651.633942] ___sys_sendmsg+0x833/0x980
+[ 651.637117] __sys_sendmsg+0xf3/0x240
+[ 651.638820] SyS_sendmsg+0x32/0x50
+[ 651.639048] entry_SYSCALL_64_fastpath+0x1f/0xc2
+
+It's caused by skb_shared_info at the end of sk_buff was overwritten by
+ISCSI_KEVENT_IF_ERROR when parsing nlmsg info from skb in iscsi_if_rx.
+
+During the loop if skb->len == nlh->nlmsg_len and both are sizeof(*nlh),
+ev = nlmsg_data(nlh) will acutally get skb_shinfo(SKB) instead and set a
+new value to skb_shinfo(SKB)->nr_frags by ev->type.
+
+This patch is to fix it by checking nlh->nlmsg_len properly there to
+avoid over accessing sk_buff.
+
+Reported-by: ChunYu Wang <chunwang@redhat.com>
+Signed-off-by: Xin Long <lucien.xin@gmail.com>
+Acked-by: Chris Leech <cleech@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/scsi_transport_iscsi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/scsi/scsi_transport_iscsi.c
++++ b/drivers/scsi/scsi_transport_iscsi.c
+@@ -3696,7 +3696,7 @@ iscsi_if_rx(struct sk_buff *skb)
+ uint32_t group;
+
+ nlh = nlmsg_hdr(skb);
+- if (nlh->nlmsg_len < sizeof(*nlh) ||
++ if (nlh->nlmsg_len < sizeof(*nlh) + sizeof(*ev) ||
+ skb->len < nlh->nlmsg_len) {
+ break;
+ }
mac80211_hwsim-use-proper-tx-power.patch
mac80211-flush-hw_roc_start-work-before-cancelling-the-roc.patch
genirq-make-sparse_irq_lock-protect-what-it-should-protect.patch
+kvm-ppc-book3s-fix-race-and-leak-in-kvm_vm_ioctl_create_spapr_tce.patch
+kvm-ppc-book3s-hv-protect-updates-to-spapr_tce_tables-list.patch
+tracing-fix-trace_pipe-behavior-for-instance-traces.patch
+tracing-erase-irqsoff-trace-with-empty-write.patch
+md-raid5-fix-a-race-condition-in-stripe-batch.patch
+md-raid5-preserve-stripe_on_unplug_list-in-break_stripe_batch_list.patch
+scsi-scsi_transport_iscsi-fix-the-issue-that-iscsi_if_rx-doesn-t-parse-nlmsg-properly.patch
+drm-radeon-disable-hard-reset-in-hibernate-for-apus.patch
+crypto-drbg-fix-freeing-of-resources.patch
+crypto-talitos-don-t-provide-setkey-for-non-hmac-hashing-algs.patch
+crypto-talitos-fix-sha224.patch
+crypto-talitos-fix-hashing.patch
--- /dev/null
+From 8dd33bcb7050dd6f8c1432732f930932c9d3a33e Mon Sep 17 00:00:00 2001
+From: Bo Yan <byan@nvidia.com>
+Date: Mon, 18 Sep 2017 10:03:35 -0700
+Subject: tracing: Erase irqsoff trace with empty write
+
+From: Bo Yan <byan@nvidia.com>
+
+commit 8dd33bcb7050dd6f8c1432732f930932c9d3a33e upstream.
+
+One convenient way to erase trace is "echo > trace". However, this
+is currently broken if the current tracer is irqsoff tracer. This
+is because irqsoff tracer use max_buffer as the default trace
+buffer.
+
+Set the max_buffer as the one to be cleared when it's the trace
+buffer currently in use.
+
+Link: http://lkml.kernel.org/r/1505754215-29411-1-git-send-email-byan@nvidia.com
+
+Cc: <mingo@redhat.com>
+Fixes: 4acd4d00f ("tracing: give easy way to clear trace buffer")
+Signed-off-by: Bo Yan <byan@nvidia.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -3569,11 +3569,17 @@ static int tracing_open(struct inode *in
+ /* If this file was open for write, then erase contents */
+ if ((file->f_mode & FMODE_WRITE) && (file->f_flags & O_TRUNC)) {
+ int cpu = tracing_get_cpu(inode);
++ struct trace_buffer *trace_buf = &tr->trace_buffer;
++
++#ifdef CONFIG_TRACER_MAX_TRACE
++ if (tr->current_trace->print_max)
++ trace_buf = &tr->max_buffer;
++#endif
+
+ if (cpu == RING_BUFFER_ALL_CPUS)
+- tracing_reset_online_cpus(&tr->trace_buffer);
++ tracing_reset_online_cpus(trace_buf);
+ else
+- tracing_reset(&tr->trace_buffer, cpu);
++ tracing_reset(trace_buf, cpu);
+ }
+
+ if (file->f_mode & FMODE_READ) {
--- /dev/null
+From 75df6e688ccd517e339a7c422ef7ad73045b18a2 Mon Sep 17 00:00:00 2001
+From: Tahsin Erdogan <tahsin@google.com>
+Date: Sun, 17 Sep 2017 03:23:48 -0700
+Subject: tracing: Fix trace_pipe behavior for instance traces
+
+From: Tahsin Erdogan <tahsin@google.com>
+
+commit 75df6e688ccd517e339a7c422ef7ad73045b18a2 upstream.
+
+When reading data from trace_pipe, tracing_wait_pipe() performs a
+check to see if tracing has been turned off after some data was read.
+Currently, this check always looks at global trace state, but it
+should be checking the trace instance where trace_pipe is located at.
+
+Because of this bug, cat instances/i1/trace_pipe in the following
+script will immediately exit instead of waiting for data:
+
+cd /sys/kernel/debug/tracing
+echo 0 > tracing_on
+mkdir -p instances/i1
+echo 1 > instances/i1/tracing_on
+echo 1 > instances/i1/events/sched/sched_process_exec/enable
+cat instances/i1/trace_pipe
+
+Link: http://lkml.kernel.org/r/20170917102348.1615-1-tahsin@google.com
+
+Fixes: 10246fa35d4f ("tracing: give easy way to clear trace buffer")
+Signed-off-by: Tahsin Erdogan <tahsin@google.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -5128,7 +5128,7 @@ static int tracing_wait_pipe(struct file
+ *
+ * iter->pos will be 0 if we haven't read anything.
+ */
+- if (!tracing_is_on() && iter->pos)
++ if (!tracer_tracing_is_on(iter->tr) && iter->pos)
+ break;
+
+ mutex_unlock(&iter->mutex);
projects / thirdparty / kernel / stable-queue.git / commitdiff
