The patch below does not apply to the 4.16-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d68f353fc9d086a88331d6714e437bd7f4f77f48 Mon Sep 17 00:00:00 2001
From: Steve French <smfrench(a)gmail.com>
Date: Tue, 13 Mar 2018 02:35:01 -0500
Subject: [PATCH] SMB3.1.1 dialect is no longer experimental
SMB3.1.1 is a very important dialect, with much improved security.
We can remove the ExPERIMENTAL comments about it. It is widely
supported by servers.
Signed-off-by: Steve French <smfrench(a)gmail.com>
CC: Stable <stable(a)vger.kernel.org>
diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig
index e901ef6a4813..741749a98614 100644
--- a/fs/cifs/Kconfig
+++ b/fs/cifs/Kconfig
@@ -187,14 +187,13 @@ config CIFS_NFSD_EXPORT
Allows NFS server to export a CIFS mounted share (nfsd over cifs)
config CIFS_SMB311
- bool "SMB3.1.1 network file system support (Experimental)"
+ bool "SMB3.1.1 network file system support"
depends on CIFS
select CRYPTO_SHA512
help
- This enables experimental support for the newest, SMB3.1.1, dialect.
- This dialect includes improved security negotiation features.
- If unsure, say N
+ This enables support for the newest, and most secure dialect, SMB3.11.
+ If unsure, say Y
config CIFS_SMB_DIRECT
bool "SMB Direct support (Experimental)"
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 7fafcfdf6377b18b2a726ea554d6e593ba44349f Mon Sep 17 00:00:00 2001
From: "Yavuz, Tuba" <tuba(a)ece.ufl.edu>
Date: Fri, 23 Mar 2018 17:00:38 +0000
Subject: [PATCH] USB: gadget: f_midi: fixing a possible double-free in f_midi
It looks like there is a possibility of a double-free vulnerability on an
error path of the f_midi_set_alt function in the f_midi driver. If the
path is feasible then free_ep_req gets called twice:
req->complete = f_midi_complete;
err = usb_ep_queue(midi->out_ep, req, GFP_ATOMIC);
=> ...
usb_gadget_giveback_request
=>
f_midi_complete (CALLBACK)
(inside f_midi_complete, for various cases of status)
free_ep_req(ep, req); // first kfree
if (err) {
ERROR(midi, "%s: couldn't enqueue request: %d\n",
midi->out_ep->name, err);
free_ep_req(midi->out_ep, req); // second kfree
return err;
}
The double-free possibility was introduced with commit ad0d1a058eac
("usb: gadget: f_midi: fix leak on failed to enqueue out requests").
Found by MOXCAFE tool.
Signed-off-by: Tuba Yavuz <tuba(a)ece.ufl.edu>
Fixes: ad0d1a058eac ("usb: gadget: f_midi: fix leak on failed to enqueue out requests")
Acked-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/gadget/function/f_midi.c b/drivers/usb/gadget/function/f_midi.c
index 4eb96b91cc40..e8f35db42394 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -404,7 +404,8 @@ static int f_midi_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
if (err) {
ERROR(midi, "%s: couldn't enqueue request: %d\n",
midi->out_ep->name, err);
- free_ep_req(midi->out_ep, req);
+ if (req->buf != NULL)
+ free_ep_req(midi->out_ep, req);
return err;
}
}
diff --git a/drivers/usb/gadget/u_f.h b/drivers/usb/gadget/u_f.h
index c3fbef2bb5db..09f90447fed5 100644
--- a/drivers/usb/gadget/u_f.h
+++ b/drivers/usb/gadget/u_f.h
@@ -61,7 +61,9 @@ struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len);
/* Frees a usb_request previously allocated by alloc_ep_req() */
static inline void free_ep_req(struct usb_ep *ep, struct usb_request *req)
{
+ WARN_ON(req->buf == NULL);
kfree(req->buf);
+ req->buf = NULL;
usb_ep_free_request(ep, req);
}
x86/xen: Delay get_cpu_cap until stack canary is established
Upstream commit 36104cb9012a82e73c32a3b709257766b16bcd1d
32bit Xen domains cannot boot without this patch. They crash early in
boot without output because they call into -f-stack-protector code
without the canary established. This patch re-orders code to avoid
that.
I've been running this patch on 4.14 and would like it applied there.
Regards,
Jason
From: Roland Dreier <roland(a)purestorage.com>
The RDMA CM will select a source device and address by consulting the routing table
if no source address is passed into rdma_resolve_address(). Userspace will ask for
this by passing an all-zero source address in the RESOLVE_IP command. Unfortunately
the new check for non-zero address size rejects this with EINVAL, which breaks valid
userspace applications.
Fix this by explicitly allowing a zero address family for the source.
Fixes: 2975d5de6428 ("RDMA/ucma: Check AF family prior resolving address")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Roland Dreier <roland(a)purestorage.com>
---
drivers/infiniband/core/ucma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
index 74329483af6d..0a7242ce7c1f 100644
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -683,7 +683,7 @@ static ssize_t ucma_resolve_ip(struct ucma_file *file,
if (copy_from_user(&cmd, inbuf, sizeof(cmd)))
return -EFAULT;
- if (!rdma_addr_size_in6(&cmd.src_addr) ||
+ if ((cmd.src_addr.sin6_family && !rdma_addr_size_in6(&cmd.src_addr)) ||
!rdma_addr_size_in6(&cmd.dst_addr))
return -EINVAL;
--
2.17.0