--- /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
+@@ -2770,7 +2770,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 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
+@@ -1749,9 +1749,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 paulus@ozlabs.org Mon Oct 2 11:13:24 2017
+From: Paul Mackerras <paulus@ozlabs.org>
+Date: Tue, 12 Sep 2017 15:54:14 +1000
+Subject: KVM: PPC: Book3S: Fix race and leak in kvm_vm_ioctl_create_spapr_tce()
+To: stable@vger.kernel.org
+Message-ID: <20170912055414.qlxo5qyflbnearna@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.
+
+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 both 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.
+
+[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().
+ Also removed the locked memory accounting, since it doesn't exist
+ in this version, and adjusted the commit message.]
+
+Fixes: 54738c097163 ("KVM: PPC: Accelerate H_PUT_TCE by implementing it in real mode")
+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 | 46 ++++++++++++++++++++++-----------------
+ 1 file changed, 27 insertions(+), 19 deletions(-)
+
+--- a/arch/powerpc/kvm/book3s_64_vio.c
++++ b/arch/powerpc/kvm/book3s_64_vio.c
+@@ -101,22 +101,17 @@ long kvm_vm_ioctl_create_spapr_tce(struc
+ struct kvm_create_spapr_tce *args)
+ {
+ struct kvmppc_spapr_tce_table *stt = NULL;
++ struct kvmppc_spapr_tce_table *siter;
+ long npages;
+ int ret = -ENOMEM;
+ int i;
+
+- /* 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;
+- }
+-
+ npages = kvmppc_stt_npages(args->window_size);
+
+ stt = kzalloc(sizeof(*stt) + npages * sizeof(struct page *),
+ GFP_KERNEL);
+ if (!stt)
+- goto fail;
++ return ret;
+
+ stt->liobn = args->liobn;
+ stt->window_size = args->window_size;
+@@ -128,23 +123,36 @@ long kvm_vm_ioctl_create_spapr_tce(struc
+ goto fail;
+ }
+
+- kvm_get_kvm(kvm);
+-
+ mutex_lock(&kvm->lock);
+- list_add(&stt->list, &kvm->arch.spapr_tce_tables);
++
++ /* 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(&stt->list, &kvm->arch.spapr_tce_tables);
++ kvm_get_kvm(kvm);
++ }
+
+ mutex_unlock(&kvm->lock);
+
+- return anon_inode_getfd("kvm-spapr-tce", &kvm_spapr_tce_fops,
+- stt, O_RDWR | O_CLOEXEC);
++ if (ret >= 0)
++ return ret;
+
+-fail:
+- if (stt) {
+- for (i = 0; i < npages; i++)
+- if (stt->pages[i])
+- __free_page(stt->pages[i]);
++ fail:
++ for (i = 0; i < npages; i++)
++ if (stt->pages[i])
++ __free_page(stt->pages[i]);
+
+- kfree(stt);
+- }
++ kfree(stt);
+ return ret;
+ }
--- /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
+@@ -818,6 +818,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
+@@ -825,8 +833,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
+@@ -4264,7 +4264,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
+@@ -3697,7 +3697,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;
+ }
cifs-release-auth_key.response-for-reconnect.patch
mac80211-flush-hw_roc_start-work-before-cancelling-the-roc.patch
+kvm-ppc-book3s-fix-race-and-leak-in-kvm_vm_ioctl_create_spapr_tce.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
+crypto-talitos-don-t-provide-setkey-for-non-hmac-hashing-algs.patch
+crypto-talitos-fix-sha224.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
+@@ -3226,11 +3226,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
+@@ -4701,7 +4701,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
