4.4.90-stable review

This is the start of the stable review cycle for the 4.4.90 release. There are 41 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Thu Oct 5 11:42:00 UTC 2017. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.90-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 4.4.90-rc1

Stefano Stabellini <[email protected]>
swiotlb-xen: implement xen_swiotlb_dma_mmap callback

Vladis Dronov <[email protected]>
video: fbdev: aty: do not leak uninitialized padding in clk to userspace

Paolo Bonzini <[email protected]>
KVM: VMX: use cmpxchg64

Robert Jarzmik <[email protected]>
ARM: pxa: fix the number of DMA requestor lines

Robert Jarzmik <[email protected]>
ARM: pxa: add the number of DMA requestor lines

Robert Jarzmik <[email protected]>
dmaengine: mmp-pdma: add number of requestors

Frederic Barrat <[email protected]>
cxl: Fix driver use count

Haozhong Zhang <[email protected]>
KVM: VMX: remove WARN_ON_ONCE in kvm_vcpu_trigger_posted_interrupt

Haozhong Zhang <[email protected]>
KVM: VMX: do not change SN bit in vmx_update_pi_irte()

Myungho Jung <[email protected]>
timer/sysclt: Restrict timer migration sysctl values to 0 and 1

Andreas Gruenbacher <[email protected]>
gfs2: Fix debugfs glocks dump

Eric Biggers <[email protected]>
x86/fpu: Don't let userspace set bogus xcomp_bv

satoru takeuchi <[email protected]>
btrfs: prevent to set invalid default subvolid

Naohiro Aota <[email protected]>
btrfs: propagate error to btrfs_cmp_data_prepare caller

Naohiro Aota <[email protected]>
btrfs: fix NULL pointer dereference from free_reloc_roots()

Nicolai Stange <[email protected]>
PCI: Fix race condition with driver_override

Jim Mattson <[email protected]>
kvm: nVMX: Don't allow L2 to access the hardware CR8

Jan H. Schönherr <[email protected]>
KVM: VMX: Do not BUG() on out-of-bounds guest IRQ

Will Deacon <[email protected]>
arm64: fault: Route pte translation faults via do_translation_fault

Marc Zyngier <[email protected]>
arm64: Make sure SPsel is always set

Oleg Nesterov <[email protected]>
seccomp: fix the usage of get/put_seccomp_filter() in seccomp_get_filter()

Christoph Hellwig <[email protected]>
bsg-lib: don't free job in bsg_prepare_job

Vladis Dronov <[email protected]>
nl80211: check for the required netlink attributes presence

Andreas Gruenbacher <[email protected]>
vfs: Return -ENXIO for negative SEEK_HOLE / SEEK_DATA offsets

Steve French <[email protected]>
SMB3: Don't ignore O_SYNC/O_DSYNC and O_DIRECT flags

Steve French <[email protected]>
SMB: Validate negotiate (to protect against downgrade) even if signing off

Steve French <[email protected]>
Fix SMB3.1.1 guest authentication to Samba

Tyrel Datwyler <[email protected]>
powerpc/pseries: Fix parent_dn reference leak in add_dt_node()

Eric Biggers <[email protected]>
KEYS: prevent KEYCTL_READ on negative key

Eric Biggers <[email protected]>
KEYS: prevent creating a different user's keyrings

Eric Biggers <[email protected]>
KEYS: fix writing past end of user-supplied buffer in keyring_read()

LEROY Christophe <[email protected]>
crypto: talitos - fix sha224

LEROY Christophe <[email protected]>
crypto: talitos - Don't provide setkey for non hmac hashing algs.

Xin Long <[email protected]>
scsi: scsi_transport_iscsi: fix the issue that iscsi_if_rx doesn't parse nlmsg properly

Dennis Yang <[email protected]>
md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list

Shaohua Li <[email protected]>
md/raid5: fix a race condition in stripe batch

Bo Yan <[email protected]>
tracing: Erase irqsoff trace with empty write

Tahsin Erdogan <[email protected]>
tracing: Fix trace_pipe behavior for instance traces

Paul Mackerras <[email protected]>
KVM: PPC: Book3S: Fix race and leak in kvm_vm_ioctl_create_spapr_tce()

Avraham Stern <[email protected]>
mac80211: flush hw_roc_start work before cancelling the ROC

Shu Wang <[email protected]>
cifs: release auth_key.response for reconnect.

-------------

Diffstat:

 Makefile                                  |  4 +-
 arch/arm/boot/dts/pxa27x.dtsi             |  1 +
 arch/arm/boot/dts/pxa3xx.dtsi             |  1 +
 arch/arm/mach-pxa/devices.c               |  4 +-
 arch/arm/mach-pxa/pxa25x.c                |  2 +-
 arch/arm/mach-pxa/pxa27x.c                |  2 +-
 arch/arm/mach-pxa/pxa3xx.c                |  2 +-
 arch/arm/plat-pxa/include/plat/dma.h      |  2 +-
 arch/arm/xen/mm.c                         |  1 +
 arch/arm64/kernel/head.S                  |  1 +
 arch/arm64/mm/fault.c                     |  2 +-
 arch/powerpc/kvm/book3s_64_vio.c          | 46 +++++++++++++---------
 arch/powerpc/platforms/pseries/mobility.c |  4 +-
 arch/x86/kernel/fpu/regset.c              | 11 ++++++
 arch/x86/kernel/fpu/signal.c              |  4 +-
 arch/x86/kvm/vmx.c                        | 65 +++++++++++++++++++------------
 block/bsg-lib.c                           |  1 -
 drivers/crypto/talitos.c                  |  7 ++--
 drivers/md/raid5.c                        | 13 +++++--
 drivers/misc/cxl/api.c                    |  4 ++
 drivers/misc/cxl/file.c                   |  8 +++-
 drivers/pci/pci-sysfs.c                   | 11 +++++-
 drivers/scsi/scsi_transport_iscsi.c       |  2 +-
 drivers/video/fbdev/aty/atyfb_base.c      |  2 +-
 drivers/xen/swiotlb-xen.c                 | 19 +++++++++
 fs/btrfs/ioctl.c                          |  6 ++-
 fs/btrfs/relocation.c                     |  2 +-
 fs/cifs/connect.c                         |  8 ++++
 fs/cifs/file.c                            |  7 ++++
 fs/cifs/smb2pdu.c                         | 19 ++++++---
 fs/gfs2/glock.c                           | 21 +++++-----
 fs/read_write.c                           |  4 +-
 include/linux/key.h                       |  2 +
 include/linux/platform_data/mmp_dma.h     |  1 +
 include/xen/swiotlb-xen.h                 |  5 +++
 kernel/seccomp.c                          | 23 +++++++----
 kernel/sysctl.c                           |  2 +
 kernel/time/timer.c                       |  2 +-
 kernel/trace/trace.c                      | 12 ++++--
 net/mac80211/offchannel.c                 |  2 +
 net/wireless/nl80211.c                    |  3 ++
 security/keys/internal.h                  |  2 +-
 security/keys/key.c                       |  2 +
 security/keys/keyctl.c                    |  5 +++
 security/keys/keyring.c                   | 37 +++++++++---------
 security/keys/process_keys.c              |  8 +++-
 46 files changed, 272 insertions(+), 120 deletions(-)

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Shu Wang <[email protected]>

commit f5c4ba816315d3b813af16f5571f86c8d4e897bd upstream.

There is a race that cause cifs reconnect in cifs_mount,
- cifs_mount
- cifs_get_tcp_session
- [ start thread cifs_demultiplex_thread
- cifs_read_from_socket: -ECONNABORTED
- DELAY_WORK smb2_reconnect_server ]
- cifs_setup_session
- [ smb2_reconnect_server ]

auth_key.response was allocated in cifs_setup_session, and will release when the session destoried. So when session re- connect, auth_key.response should be check and released.

Tested with my system:
CIFS VFS: Free previous auth_key.response = ffff8800320bbf80

A simple auth_key.response allocation call trace:
- cifs_setup_session
- SMB2_sess_setup
- SMB2_sess_auth_rawntlmssp_authenticate
- build_ntlmssp_auth_blob
- setup_ntlmv2_rsp

---
 fs/cifs/connect.c |    8 ++++++++
 1 file changed, 8 insertions(+)

@@ -4060,6 +4060,14 @@ cifs_setup_session(const unsigned int xi
 	cifs_dbg(FYI, "Security Mode: 0x%x Capabilities: 0x%x TimeAdjust: %d\n",
 		 server->sec_mode, server->capabilities, server->timeAdj);
 
+	if (ses->auth_key.response) {
+		cifs_dbg(VFS, "Free previous auth_key.response = %p\n",
+			 ses->auth_key.response);
+		kfree(ses->auth_key.response);
+		ses->auth_key.response = NULL;
+		ses->auth_key.len = 0;
+	}
+
 	if (server->ops->sess_setup)
 		rc = server->ops->sess_setup(xid, ses, nls_info);
 

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Avraham Stern <[email protected]>

commit 6e46d8ce894374fc135c96a8d1057c6af1fef237 upstream.

When HW ROC is supported it is possible that after the HW notified that the ROC has started, the ROC was cancelled and another ROC was added while the hw_roc_start worker is waiting on the mutex (since cancelling the ROC and adding another one also holds the same mutex). As a result, the hw_roc_start worker will continue to run after the new ROC is added but before it is actually started by the HW. This may result in notifying userspace that the ROC has started before it actually does, or in case of management tx ROC, in an attempt to tx while not on the right channel.

In addition, when the driver will notify mac80211 that the second ROC has started, mac80211 will warn that this ROC has already been notified.

Fix this by flushing the hw_roc_start work before cancelling an ROC.

---
 net/mac80211/offchannel.c |    2 ++
 1 file changed, 2 insertions(+)

@@ -469,6 +469,8 @@ void ieee80211_roc_purge(struct ieee8021
 	struct ieee80211_roc_work *roc, *tmp;
 	LIST_HEAD(tmp_list);
 
+	flush_work(&local->hw_roc_start);
+
 	mutex_lock(&local->mtx);
 	list_for_each_entry_safe(roc, tmp, &local->roc_list, list) {
 		if (sdata && roc->sdata != sdata)

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paul Mackerras <[email protected]>

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.

[[email protected] - 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.]

---
 arch/powerpc/kvm/book3s_64_vio.c |   46 ++++++++++++++++++++++-----------------
 1 file changed, 27 insertions(+), 19 deletions(-)

@@ -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;
 }

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tahsin Erdogan <[email protected]>

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

---
 kernel/trace/trace.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

@@ -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);

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bo Yan <[email protected]>

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.

---
 kernel/trace/trace.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

@@ -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) {

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Shaohua Li <[email protected]>

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.

---
 drivers/md/raid5.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

@@ -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;

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dennis Yang <[email protected]>

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.

---
 drivers/md/raid5.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

@@ -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;

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Xin Long <[email protected]>

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.

---
 drivers/scsi/scsi_transport_iscsi.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

@@ -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;
 		}

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: LEROY Christophe <[email protected]>

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.

---
 drivers/crypto/talitos.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

@@ -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;
 

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: LEROY Christophe <[email protected]>

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

---
 drivers/crypto/talitos.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

@@ -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)

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eric Biggers <[email protected]>

commit e645016abc803dafc75e4b8f6e4118f088900ffb upstream.

Userspace can call keyctl_read() on a keyring to get the list of IDs of keys in the keyring. But if the user-supplied buffer is too small, the kernel would write the full list anyway --- which will corrupt whatever userspace memory happened to be past the end of the buffer. Fix it by only filling the space that is available.

---
 security/keys/keyring.c |   14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

@@ -416,7 +416,7 @@ static void keyring_describe(const struc
 }
 
 struct keyring_read_iterator_context {
-	size_t			qty;
+	size_t			buflen;
 	size_t			count;
 	key_serial_t __user	*buffer;
 };

@@ -428,9 +428,9 @@ static int keyring_read_iterator(const v
 	int ret;
 
 	kenter("{%s,%d},,{%zu/%zu}",
-	       key->type->name, key->serial, ctx->count, ctx->qty);
+	       key->type->name, key->serial, ctx->count, ctx->buflen);
 
-	if (ctx->count >= ctx->qty)
+	if (ctx->count >= ctx->buflen)
 		return 1;
 
 	ret = put_user(key->serial, ctx->buffer);

@@ -465,16 +465,12 @@ static long keyring_read(const struct ke
 		return 0;
 
 	/* Calculate how much data we could return */
-	ctx.qty = nr_keys * sizeof(key_serial_t);
-
 	if (!buffer || !buflen)
-		return ctx.qty;
-
-	if (buflen > ctx.qty)
-		ctx.qty = buflen;
+		return nr_keys * sizeof(key_serial_t);
 
 	/* Copy the IDs of the subscribed keys into the buffer */
 	ctx.buffer = (key_serial_t __user *)buffer;
+	ctx.buflen = buflen;
 	ctx.count = 0;
 	ret = assoc_array_iterate(&keyring->keys, keyring_read_iterator, &ctx);
 	if (ret < 0) {

[...]

trusted_read() has the same bug.

Also, the comment above keyctl_read_key() says "return the amount of data that is available in the key, irrespective of how much we copied into the buffer." All the other implementations of key_type::read seem to follow that, but this changes keyring_read() to return buflen in case of a truncated read.

Ben.

Ben Hutchings
Software Developer, Codethink Ltd.

Hi Ben, thanks for pointing this out. I had assumed the "obvious" semantics, but it turns out that's not what's documented. And actually the comment above keyctl_read_key() might be wrong too, since the man page says that nothing is copied if the buffer is too small... David, which behavior was intended? Some of the ->read() methods will fill a too-small buffer, while others don't.

I think this bug isn't *too* bad since the short return will only be encountered in cases where the kernel would have corrupted userspace memory before. But I'll send a patch to fix it.

And yes, trusted_read() is ignoring 'buflen' which is a bug too; I'll see if I can fix that too...

Eric

The manpage is correct. keyctl_read_alloc() in libkeyutils relies on the behaviour documented there with respect to the full size of the data always being returned, even if the buffer was too small.

The keyring cannot be modified whilst it is being read, so that's not a concern.

keyctl_read_alloc() doesn't care if the buffer actually gets written to or not, but it's best to honour the manpage.

David

Do you mean we should also make it not copy anything at all if the buffer is too small? The man page says "If the buffer is too small ... no copy will take place." However, the in-kernel documentation contradicts it: "As much of the data as can be fitted into the buffer will be copied to userspace if the buffer pointer is not NULL.". And meanwhile, the implementations of ->read() are split between the two behaviors.

Eric

I'd like to fix this, but I still can't decide whether keyring_read() should fill the buffer or not. In keyutils, keyctl_read_alloc() doesn't care, but keyctl_read() on a keyring is also called from dump_key_tree_aux(). And that *does* assume that the buffer was filled in the event of a short read --- although it can only happen if the keyring is added to concurrently, and even then it's still broken because dump_key_tree_aux() won't show everything in the keyring.

So do we really make it keep filling the buffer, even though that contradicts the man page?

Eric

On Tue, 2017-10-24 at 16:19 -0700, Eric Biggers wrote:
[...]

I don't think any application is likely to care about this. The documentation should also be changed to say that if the buffer is too small, "data may or may not be copied to the buffer" or "the contents of the buffer are undefined".

Ben.

Ben Hutchings
Software Developer, Codethink Ltd.

Okay, let's go with that.

David

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eric Biggers <[email protected]>

commit 237bbd29f7a049d310d907f4b2716a7feef9abf3 upstream.

It was possible for an unprivileged user to create the user and user session keyrings for another user. For example:

    sudo -u '#3000' sh -c 'keyctl add keyring _uid.4000 "" @u
                           keyctl add keyring _uid_ses.4000 "" @u
                           sleep 15' &
    sleep 1
    sudo -u '#4000' keyctl describe @u
    sudo -u '#4000' keyctl describe @us

This is problematic because these "fake" keyrings won't have the right permissions. In particular, the user who created them first will own them and will have full access to them via the possessor permissions, which can be used to compromise the security of a user's keys:

    -4: alswrv-----v------------  3000     0 keyring: _uid.4000
    -5: alswrv-----v------------  3000     0 keyring: _uid_ses.4000

Fix it by marking user and user session keyrings with a flag KEY_FLAG_UID_KEYRING. Then, when searching for a user or user session keyring by name, skip all keyrings that don't have the flag set.

---
 include/linux/key.h          |    2 ++
 security/keys/internal.h     |    2 +-
 security/keys/key.c          |    2 ++
 security/keys/keyring.c      |   23 ++++++++++++++---------
 security/keys/process_keys.c |    8 ++++++--
 5 files changed, 25 insertions(+), 12 deletions(-)

@@ -177,6 +177,7 @@ struct key {
 #define KEY_FLAG_TRUSTED_ONLY	9	/* set if keyring only accepts links to trusted keys */
 #define KEY_FLAG_BUILTIN	10	/* set if key is builtin */
 #define KEY_FLAG_ROOT_CAN_INVAL	11	/* set if key can be invalidated by root without permission */
+#define KEY_FLAG_UID_KEYRING	12	/* set if key is a user or user session keyring */
 
 	/* the key type and key description string
 	 * - the desc is used to match a key against search criteria

@@ -218,6 +219,7 @@ extern struct key *key_alloc(struct key_
 #define KEY_ALLOC_QUOTA_OVERRUN	0x0001	/* add to quota, permit even if overrun */
 #define KEY_ALLOC_NOT_IN_QUOTA	0x0002	/* not in quota */
 #define KEY_ALLOC_TRUSTED	0x0004	/* Key should be flagged as trusted */
+#define KEY_ALLOC_UID_KEYRING	0x0010	/* allocating a user or user session keyring */
 
 extern void key_revoke(struct key *key);
 extern void key_invalidate(struct key *key);

@@ -136,7 +136,7 @@ extern key_ref_t keyring_search_aux(key_
 extern key_ref_t search_my_process_keyrings(struct keyring_search_context *ctx);
 extern key_ref_t search_process_keyrings(struct keyring_search_context *ctx);
 
-extern struct key *find_keyring_by_name(const char *name, bool skip_perm_check);
+extern struct key *find_keyring_by_name(const char *name, bool uid_keyring);
 
 extern int install_user_keyrings(void);
 extern int install_thread_keyring_to_cred(struct cred *);

@@ -296,6 +296,8 @@ struct key *key_alloc(struct key_type *t
 		key->flags |= 1 << KEY_FLAG_IN_QUOTA;
 	if (flags & KEY_ALLOC_TRUSTED)
 		key->flags |= 1 << KEY_FLAG_TRUSTED;
+	if (flags & KEY_ALLOC_UID_KEYRING)
+		key->flags |= 1 << KEY_FLAG_UID_KEYRING;
 
 #ifdef KEY_DEBUGGING
 	key->magic = KEY_DEBUG_MAGIC;

@@ -961,15 +961,15 @@ found:
 /*
  * Find a keyring with the specified name.
  *
- * All named keyrings in the current user namespace are searched, provided they
- * grant Search permission directly to the caller (unless this check is
- * skipped).  Keyrings whose usage points have reached zero or who have been
- * revoked are skipped.
+ * Only keyrings that have nonzero refcount, are not revoked, and are owned by a
+ * user in the current user namespace are considered.  If @uid_keyring is %true,
+ * the keyring additionally must have been allocated as a user or user session
+ * keyring; otherwise, it must grant Search permission directly to the caller.
  *
  * Returns a pointer to the keyring with the keyring's refcount having being
  * incremented on success.  -ENOKEY is returned if a key could not be found.
  */
-struct key *find_keyring_by_name(const char *name, bool skip_perm_check)
+struct key *find_keyring_by_name(const char *name, bool uid_keyring)
 {
 	struct key *keyring;
 	int bucket;

@@ -997,10 +997,15 @@ struct key *find_keyring_by_name(const c
 			if (strcmp(keyring->description, name) != 0)
 				continue;
 
-			if (!skip_perm_check &&
-			    key_permission(make_key_ref(keyring, 0),
-					   KEY_NEED_SEARCH) < 0)
-				continue;
+			if (uid_keyring) {
+				if (!test_bit(KEY_FLAG_UID_KEYRING,
+					      &keyring->flags))
+					continue;
+			} else {
+				if (key_permission(make_key_ref(keyring, 0),
+						   KEY_NEED_SEARCH) < 0)
+					continue;
+			}
 
 			/* we've got a match but we might end up racing with
 			 * key_cleanup() if the keyring is currently 'dead'

@@ -76,7 +76,9 @@ int install_user_keyrings(void)
 		if (IS_ERR(uid_keyring)) {
 			uid_keyring = keyring_alloc(buf, user->uid, INVALID_GID,
 						    cred, user_keyring_perm,
-						    KEY_ALLOC_IN_QUOTA, NULL);
+						    KEY_ALLOC_UID_KEYRING |
+							KEY_ALLOC_IN_QUOTA,
+						    NULL);
 			if (IS_ERR(uid_keyring)) {
 				ret = PTR_ERR(uid_keyring);
 				goto error;

@@ -92,7 +94,9 @@ int install_user_keyrings(void)
 			session_keyring =
 				keyring_alloc(buf, user->uid, INVALID_GID,
 					      cred, user_keyring_perm,
-					      KEY_ALLOC_IN_QUOTA, NULL);
+					      KEY_ALLOC_UID_KEYRING |
+						  KEY_ALLOC_IN_QUOTA,
+					      NULL);
 			if (IS_ERR(session_keyring)) {
 				ret = PTR_ERR(session_keyring);
 				goto error_release;

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eric Biggers <[email protected]>

commit 37863c43b2c6464f252862bf2e9768264e961678 upstream.

Because keyctl_read_key() looks up the key with no permissions requested, it may find a negatively instantiated key. If the key is also possessed, we went ahead and called ->read() on the key. But the key payload will actually contain the ->reject_error rather than the normal payload. Thus, the kernel oopses trying to read the user_key_payload from memory address (int)-ENOKEY = 0x00000000ffffff82.

Fortunately the payload data is stored inline, so it shouldn't be possible to abuse this as an arbitrary memory read primitive...

Reproducer:
keyctl new_session
keyctl request2 user desc '' @s
keyctl read $(keyctl show | awk '/user: desc/ {print $1}')

It causes a crash like the following:

     BUG: unable to handle kernel paging request at 00000000ffffff92
     IP: user_read+0x33/0xa0
     PGD 36a54067 P4D 36a54067 PUD 0
     Oops: 0000 [#1] SMP
     CPU: 0 PID: 211 Comm: keyctl Not tainted 4.14.0-rc1 #337
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
     task: ffff90aa3b74c3c0 task.stack: ffff9878c0478000
     RIP: 0010:user_read+0x33/0xa0
     RSP: 0018:ffff9878c047bee8 EFLAGS: 00010246
     RAX: 0000000000000001 RBX: ffff90aa3d7da340 RCX: 0000000000000017
     RDX: 0000000000000000 RSI: 00000000ffffff82 RDI: ffff90aa3d7da340
     RBP: ffff9878c047bf00 R08: 00000024f95da94f R09: 0000000000000000
     R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
     R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
     FS:  00007f58ece69740(0000) GS:ffff90aa3e200000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 00000000ffffff92 CR3: 0000000036adc001 CR4: 00000000003606f0
     Call Trace:
      keyctl_read_key+0xac/0xe0
      SyS_keyctl+0x99/0x120
      entry_SYSCALL_64_fastpath+0x1f/0xbe
     RIP: 0033:0x7f58ec787bb9
     RSP: 002b:00007ffc8d401678 EFLAGS: 00000206 ORIG_RAX: 00000000000000fa
     RAX: ffffffffffffffda RBX: 00007ffc8d402800 RCX: 00007f58ec787bb9
     RDX: 0000000000000000 RSI: 00000000174a63ac RDI: 000000000000000b
     RBP: 0000000000000004 R08: 00007ffc8d402809 R09: 0000000000000020
     R10: 0000000000000000 R11: 0000000000000206 R12: 00007ffc8d402800
     R13: 00007ffc8d4016e0 R14: 0000000000000000 R15: 0000000000000000
     Code: e5 41 55 49 89 f5 41 54 49 89 d4 53 48 89 fb e8 a4 b4 ad ff 85 c0 74 09 80 3d b9 4c 96 00 00 74 43 48 8b b3 20 01 00 00 4d 85 ed <0f> b7 5e 10 74 29 4d 85 e4 74 24 4c 39 e3 4c 89 e2 4c 89 ef 48
     RIP: user_read+0x33/0xa0 RSP: ffff9878c047bee8
     CR2: 00000000ffffff92

---
 security/keys/keyctl.c |    5 +++++
 1 file changed, 5 insertions(+)

@@ -738,6 +738,11 @@ long keyctl_read_key(key_serial_t keyid,
 
 	key = key_ref_to_ptr(key_ref);
 
+	if (test_bit(KEY_FLAG_NEGATIVE, &key->flags)) {
+		ret = -ENOKEY;
+		goto error2;
+	}
+
 	/* see if we can read it directly */
 	ret = key_permission(key_ref, KEY_NEED_READ);
 	if (ret == 0)

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Tyrel Datwyler <[email protected]>

commit b537ca6fede69a281dc524983e5e633d79a10a08 upstream.

A reference to the parent device node is held by add_dt_node() for the node to be added. If the call to dlpar_configure_connector() fails add_dt_node() returns ENOENT and that reference is not freed.

Add a call to of_node_put(parent_dn) prior to bailing out after a failed dlpar_configure_connector() call.

---
 arch/powerpc/platforms/pseries/mobility.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

@@ -225,8 +225,10 @@ static int add_dt_node(__be32 parent_pha
 		return -ENOENT;
 
 	dn = dlpar_configure_connector(drc_index, parent_dn);
-	if (!dn)
+	if (!dn) {
+		of_node_put(parent_dn);
 		return -ENOENT;
+	}
 
 	rc = dlpar_attach_node(dn);
 	if (rc)

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Steve French <[email protected]>

commit 23586b66d84ba3184b8820277f3fc42761640f87 upstream.

Samba rejects SMB3.1.1 dialect (vers=3.1.1) negotiate requests from the kernel client due to the two byte pad at the end of the negotiate contexts.

---
 fs/cifs/smb2pdu.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

@@ -361,7 +361,7 @@ assemble_neg_contexts(struct smb2_negoti
 	build_encrypt_ctxt((struct smb2_encryption_neg_context *)pneg_ctxt);
 	req->NegotiateContextOffset = cpu_to_le32(OFFSET_OF_NEG_CONTEXT);
 	req->NegotiateContextCount = cpu_to_le16(2);
-	inc_rfc1001_len(req, 4 + sizeof(struct smb2_preauth_neg_context) + 2
+	inc_rfc1001_len(req, 4 + sizeof(struct smb2_preauth_neg_context)
 			+ sizeof(struct smb2_encryption_neg_context)); /* calculate hash */
 }
 #else

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Steve French <[email protected]>

commit 0603c96f3af50e2f9299fa410c224ab1d465e0f9 upstream.

As long as signing is supported (ie not a guest user connection) and connection is SMB3 or SMB3.02, then validate negotiate (protect against man in the middle downgrade attacks). We had been doing this only when signing was required, not when signing was just enabled, but this more closely matches recommended SMB3 behavior and is better security. Suggested by Metze.

---
 fs/cifs/smb2pdu.c |   17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

@@ -526,15 +526,22 @@ int smb3_validate_negotiate(const unsign
 
 	/*
 	 * validation ioctl must be signed, so no point sending this if we
-	 * can not sign it.  We could eventually change this to selectively
+	 * can not sign it (ie are not known user).  Even if signing is not
+	 * required (enabled but not negotiated), in those cases we selectively
 	 * sign just this, the first and only signed request on a connection.
-	 * This is good enough for now since a user who wants better security
-	 * would also enable signing on the mount. Having validation of
-	 * negotiate info for signed connections helps reduce attack vectors
+	 * Having validation of negotiate info  helps reduce attack vectors.
 	 */
-	if (tcon->ses->server->sign == false)
+	if (tcon->ses->session_flags & SMB2_SESSION_FLAG_IS_GUEST)
 		return 0; /* validation requires signing */
 
+	if (tcon->ses->user_name == NULL) {
+		cifs_dbg(FYI, "Can't validate negotiate: null user mount\n");
+		return 0; /* validation requires signing */
+	}
+
+	if (tcon->ses->session_flags & SMB2_SESSION_FLAG_IS_NULL)
+		cifs_dbg(VFS, "Unexpected null user (anonymous) auth flag sent by server\n");
+
 	vneg_inbuf.Capabilities =
 			cpu_to_le32(tcon->ses->server->vals->req_capabilities);
 	memcpy(vneg_inbuf.Guid, tcon->ses->server->client_guid,

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Steve French <[email protected]>

commit 1013e760d10e614dc10b5624ce9fc41563ba2e65 upstream.

---
 fs/cifs/file.c |    7 +++++++
 1 file changed, 7 insertions(+)

@@ -224,6 +224,13 @@ cifs_nt_open(char *full_path, struct ino
 	if (backup_cred(cifs_sb))
 		create_options |= CREATE_OPEN_BACKUP_INTENT;
 
+	/* O_SYNC also has bit for O_DSYNC so following check picks up either */
+	if (f_flags & O_SYNC)
+		create_options |= CREATE_WRITE_THROUGH;
+
+	if (f_flags & O_DIRECT)
+		create_options |= CREATE_NO_BUFFER;
+
 	oparms.tcon = tcon;
 	oparms.cifs_sb = cifs_sb;
 	oparms.desired_access = desired_access;

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andreas Gruenbacher <[email protected]>

commit fc46820b27a2d9a46f7e90c9ceb4a64a1bc5fab8 upstream.

In generic_file_llseek_size, return -ENXIO for negative offsets as well as offsets beyond EOF. This affects filesystems which don't implement SEEK_HOLE / SEEK_DATA internally, possibly because they don't support holes.

Fixes xfstest generic/448.

---
 fs/read_write.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

@@ -112,7 +112,7 @@ generic_file_llseek_size(struct file *fi
 		 * In the generic case the entire file is data, so as long as
 		 * offset isn't at the end of the file then the offset is data.
 		 */
-		if (offset >= eof)
+		if ((unsigned long long)offset >= eof)
 			return -ENXIO;
 		break;
 	case SEEK_HOLE:

@@ -120,7 +120,7 @@ generic_file_llseek_size(struct file *fi
 		 * There is a virtual hole at the end of the file, so as long as
 		 * offset isn't i_size or larger, return i_size.
 		 */
-		if (offset >= eof)
+		if ((unsigned long long)offset >= eof)
 			return -ENXIO;
 		offset = eof;
 		break;

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vladis Dronov <[email protected]>

commit e785fa0a164aa11001cba931367c7f94ffaff888 upstream.

nl80211_set_rekey_data() does not check if the required attributes NL80211_REKEY_DATA_{REPLAY_CTR,KEK,KCK} are present when processing NL80211_CMD_SET_REKEY_OFFLOAD request. This request can be issued by users with CAP_NET_ADMIN privilege and may result in NULL dereference and a system crash. Add a check for the required attributes presence. This patch is based on the patch by bo Zhang.

This fixes CVE-2017-12153.

References: https://bugzilla.redhat.com/show_bug.cgi?id=1491046

---
 net/wireless/nl80211.c |    3 +++
 1 file changed, 3 insertions(+)

@@ -9786,6 +9786,9 @@ static int nl80211_set_rekey_data(struct
 	if (err)
 		return err;
 
+	if (!tb[NL80211_REKEY_DATA_REPLAY_CTR] || !tb[NL80211_REKEY_DATA_KEK] ||
+	    !tb[NL80211_REKEY_DATA_KCK])
+		return -EINVAL;
 	if (nla_len(tb[NL80211_REKEY_DATA_REPLAY_CTR]) != NL80211_REPLAY_CTR_LEN)
 		return -ERANGE;
 	if (nla_len(tb[NL80211_REKEY_DATA_KEK]) != NL80211_KEK_LEN)

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Christoph Hellwig <[email protected]>

commit f507b54dccfd8000c517d740bc45f20c74532d18 upstream.

The job structure is allocated as part of the request, so we should not free it in the error path of bsg_prepare_job.

---
 block/bsg-lib.c |    1 -
 1 file changed, 1 deletion(-)

@@ -147,7 +147,6 @@ static int bsg_create_job(struct device
 failjob_rls_rqst_payload:
 	kfree(job->request_payload.sg_list);
 failjob_rls_job:
-	kfree(job);
 	return -ENOMEM;
 }
 

That function doesn't exist here (it was introduced in 4.13). Instead, this backport has modified bsg_create_job(), creating a leak. Please revert this on the 3.18, 4.4 and 4.9 stable branches.

Ben.

Ben Hutchings
Software Developer, Codethink Ltd.

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Oleg Nesterov <[email protected]>

commit 66a733ea6b611aecf0119514d2dddab5f9d6c01e upstream.

As Chris explains, get_seccomp_filter() and put_seccomp_filter() can end up using different filters. Once we drop ->siglock it is possible for task->seccomp.filter to have been replaced by SECCOMP_FILTER_FLAG_TSYNC.

---
 kernel/seccomp.c |   23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

@@ -457,14 +457,19 @@ static long seccomp_attach_filter(unsign
 	return 0;
 }
 
+void __get_seccomp_filter(struct seccomp_filter *filter)
+{
+	/* Reference count is bounded by the number of total processes. */
+	atomic_inc(&filter->usage);
+}
+
 /* get_seccomp_filter - increments the reference count of the filter on @tsk */
 void get_seccomp_filter(struct task_struct *tsk)
 {
 	struct seccomp_filter *orig = tsk->seccomp.filter;
 	if (!orig)
 		return;
-	/* Reference count is bounded by the number of total processes. */
-	atomic_inc(&orig->usage);
+	__get_seccomp_filter(orig);
 }
 
 static inline void seccomp_filter_free(struct seccomp_filter *filter)

@@ -475,10 +480,8 @@ static inline void seccomp_filter_free(s
 	}
 }
 
-/* put_seccomp_filter - decrements the ref count of tsk->seccomp.filter */
-void put_seccomp_filter(struct task_struct *tsk)
+static void __put_seccomp_filter(struct seccomp_filter *orig)
 {
-	struct seccomp_filter *orig = tsk->seccomp.filter;
 	/* Clean up single-reference branches iteratively. */
 	while (orig && atomic_dec_and_test(&orig->usage)) {
 		struct seccomp_filter *freeme = orig;

@@ -487,6 +490,12 @@ void put_seccomp_filter(struct task_stru
 	}
 }
 
+/* put_seccomp_filter - decrements the ref count of tsk->seccomp.filter */
+void put_seccomp_filter(struct task_struct *tsk)
+{
+	__put_seccomp_filter(tsk->seccomp.filter);
+}
+
 /**
  * seccomp_send_sigsys - signals the task to allow in-process syscall emulation
  * @syscall: syscall number to send to userland

@@ -927,13 +936,13 @@ long seccomp_get_filter(struct task_stru
 	if (!data)
 		goto out;
 
-	get_seccomp_filter(task);
+	__get_seccomp_filter(filter);
 	spin_unlock_irq(&task->sighand->siglock);
 
 	if (copy_to_user(data, fprog->filter, bpf_classic_proglen(fprog)))
 		ret = -EFAULT;
 
-	put_seccomp_filter(task);
+	__put_seccomp_filter(filter);
 	return ret;
 
 out:

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Marc Zyngier <[email protected]>

commit 5371513fb338fb9989c569dc071326d369d6ade8 upstream.

When the kernel is entered at EL2 on an ARMv8.0 system, we construct the EL1 pstate and make sure this uses the the EL1 stack pointer (we perform an exception return to EL1h).

But if the kernel is either entered at EL1 or stays at EL2 (because we're on a VHE-capable system), we fail to set SPsel, and use whatever stack selection the higher exception level has choosen for us.

Let's not take any chance, and make sure that SPsel is set to one before we decide the mode we're going to run in.

---
 arch/arm64/kernel/head.S |    1 +
 1 file changed, 1 insertion(+)

@@ -446,6 +446,7 @@ ENDPROC(__mmap_switched)
  * booted in EL1 or EL2 respectively.
  */
 ENTRY(el2_setup)
+	msr	SPsel, #1			// We want to use SP_EL{1,2}
 	mrs	x0, CurrentEL
 	cmp	x0, #CurrentEL_EL2
 	b.ne	1f

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Will Deacon <[email protected]>

commit 760bfb47c36a07741a089bf6a28e854ffbee7dc9 upstream.

We currently route pte translation faults via do_page_fault, which elides the address check against TASK_SIZE before invoking the mm fault handling code. However, this can cause issues with the path walking code in conjunction with our word-at-a-time implementation because load_unaligned_zeropad can end up faulting in kernel space if it reads across a page boundary and runs into a page fault (e.g. by attempting to read from a guard region).

In the case of such a fault, load_unaligned_zeropad has registered a fixup to shift the valid data and pad with zeroes, however the abort is reported as a level 3 translation fault and we dispatch it straight to do_page_fault, despite it being a kernel address. This results in calling a sleeping function from atomic context:

  BUG: sleeping function called from invalid context at arch/arm64/mm/fault.c:313
  in_atomic(): 0, irqs_disabled(): 0, pid: 10290
  Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
  [...]
  [<ffffff8e016cd0cc>] ___might_sleep+0x134/0x144
  [<ffffff8e016cd158>] __might_sleep+0x7c/0x8c
  [<ffffff8e016977f0>] do_page_fault+0x140/0x330
  [<ffffff8e01681328>] do_mem_abort+0x54/0xb0
  Exception stack(0xfffffffb20247a70 to 0xfffffffb20247ba0)
  [...]
  [<ffffff8e016844fc>] el1_da+0x18/0x78
  [<ffffff8e017f399c>] path_parentat+0x44/0x88
  [<ffffff8e017f4c9c>] filename_parentat+0x5c/0xd8
  [<ffffff8e017f5044>] filename_create+0x4c/0x128
  [<ffffff8e017f59e4>] SyS_mkdirat+0x50/0xc8
  [<ffffff8e01684e30>] el0_svc_naked+0x24/0x28
  Code: 36380080 d5384100 f9400800 9402566d (d4210000)
  ---[ end trace 2d01889f2bca9b9f ]---

Fix this by dispatching all translation faults to do_translation_faults, which avoids invoking the page fault logic for faults on kernel addresses.

---
 arch/arm64/mm/fault.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

@@ -447,7 +447,7 @@ static struct fault_info {
 	{ do_translation_fault,	SIGSEGV, SEGV_MAPERR,	"level 0 translation fault"	},
 	{ do_translation_fault,	SIGSEGV, SEGV_MAPERR,	"level 1 translation fault"	},
 	{ do_translation_fault,	SIGSEGV, SEGV_MAPERR,	"level 2 translation fault"	},
-	{ do_page_fault,	SIGSEGV, SEGV_MAPERR,	"level 3 translation fault"	},
+	{ do_translation_fault,	SIGSEGV, SEGV_MAPERR,	"level 3 translation fault"	},
 	{ do_bad,		SIGBUS,  0,		"unknown 8"			},
 	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 1 access flag fault"	},
 	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 2 access flag fault"	},

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jim Mattson <[email protected]>

commit 51aa68e7d57e3217192d88ce90fd5b8ef29ec94f upstream.

If L1 does not specify the "use TPR shadow" VM-execution control in vmcs12, then L0 must specify the "CR8-load exiting" and "CR8-store exiting" VM-execution controls in vmcs02. Failure to do so will give the L2 VM unrestricted read/write access to the hardware CR8.

This fixes CVE-2017-12154.

---
 arch/x86/kvm/vmx.c |    5 +++++
 1 file changed, 5 insertions(+)

@@ -9683,6 +9683,11 @@ static void prepare_vmcs02(struct kvm_vc
 		vmcs_write64(VIRTUAL_APIC_PAGE_ADDR,
 				page_to_phys(vmx->nested.virtual_apic_page));
 		vmcs_write32(TPR_THRESHOLD, vmcs12->tpr_threshold);
+	} else {
+#ifdef CONFIG_X86_64
+		exec_control |= CPU_BASED_CR8_LOAD_EXITING |
+				CPU_BASED_CR8_STORE_EXITING;
+#endif
 	}
 
 	if (cpu_has_vmx_msr_bitmap() &&

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Nicolai Stange <[email protected]>

commit 9561475db680f7144d2223a409dd3d7e322aca03 upstream.

The driver_override implementation is susceptible to a race condition when different threads are reading vs. storing a different driver override. Add locking to avoid the race condition.

This is in close analogy to commit 6265539776a0 ("driver core: platform:
fix race condition with driver_override") from Adrian Salido.

---
 drivers/pci/pci-sysfs.c |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

@@ -522,7 +522,7 @@ static ssize_t driver_override_store(str
 				     const char *buf, size_t count)
 {
 	struct pci_dev *pdev = to_pci_dev(dev);
-	char *driver_override, *old = pdev->driver_override, *cp;
+	char *driver_override, *old, *cp;
 
 	/* We need to keep extra room for a newline */
 	if (count >= (PAGE_SIZE - 1))

@@ -536,12 +536,15 @@ static ssize_t driver_override_store(str
 	if (cp)
 		*cp = '\0';
 
+	device_lock(dev);
+	old = pdev->driver_override;
 	if (strlen(driver_override)) {
 		pdev->driver_override = driver_override;
 	} else {
 		kfree(driver_override);
 		pdev->driver_override = NULL;
 	}
+	device_unlock(dev);
 
 	kfree(old);
 

@@ -552,8 +555,12 @@ static ssize_t driver_override_show(stru
 				    struct device_attribute *attr, char *buf)
 {
 	struct pci_dev *pdev = to_pci_dev(dev);
+	ssize_t len;
 
-	return snprintf(buf, PAGE_SIZE, "%s\n", pdev->driver_override);
+	device_lock(dev);
+	len = snprintf(buf, PAGE_SIZE, "%s\n", pdev->driver_override);
+	device_unlock(dev);
+	return len;
 }
 static DEVICE_ATTR_RW(driver_override);
 

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Naohiro Aota <[email protected]>

commit bb166d7207432d3c7d10c45dc052f12ba3a2121d upstream.

__del_reloc_root should be called before freeing up reloc_root->node. If not, calling __del_reloc_root() dereference reloc_root->node, causing the system BUG.

---
 fs/btrfs/relocation.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

@@ -2350,11 +2350,11 @@ void free_reloc_roots(struct list_head *
 	while (!list_empty(list)) {
 		reloc_root = list_entry(list->next, struct btrfs_root,
 					root_list);
+		__del_reloc_root(reloc_root);
 		free_extent_buffer(reloc_root->node);
 		free_extent_buffer(reloc_root->commit_root);
 		reloc_root->node = NULL;
 		reloc_root->commit_root = NULL;
-		__del_reloc_root(reloc_root);
 	}
 }
 

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Naohiro Aota <[email protected]>

commit 78ad4ce014d025f41b8dde3a81876832ead643cf upstream.

btrfs_cmp_data_prepare() (almost) always returns 0 i.e. ignoring errors from gather_extent_pages(). While the pages are freed by btrfs_cmp_data_free(), cmp->num_pages still has > 0. Then, btrfs_extent_same() try to access the already freed pages causing faults (or violates PageLocked assertion).

This patch just return the error as is so that the caller stop the process.

---
 fs/btrfs/ioctl.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

@@ -2984,7 +2984,7 @@ static int btrfs_cmp_data_prepare(struct
 out:
 	if (ret)
 		btrfs_cmp_data_free(cmp);
-	return 0;
+	return ret;
 }
 
 static int btrfs_cmp_data(struct inode *src, u64 loff, struct inode *dst,

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: satoru takeuchi <[email protected]>

commit 6d6d282932d1a609e60dc4467677e0e863682f57 upstream.

btrfs sub set-default succeeds to set an ID which isn't corresponding to any fs/file tree. If such the bad ID is set to a filesystem, we can't mount this filesystem without specifying subvol or subvolid mount options.

---
 fs/btrfs/ioctl.c |    4 ++++
 1 file changed, 4 insertions(+)

@@ -4118,6 +4118,10 @@ static long btrfs_ioctl_default_subvol(s
 		ret = PTR_ERR(new_root);
 		goto out;
 	}
+	if (!is_fstree(new_root->objectid)) {
+		ret = -ENOENT;
+		goto out;
+	}
 
 	path = btrfs_alloc_path();
 	if (!path) {

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eric Biggers <[email protected]>

commit 814fb7bb7db5433757d76f4c4502c96fc53b0b5e upstream.

[Please apply to 4.4-stable. Note: the backport includes the fpstate_init() call in xstateregs_set(), since fix is useless without it. It was added by commit 91c3dba7dbc1 ("x86/fpu/xstate: Fix PTRACE frames for XSAVES"), but it doesn't make sense to backport that whole commit.]

On x86, userspace can use the ptrace() or rt_sigreturn() system calls to set a task's extended state (xstate) or "FPU" registers. ptrace() can set them for another task using the PTRACE_SETREGSET request with NT_X86_XSTATE, while rt_sigreturn() can set them for the current task. In either case, registers can be set to any value, but the kernel assumes that the XSAVE area itself remains valid in the sense that the CPU can restore it.

However, in the case where the kernel is using the uncompacted xstate format (which it does whenever the XSAVES instruction is unavailable), it was possible for userspace to set the xcomp_bv field in the xstate_header to an arbitrary value. However, all bits in that field are reserved in the uncompacted case, so when switching to a task with nonzero xcomp_bv, the XRSTOR instruction failed with a #GP fault. This caused the WARN_ON_FPU(err) in copy_kernel_to_xregs() to be hit. In addition, since the error is otherwise ignored, the FPU registers from the task previously executing on the CPU were leaked.

Fix the bug by checking that the user-supplied value of xcomp_bv is 0 in the uncompacted case, and returning an error otherwise.

The reason for validating xcomp_bv rather than simply overwriting it with 0 is that we want userspace to see an error if it (incorrectly) provides an XSAVE area in compacted format rather than in uncompacted format.

Note that as before, in case of error we clear the task's FPU state. This is perhaps non-ideal, especially for PTRACE_SETREGSET; it might be better to return an error before changing anything. But it seems the "clear on error" behavior is fine for now, and it's a little tricky to do otherwise because it would mean we couldn't simply copy the full userspace state into kernel memory in one __copy_from_user().

This bug was found by syzkaller, which hit the above-mentioned WARN_ON_FPU():

    WARNING: CPU: 1 PID: 0 at ./arch/x86/include/asm/fpu/internal.h:373 __switch_to+0x5b5/0x5d0
    CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.13.0 #453
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    task: ffff9ba2bc8e42c0 task.stack: ffffa78cc036c000
    RIP: 0010:__switch_to+0x5b5/0x5d0
    RSP: 0000:ffffa78cc08bbb88 EFLAGS: 00010082
    RAX: 00000000fffffffe RBX: ffff9ba2b8bf2180 RCX: 00000000c0000100
    RDX: 00000000ffffffff RSI: 000000005cb10700 RDI: ffff9ba2b8bf36c0
    RBP: ffffa78cc08bbbd0 R08: 00000000929fdf46 R09: 0000000000000001
    R10: 0000000000000000 R11: 0000000000000000 R12: ffff9ba2bc8e42c0
    R13: 0000000000000000 R14: ffff9ba2b8bf3680 R15: ffff9ba2bf5d7b40
    FS:  00007f7e5cb10700(0000) GS:ffff9ba2bf400000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00000000004005cc CR3: 0000000079fd5000 CR4: 00000000001406e0
    Call Trace:
    Code: 84 00 00 00 00 00 e9 11 fd ff ff 0f ff 66 0f 1f 84 00 00 00 00 00 e9 e7 fa ff ff 0f ff 66 0f 1f 84 00 00 00 00 00 e9 c2 fa ff ff <0f> ff 66 0f 1f 84 00 00 00 00 00 e9 d4 fc ff ff 66 66 2e 0f 1f

Here is a C reproducer. The expected behavior is that the program spin forever with no output. However, on a buggy kernel running on a processor with the "xsave" feature but without the "xsaves" feature (e.g. Sandy Bridge through Broadwell for Intel), within a second or two the program reports that the xmm registers were corrupted, i.e. were not restored correctly. With CONFIG_X86_DEBUG_FPU=y it also hits the above kernel warning.

    #define _GNU_SOURCE
    #include <stdbool.h>
    #include <inttypes.h>
    #include <linux/elf.h>
    #include <stdio.h>
    #include <sys/ptrace.h>
    #include <sys/uio.h>
    #include <sys/wait.h>
    #include <unistd.h>

    int main(void)
    {
        int pid = fork();
        uint64_t xstate[512];
        struct iovec iov = { .iov_base = xstate, .iov_len = sizeof(xstate) };

        if (pid == 0) {
            bool tracee = true;
            for (int i = 0; i < sysconf(_SC_NPROCESSORS_ONLN) && tracee; i++)
                tracee = (fork() != 0);
            uint32_t xmm0[4] = { [0 ... 3] = tracee ? 0x00000000 : 0xDEADBEEF };
            asm volatile("   movdqu %0, %%xmm0\n"
                         "   mov %0, %%rbx\n"
                         "1: movdqu %%xmm0, %0\n"
                         "   mov %0, %%rax\n"
                         "   cmp %%rax, %%rbx\n"
                         "   je 1b\n"
                         : "+m" (xmm0) : : "rax", "rbx", "xmm0");
            printf("BUG: xmm registers corrupted!  tracee=%d, xmm0=%08X%08X%08X%08X\n",
                   tracee, xmm0[0], xmm0[1], xmm0[2], xmm0[3]);
        } else {
            usleep(100000);
            ptrace(PTRACE_ATTACH, pid, 0, 0);
            wait(NULL);
            ptrace(PTRACE_GETREGSET, pid, NT_X86_XSTATE, &iov);
            xstate[65] = -1;
            ptrace(PTRACE_SETREGSET, pid, NT_X86_XSTATE, &iov);
            ptrace(PTRACE_CONT, pid, 0, 0);
            wait(NULL);
        }
        return 1;
    }

Note: the program only tests for the bug using the ptrace() system call. The bug can also be reproduced using the rt_sigreturn() system call, but only when called from a 32-bit program, since for 64-bit programs the kernel restores the FPU state from the signal frame by doing XRSTOR directly from userspace memory (with proper error checking).

---
 arch/x86/kernel/fpu/regset.c |   11 +++++++++++
 arch/x86/kernel/fpu/signal.c |    4 +++-
 2 files changed, 14 insertions(+), 1 deletion(-)

@@ -116,6 +116,11 @@ int xstateregs_set(struct task_struct *t
 	xsave = &fpu->state.xsave;
 
 	ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, xsave, 0, -1);
+
+	/* xcomp_bv must be 0 when using uncompacted format */
+	if (!ret && xsave->header.xcomp_bv)
+		ret = -EINVAL;
+
 	/*
 	 * mxcsr reserved bits must be masked to zero for security reasons.
 	 */

@@ -126,6 +131,12 @@ int xstateregs_set(struct task_struct *t
 	 */
 	memset(&xsave->header.reserved, 0, 48);
 
+	/*
+	 * In case of failure, mark all states as init:
+	 */
+	if (ret)
+		fpstate_init(&fpu->state);
+
 	return ret;
 }
 

@@ -309,7 +309,9 @@ static int __fpu__restore_sig(void __use
 		fpu__drop(fpu);
 
 		if (__copy_from_user(&fpu->state.xsave, buf_fx, state_size) ||
-		    __copy_from_user(&env, buf, sizeof(env))) {
+		    __copy_from_user(&env, buf, sizeof(env)) ||
+		    (state_size > offsetof(struct xregs_state, header) &&
+		     fpu->state.xsave.header.xcomp_bv)) {
 			fpstate_init(&fpu->state);
 			err = -1;
 		} else {

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andreas Gruenbacher <[email protected]>

commit 10201655b085df8e000822e496e5d4016a167a36 upstream.

The switch to rhashtables (commit 88ffbf3e03) broke the debugfs glock dump (/sys/kernel/debug/gfs2/<device>/glocks) for dumps bigger than a single buffer: the right function for restarting an rhashtable iteration from the beginning of the hash table is rhashtable_walk_enter; rhashtable_walk_stop + rhashtable_walk_start will just resume from the current position.

The upstream commit doesn't directly apply to 4.4.y because 4.4.y doesn't have rhashtable_walk_enter and the following mainline commits:

92ecd73a887c4a2b94daf5fc35179d75d1c4ef95
gfs2: Deduplicate gfs2_{glocks,glstats}_open
cc37a62785a584f4875788689f3fd1fa6e4eb291
gfs2: Replace rhashtable_walk_init with rhashtable_walk_enter

Other than rhashtable_walk_enter, rhashtable_walk_init can fail. To handle the failure case in gfs2_glock_seq_stop, we check if rhashtable_walk_init has initialized iter->walker; if it has not, we must not call rhashtable_walk_stop or rhashtable_walk_exit.

---
 fs/gfs2/glock.c |   21 +++++++++------------
 1 file changed, 9 insertions(+), 12 deletions(-)

@@ -1814,13 +1814,10 @@ static void *gfs2_glock_seq_start(struct
 {
 	struct gfs2_glock_iter *gi = seq->private;
 	loff_t n = *pos;
-	int ret;
 
-	if (gi->last_pos <= *pos)
-		n = (*pos - gi->last_pos);
-
-	ret = rhashtable_walk_start(&gi->hti);
-	if (ret)
+	if (rhashtable_walk_init(&gl_hash_table, &gi->hti) != 0)
+		return NULL;
+	if (rhashtable_walk_start(&gi->hti) != 0)
 		return NULL;
 
 	do {

@@ -1828,6 +1825,7 @@ static void *gfs2_glock_seq_start(struct
 	} while (gi->gl && n--);
 
 	gi->last_pos = *pos;
+
 	return gi->gl;
 }
 

@@ -1839,6 +1837,7 @@ static void *gfs2_glock_seq_next(struct
 	(*pos)++;
 	gi->last_pos = *pos;
 	gfs2_glock_iter_next(gi);
+
 	return gi->gl;
 }
 

@@ -1847,7 +1846,10 @@ static void gfs2_glock_seq_stop(struct s
 	struct gfs2_glock_iter *gi = seq->private;
 
 	gi->gl = NULL;
-	rhashtable_walk_stop(&gi->hti);
+	if (gi->hti.walker) {
+		rhashtable_walk_stop(&gi->hti);
+		rhashtable_walk_exit(&gi->hti);
+	}
 }
 
 static int gfs2_glock_seq_show(struct seq_file *seq, void *iter_ptr)

@@ -1910,12 +1912,10 @@ static int gfs2_glocks_open(struct inode
 		struct gfs2_glock_iter *gi = seq->private;
 
 		gi->sdp = inode->i_private;
-		gi->last_pos = 0;
 		seq->buf = kmalloc(GFS2_SEQ_GOODSIZE, GFP_KERNEL | __GFP_NOWARN);
 		if (seq->buf)
 			seq->size = GFS2_SEQ_GOODSIZE;
 		gi->gl = NULL;
-		ret = rhashtable_walk_init(&gl_hash_table, &gi->hti);
 	}
 	return ret;
 }

@@ -1926,7 +1926,6 @@ static int gfs2_glocks_release(struct in
 	struct gfs2_glock_iter *gi = seq->private;
 
 	gi->gl = NULL;
-	rhashtable_walk_exit(&gi->hti);
 	return seq_release_private(inode, file);
 }
 

@@ -1938,12 +1937,10 @@ static int gfs2_glstats_open(struct inod
 		struct seq_file *seq = file->private_data;
 		struct gfs2_glock_iter *gi = seq->private;
 		gi->sdp = inode->i_private;
-		gi->last_pos = 0;
 		seq->buf = kmalloc(GFS2_SEQ_GOODSIZE, GFP_KERNEL | __GFP_NOWARN);
 		if (seq->buf)
 			seq->size = GFS2_SEQ_GOODSIZE;
 		gi->gl = NULL;
-		ret = rhashtable_walk_init(&gl_hash_table, &gi->hti);
 	}
 	return ret;
 }

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Myungho Jung <[email protected]>

commit b94bf594cf8ed67cdd0439e70fa939783471597a upstream.

timer_migration sysctl acts as a boolean switch, so the allowed values should be restricted to 0 and 1.

Add the necessary extra fields to the sysctl table entry to enforce that.

[ tglx: Rewrote changelog ]

---
 kernel/sysctl.c     |    2 ++
 kernel/time/timer.c |    2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

@@ -1159,6 +1159,8 @@ static struct ctl_table kern_table[] = {
 		.maxlen		= sizeof(unsigned int),
 		.mode		= 0644,
 		.proc_handler	= timer_migration_handler,
+		.extra1		= &zero,
+		.extra2		= &one,
 	},
 #endif
 #ifdef CONFIG_BPF_SYSCALL

@@ -127,7 +127,7 @@ int timer_migration_handler(struct ctl_t
 	int ret;
 
 	mutex_lock(&mutex);
-	ret = proc_dointvec(table, write, buffer, lenp, ppos);
+	ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
 	if (!ret && write)
 		timers_update_migration(false);
 	mutex_unlock(&mutex);

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Frederic Barrat <[email protected]>

commit 197267d0356004a31c4d6b6336598f5dff3301e1 upstream.

cxl keeps a driver use count, which is used with the hash memory model on p8 to know when to upgrade local TLBIs to global and to trigger callbacks to manage the MMU for PSL8.

If a process opens a context and closes without attaching or fails the attachment, the driver use count is never decremented. As a consequence, TLB invalidations remain global, even if there are no active cxl contexts.

We should increment the driver use count when the process is attaching to the cxl adapter, and not on open. It's not needed before the adapter starts using the context and the use count is decremented on the detach path, so it makes more sense.

It affects only the user api. The kernel api is already doing The Right Thing.

---
 drivers/misc/cxl/api.c  |    4 ++++
 drivers/misc/cxl/file.c |    8 +++++++-
 2 files changed, 11 insertions(+), 1 deletion(-)

@@ -176,6 +176,10 @@ int cxl_start_context(struct cxl_context
 		kernel = false;
 	}
 
+	/*
+	 * Increment driver use count. Enables global TLBIs for hash
+	 * and callbacks to handle the segment table
+	 */
 	cxl_ctx_get();
 
 	if ((rc = cxl_attach_process(ctx, kernel, wed , 0))) {

@@ -94,7 +94,6 @@ static int __afu_open(struct inode *inod
 
 	pr_devel("afu_open pe: %i\n", ctx->pe);
 	file->private_data = ctx;
-	cxl_ctx_get();
 
 	/* indicate success */
 	rc = 0;

@@ -205,11 +204,18 @@ static long afu_ioctl_start_work(struct
 	ctx->pid = get_task_pid(current, PIDTYPE_PID);
 	ctx->glpid = get_task_pid(current->group_leader, PIDTYPE_PID);
 
+	/*
+	 * Increment driver use count. Enables global TLBIs for hash
+	 * and callbacks to handle the segment table
+	 */
+	cxl_ctx_get();
+
 	trace_cxl_attach(ctx, work.work_element_descriptor, work.num_interrupts, amr);
 
 	if ((rc = cxl_attach_process(ctx, false, work.work_element_descriptor,
 				     amr))) {
 		afu_release_irqs(ctx, ctx);
+		cxl_ctx_put();
 		goto out;
 	}
 

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Robert Jarzmik <[email protected]>

commit c283e41ef32442f41e7180f9bb1c5aedf9255bfe upstream.

The DMA chip has a fixed number of requestor lines used for flow control. This number is platform dependent. The pxa_dma dma driver will use this value to activate or not the flow control.

There won't be any impact on mmp_pdma driver.

---
 include/linux/platform_data/mmp_dma.h |    1 +
 1 file changed, 1 insertion(+)

@@ -14,6 +14,7 @@
 
 struct mmp_dma_platdata {
 	int dma_channels;
+	int nb_requestors;
 };
 
 #endif /* MMP_DMA_H */

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Robert Jarzmik <[email protected]>

commit 72b195cb716284217e8b270af420bc7e5cf04b3c upstream.

Declare the number of DMA requestor lines per platform :
- for pxa25x: 40 requestor lines
- for pxa27x: 75 requestor lines
- for pxa3xx: 100 requestor lines

This information will be used to activate the DMA flow control or not.

---
 arch/arm/boot/dts/pxa27x.dtsi        |    1 +
 arch/arm/boot/dts/pxa3xx.dtsi        |    1 +
 arch/arm/mach-pxa/devices.c          |    3 ++-
 arch/arm/mach-pxa/pxa25x.c           |    2 +-
 arch/arm/mach-pxa/pxa27x.c           |    2 +-
 arch/arm/mach-pxa/pxa3xx.c           |    2 +-
 arch/arm/plat-pxa/include/plat/dma.h |    2 +-
 7 files changed, 8 insertions(+), 5 deletions(-)

@@ -13,6 +13,7 @@
 			interrupts = <25>;
 			#dma-channels = <32>;
 			#dma-cells = <2>;
+			#dma-requests = <75>;
 			status = "okay";
 		};
 

@@ -12,6 +12,7 @@
 			interrupts = <25>;
 			#dma-channels = <32>;
 			#dma-cells = <2>;
+			#dma-requests = <100>;
 			status = "okay";
 		};
 

@@ -1203,6 +1203,7 @@ void __init pxa2xx_set_spi_info(unsigned
 
 static struct mmp_dma_platdata pxa_dma_pdata = {
 	.dma_channels	= 0,
+	.nb_requestors	= 0,
 };
 
 static struct resource pxa_dma_resource[] = {

@@ -1231,7 +1232,7 @@ static struct platform_device pxa2xx_pxa
 	.resource	= pxa_dma_resource,
 };
 
-void __init pxa2xx_set_dmac_info(int nb_channels)
+void __init pxa2xx_set_dmac_info(int nb_channels, int nb_requestors)
 {
 	pxa_dma_pdata.dma_channels = nb_channels;
 	pxa_register_device(&pxa2xx_pxa_dma, &pxa_dma_pdata);

@@ -206,7 +206,7 @@ static int __init pxa25x_init(void)
 		register_syscore_ops(&pxa_irq_syscore_ops);
 		register_syscore_ops(&pxa2xx_mfp_syscore_ops);
 
-		pxa2xx_set_dmac_info(16);
+		pxa2xx_set_dmac_info(16, 40);
 		pxa_register_device(&pxa25x_device_gpio, &pxa25x_gpio_info);
 		ret = platform_add_devices(pxa25x_devices,
 					   ARRAY_SIZE(pxa25x_devices));

@@ -309,7 +309,7 @@ static int __init pxa27x_init(void)
 		if (!of_have_populated_dt()) {
 			pxa_register_device(&pxa27x_device_gpio,
 					    &pxa27x_gpio_info);
-			pxa2xx_set_dmac_info(32);
+			pxa2xx_set_dmac_info(32, 75);
 			ret = platform_add_devices(devices,
 						   ARRAY_SIZE(devices));
 		}

@@ -450,7 +450,7 @@ static int __init pxa3xx_init(void)
 		if (of_have_populated_dt())
 			return 0;
 
-		pxa2xx_set_dmac_info(32);
+		pxa2xx_set_dmac_info(32, 100);
 		ret = platform_add_devices(devices, ARRAY_SIZE(devices));
 		if (ret)
 			return ret;

@@ -95,6 +95,6 @@ static inline int pxad_toggle_reserved_c
 }
 #endif
 
-extern void __init pxa2xx_set_dmac_info(int nb_channels);
+extern void __init pxa2xx_set_dmac_info(int nb_channels, int nb_requestors);
 
 #endif /* __PLAT_DMA_H */

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Robert Jarzmik <[email protected]>

commit 4c35430ad18f5a034302cb90e559ede5a27f93b9 upstream.

The number of requestor lines was clamped to 0 for all pxa architectures in the requestor declaration. Fix this by using the value.

---
 arch/arm/mach-pxa/devices.c |    1 +
 1 file changed, 1 insertion(+)

@@ -1235,5 +1235,6 @@ static struct platform_device pxa2xx_pxa
 void __init pxa2xx_set_dmac_info(int nb_channels, int nb_requestors)
 {
 	pxa_dma_pdata.dma_channels = nb_channels;
+	pxa_dma_pdata.nb_requestors = nb_requestors;
 	pxa_register_device(&pxa2xx_pxa_dma, &pxa_dma_pdata);
 }

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paolo Bonzini <[email protected]>

commit c0a1666bcb2a33e84187a15eabdcd54056be9a97 upstream.

This fixes a compilation failure on 32-bit systems.

---
 arch/x86/kvm/vmx.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

@@ -2029,8 +2029,8 @@ static void vmx_vcpu_pi_load(struct kvm_
 
 		/* Allow posting non-urgent interrupts */
 		new.sn = 0;
-	} while (cmpxchg(&pi_desc->control, old.control,
-			new.control) != old.control);
+	} while (cmpxchg64(&pi_desc->control, old.control,
+			   new.control) != old.control);
 }
 /*
  * Switches to specified vcpu, until a matching vcpu_put(), but assumes

@@ -10705,8 +10705,8 @@ static int vmx_pre_block(struct kvm_vcpu
 
 		/* set 'NV' to 'wakeup vector' */
 		new.nv = POSTED_INTR_WAKEUP_VECTOR;
-	} while (cmpxchg(&pi_desc->control, old.control,
-			new.control) != old.control);
+	} while (cmpxchg64(&pi_desc->control, old.control,
+			   new.control) != old.control);
 
 	return 0;
 }

@@ -10737,8 +10737,8 @@ static void vmx_post_block(struct kvm_vc
 
 		/* set 'NV' to 'notification vector' */
 		new.nv = POSTED_INTR_VECTOR;
-	} while (cmpxchg(&pi_desc->control, old.control,
-			new.control) != old.control);
+	} while (cmpxchg64(&pi_desc->control, old.control,
+			   new.control) != old.control);
 
 	if(vcpu->pre_pcpu != -1) {
 		spin_lock_irqsave(

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vladis Dronov <[email protected]>

commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

'clk' is copied to a userland with padding byte(s) after 'vclk_post_div' field unitialized, leaking data from the stack. Fix this ensuring all of 'clk' is initialized to zero.

References: https://github.com/torvalds/linux/pull/441

---
 drivers/video/fbdev/aty/atyfb_base.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

@@ -1861,7 +1861,7 @@ static int atyfb_ioctl(struct fb_info *i
 #if defined(DEBUG) && defined(CONFIG_FB_ATY_CT)
 	case ATYIO_CLKR:
 		if (M64_HAS(INTEGRATED)) {
-			struct atyclk clk;
+			struct atyclk clk = { 0 };
 			union aty_pll *pll = &par->pll;
 			u32 dsp_config = pll->ct.dsp_config;
 			u32 dsp_on_off = pll->ct.dsp_on_off;

4.4-stable review patch. If anyone has any objections, please let me know.

------------------

From: Stefano Stabellini <[email protected]>

commit 7e91c7df29b5e196de3dc6f086c8937973bd0b88 upstream.

This function creates userspace mapping for the DMA-coherent memory.

---
 arch/arm/xen/mm.c         |    1 +
 drivers/xen/swiotlb-xen.c |   19 +++++++++++++++++++
 include/xen/swiotlb-xen.h |    5 +++++
 3 files changed, 25 insertions(+)

@@ -199,6 +199,7 @@ static struct dma_map_ops xen_swiotlb_dm
 	.unmap_page = xen_swiotlb_unmap_page,
 	.dma_supported = xen_swiotlb_dma_supported,
 	.set_dma_mask = xen_swiotlb_set_dma_mask,
+	.mmap = xen_swiotlb_dma_mmap,
 };
 
 int __init xen_mm_init(void)

@@ -680,3 +680,22 @@ xen_swiotlb_set_dma_mask(struct device *
 	return 0;
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_set_dma_mask);
+
+/*
+ * Create userspace mapping for the DMA-coherent memory.
+ * This function should be called with the pages from the current domain only,
+ * passing pages mapped from other domains would lead to memory corruption.
+ */
+int
+xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+		     void *cpu_addr, dma_addr_t dma_addr, size_t size,
+		     unsigned long attrs)
+{
+#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
+	if (__generic_dma_ops(dev)->mmap)
+		return __generic_dma_ops(dev)->mmap(dev, vma, cpu_addr,
+						    dma_addr, size, attrs);
+#endif
+	return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size);
+}
+EXPORT_SYMBOL_GPL(xen_swiotlb_dma_mmap);

@@ -58,4 +58,9 @@ xen_swiotlb_dma_supported(struct device
 
 extern int
 xen_swiotlb_set_dma_mask(struct device *dev, u64 dma_mask);
+
+extern int
+xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+		     void *cpu_addr, dma_addr_t dma_addr, size_t size,
+		     unsigned long attrs);
 #endif /* __LINUX_SWIOTLB_XEN_H */

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Test results from the linaro linux kernel functional test farm:

kernel: 4.4.90-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 255b4a073a820d2f46a1ce1740f1a9be3de9661a
git describe: v4.4.89-42-g255b4a073a82
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.89-42-g255b4a073a82

No regressions (compared to build v4.4.89-30-gb547584d016b)

Boards, architectures and test suites:
-------------------------------------

dell-poweredge-r200 - x86_64
* boot - 1 pass
* kselftest - 44 pass - 24 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-syscalls-tests - 941 pass - 175 skip - 11 known failures

And as a separate but related report, we have HiKey (arm64) results. These are separate because there are some out of tree patches that didn’t quite make 4.4 back in the day, thus for this board the kernel is a blend of the LTS RC + some platform patches.

Summary
------------------------------------------------------------------------

kernel: 4.4.90-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.90-rc1-hikey-20171003
git commit: 8b0848771d885b6030233931b2d2039382a1cf73
git describe: v4.4.89-352-g8b0848771d88
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/v4.4.89-352-g8b0848771d88

No regressions (compared to build v4.4.89-340-ga6279f8aa398)

Boards, architectures and test suites:
-------------------------------------

hi6220-hikey - arm64
* boot - 1 pass
* kselftest - 32 pass - 1 skip - 21 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-syscalls-tests - 960 pass - 138 skip - 2 known failures

Tom

Director, Linaro Mobile Group

Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall  

"Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian

Nice, thanks for letting me know, but that seems like a lot of "known failures" :(

Any chance you can add a beaglebone black to your 4.4 testing to give it some "native arm" test support? That should run a "stock" 4.4 kernel, right?

thanks,

greg k-h

Hi Greg,

Most of these failures result from our "mainline kselftest + lts kernel" combination - this is also visible from the failures seen on the x86 box as well.
We are working on getting these tests to not run on 4.4 specifically, as we see most such failures on these kernels.

Best,
Sumit.

Build results:

	total: 145 pass: 145 fail: 0
Qemu test results:
	total: 116 pass: 116 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter