From: Eric Biggers <ebiggers(a)google.com>
commit 4dca6ea1d9432052afb06baf2e3ae78188a4410b upstream.
[Please apply to 4.4-stable.]
When the request_key() syscall is not passed a destination keyring, it
links the requested key (if constructed) into the "default" request-key
keyring. This should require Write permission to the keyring. However,
there is actually no permission check.
This can be abused to add keys to any keyring to which only Search
permission is granted. This is because Search permission allows joining
the keyring. keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_SESSION_KEYRING)
then will set the default request-key keyring to the session keyring.
Then, request_key() can be used to add keys to the keyring.
Both negatively and positively instantiated keys can be added using this
method. Adding negative keys is trivial. Adding a positive key is a
bit trickier. It requires that either /sbin/request-key positively
instantiates the key, or that another thread adds the key to the process
keyring at just the right time, such that request_key() misses it
initially but then finds it in construct_alloc_key().
Fix this bug by checking for Write permission to the keyring in
construct_get_dest_keyring() when the default keyring is being used.
We don't do the permission check for non-default keyrings because that
was already done by the earlier call to lookup_user_key(). Also,
request_key_and_link() is currently passed a 'struct key *' rather than
a key_ref_t, so the "possessed" bit is unavailable.
We also don't do the permission check for the "requestor keyring", to
continue to support the use case described by commit 8bbf4976b59f
("KEYS: Alter use of key instantiation link-to-keyring argument") where
/sbin/request-key recursively calls request_key() to add keys to the
original requestor's destination keyring. (I don't know of any users
who actually do that, though...)
Fixes: 3e30148c3d52 ("[PATCH] Keys: Make request-key create an authorisation key")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
---
security/keys/request_key.c | 48 +++++++++++++++++++++++++++++++++++----------
1 file changed, 38 insertions(+), 10 deletions(-)
diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index 2ce733342b5a..3ae3acf473c8 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -250,11 +250,12 @@ static int construct_key(struct key *key, const void *callout_info,
* The keyring selected is returned with an extra reference upon it which the
* caller must release.
*/
-static void construct_get_dest_keyring(struct key **_dest_keyring)
+static int construct_get_dest_keyring(struct key **_dest_keyring)
{
struct request_key_auth *rka;
const struct cred *cred = current_cred();
struct key *dest_keyring = *_dest_keyring, *authkey;
+ int ret;
kenter("%p", dest_keyring);
@@ -263,6 +264,8 @@ static void construct_get_dest_keyring(struct key **_dest_keyring)
/* the caller supplied one */
key_get(dest_keyring);
} else {
+ bool do_perm_check = true;
+
/* use a default keyring; falling through the cases until we
* find one that we actually have */
switch (cred->jit_keyring) {
@@ -277,8 +280,10 @@ static void construct_get_dest_keyring(struct key **_dest_keyring)
dest_keyring =
key_get(rka->dest_keyring);
up_read(&authkey->sem);
- if (dest_keyring)
+ if (dest_keyring) {
+ do_perm_check = false;
break;
+ }
}
case KEY_REQKEY_DEFL_THREAD_KEYRING:
@@ -313,11 +318,29 @@ static void construct_get_dest_keyring(struct key **_dest_keyring)
default:
BUG();
}
+
+ /*
+ * Require Write permission on the keyring. This is essential
+ * because the default keyring may be the session keyring, and
+ * joining a keyring only requires Search permission.
+ *
+ * However, this check is skipped for the "requestor keyring" so
+ * that /sbin/request-key can itself use request_key() to add
+ * keys to the original requestor's destination keyring.
+ */
+ if (dest_keyring && do_perm_check) {
+ ret = key_permission(make_key_ref(dest_keyring, 1),
+ KEY_NEED_WRITE);
+ if (ret) {
+ key_put(dest_keyring);
+ return ret;
+ }
+ }
}
*_dest_keyring = dest_keyring;
kleave(" [dk %d]", key_serial(dest_keyring));
- return;
+ return 0;
}
/*
@@ -442,12 +465,16 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx,
if (ctx->index_key.type == &key_type_keyring)
return ERR_PTR(-EPERM);
-
- user = key_user_lookup(current_fsuid());
- if (!user)
- return ERR_PTR(-ENOMEM);
- construct_get_dest_keyring(&dest_keyring);
+ ret = construct_get_dest_keyring(&dest_keyring);
+ if (ret)
+ goto error;
+
+ user = key_user_lookup(current_fsuid());
+ if (!user) {
+ ret = -ENOMEM;
+ goto error_put_dest_keyring;
+ }
ret = construct_alloc_key(ctx, dest_keyring, flags, user, &key);
key_user_put(user);
@@ -462,7 +489,7 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx,
} else if (ret == -EINPROGRESS) {
ret = 0;
} else {
- goto couldnt_alloc_key;
+ goto error_put_dest_keyring;
}
key_put(dest_keyring);
@@ -472,8 +499,9 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx,
construction_failed:
key_negate_and_link(key, key_negative_timeout, NULL, NULL);
key_put(key);
-couldnt_alloc_key:
+error_put_dest_keyring:
key_put(dest_keyring);
+error:
kleave(" = %d", ret);
return ERR_PTR(ret);
}
--
2.15.1.504.g5279b80103-goog
From: David Howells <dhowells(a)redhat.com>
commit 911b79cde95c7da0ec02f48105358a36636b7a71 upstream.
[Please apply to 3.18-stable and 4.1-stable.]
If request_key() is used to find a keyring, only do the search part - don't
do the construction part if the keyring was not found by the search. We
don't really want keyrings in the negative instantiated state since the
rejected/negative instantiation error value in the payload is unioned with
keyring metadata.
Now the kernel gives an error:
request_key("keyring", "#selinux,bdekeyring", "keyring", KEY_SPEC_USER_SESSION_KEYRING) = -1 EPERM (Operation not permitted)
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
security/keys/request_key.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index 486ef6fa393b..0d6253124278 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -440,6 +440,9 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx,
kenter("");
+ if (ctx->index_key.type == &key_type_keyring)
+ return ERR_PTR(-EPERM);
+
user = key_user_lookup(current_fsuid());
if (!user)
return ERR_PTR(-ENOMEM);
--
2.15.1.504.g5279b80103-goog
From: David Jeffery <djeffery(a)redhat.com>
commit d0709f1e66e8066c4ac6a54620ec116aa41937c0 upstream.
[Please apply to 3.18-stable.]
If a request_key() call to allocate and fill out a key attempts to insert the
key structure into a revoked keyring, the key will leak, using memory and part
of the user's key quota until the system reboots. This is from a failure of
construct_alloc_key() to decrement the key's reference count after the attempt
to insert into the requested keyring is rejected.
key_put() needs to be called in the link_prealloc_failed callpath to ensure
the unused key is released.
Signed-off-by: David Jeffery <djeffery(a)redhat.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
security/keys/request_key.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index 8117a774ee5d..edc367ef0bd6 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -437,6 +437,7 @@ link_check_failed:
link_prealloc_failed:
mutex_unlock(&user->cons_lock);
+ key_put(key);
kleave(" = %d [prelink]", ret);
return ret;
--
2.15.1.504.g5279b80103-goog
This is a note to let you know that I've just added the patch titled
xhci: Don't add a virt_dev to the devs array before it's fully allocated
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xhci-don-t-add-a-virt_dev-to-the-devs-array-before-it-s-fully-allocated.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5d9b70f7d52eb14bb37861c663bae44de9521c35 Mon Sep 17 00:00:00 2001
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Date: Fri, 8 Dec 2017 18:10:05 +0200
Subject: xhci: Don't add a virt_dev to the devs array before it's fully allocated
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
commit 5d9b70f7d52eb14bb37861c663bae44de9521c35 upstream.
Avoid null pointer dereference if some function is walking through the
devs array accessing members of a new virt_dev that is mid allocation.
Add the virt_dev to xhci->devs[i] _after_ the virt_device and all its
members are properly allocated.
issue found by KASAN: null-ptr-deref in xhci_find_slot_id_by_port
"Quick analysis suggests that xhci_alloc_virt_device() is not mutex
protected. If so, there is a time frame where xhci->devs[slot_id] is set
but not fully initialized. Specifically, xhci->devs[i]->udev can be NULL."
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci-mem.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1032,10 +1032,9 @@ int xhci_alloc_virt_device(struct xhci_h
return 0;
}
- xhci->devs[slot_id] = kzalloc(sizeof(*xhci->devs[slot_id]), flags);
- if (!xhci->devs[slot_id])
+ dev = kzalloc(sizeof(*dev), flags);
+ if (!dev)
return 0;
- dev = xhci->devs[slot_id];
/* Allocate the (output) device context that will be used in the HC. */
dev->out_ctx = xhci_alloc_container_ctx(xhci, XHCI_CTX_TYPE_DEVICE, flags);
@@ -1083,9 +1082,17 @@ int xhci_alloc_virt_device(struct xhci_h
&xhci->dcbaa->dev_context_ptrs[slot_id],
le64_to_cpu(xhci->dcbaa->dev_context_ptrs[slot_id]));
+ xhci->devs[slot_id] = dev;
+
return 1;
fail:
- xhci_free_virt_device(xhci, slot_id);
+
+ if (dev->in_ctx)
+ xhci_free_container_ctx(xhci, dev->in_ctx);
+ if (dev->out_ctx)
+ xhci_free_container_ctx(xhci, dev->out_ctx);
+ kfree(dev);
+
return 0;
}
Patches currently in stable-queue which might be from mathias.nyman(a)linux.intel.com are
queue-4.9/usb-xhci-fix-tds-for-mtk-xhci1.1.patch
queue-4.9/xhci-don-t-add-a-virt_dev-to-the-devs-array-before-it-s-fully-allocated.patch
This is a note to let you know that I've just added the patch titled
usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-fix-stub_send_ret_submit-vulnerability-to-null-transfer_buffer.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From be6123df1ea8f01ee2f896a16c2b7be3e4557a5a Mon Sep 17 00:00:00 2001
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Thu, 7 Dec 2017 14:16:50 -0700
Subject: usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer
From: Shuah Khan <shuahkh(a)osg.samsung.com>
commit be6123df1ea8f01ee2f896a16c2b7be3e4557a5a upstream.
stub_send_ret_submit() handles urb with a potential null transfer_buffer,
when it replays a packet with potential malicious data that could contain
a null buffer. Add a check for the condition when actual_length > 0 and
transfer_buffer is null.
Reported-by: Secunia Research <vuln(a)secunia.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/stub_tx.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/usb/usbip/stub_tx.c
+++ b/drivers/usb/usbip/stub_tx.c
@@ -181,6 +181,13 @@ static int stub_send_ret_submit(struct s
memset(&pdu_header, 0, sizeof(pdu_header));
memset(&msg, 0, sizeof(msg));
+ if (urb->actual_length > 0 && !urb->transfer_buffer) {
+ dev_err(&sdev->udev->dev,
+ "urb: actual_length %d transfer_buffer null\n",
+ urb->actual_length);
+ return -1;
+ }
+
if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS)
iovnum = 2 + urb->number_of_packets;
else
Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are
queue-4.9/usbip-fix-stub_rx-harden-cmd_submit-path-to-handle-malicious-input.patch
queue-4.9/usbip-fix-stub_send_ret_submit-vulnerability-to-null-transfer_buffer.patch
queue-4.9/usbip-fix-stub_rx-get_pipe-to-validate-endpoint-number.patch
This is a note to let you know that I've just added the patch titled
usb: xhci: fix TDS for MTK xHCI1.1
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-xhci-fix-tds-for-mtk-xhci1.1.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 72b663a99c074a8d073e7ecdae446cfb024ef551 Mon Sep 17 00:00:00 2001
From: Chunfeng Yun <chunfeng.yun(a)mediatek.com>
Date: Fri, 8 Dec 2017 18:10:06 +0200
Subject: usb: xhci: fix TDS for MTK xHCI1.1
From: Chunfeng Yun <chunfeng.yun(a)mediatek.com>
commit 72b663a99c074a8d073e7ecdae446cfb024ef551 upstream.
For MTK's xHCI 1.0 or latter, TD size is the number of max
packet sized packets remaining in the TD, not including
this TRB (following spec).
For MTK's xHCI 0.96 and older, TD size is the number of max
packet sized packets remaining in the TD, including this TRB
(not following spec).
Signed-off-by: Chunfeng Yun <chunfeng.yun(a)mediatek.com>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci-ring.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3132,7 +3132,7 @@ static u32 xhci_td_remainder(struct xhci
{
u32 maxp, total_packet_count;
- /* MTK xHCI is mostly 0.97 but contains some features from 1.0 */
+ /* MTK xHCI 0.96 contains some features from 1.0 */
if (xhci->hci_version < 0x100 && !(xhci->quirks & XHCI_MTK_HOST))
return ((td_total_len - transferred) >> 10);
@@ -3141,8 +3141,8 @@ static u32 xhci_td_remainder(struct xhci
trb_buff_len == td_total_len)
return 0;
- /* for MTK xHCI, TD size doesn't include this TRB */
- if (xhci->quirks & XHCI_MTK_HOST)
+ /* for MTK xHCI 0.96, TD size include this TRB, but not in 1.x */
+ if ((xhci->quirks & XHCI_MTK_HOST) && (xhci->hci_version < 0x100))
trb_buff_len = 0;
maxp = GET_MAX_PACKET(usb_endpoint_maxp(&urb->ep->desc));
Patches currently in stable-queue which might be from chunfeng.yun(a)mediatek.com are
queue-4.9/usb-xhci-fix-tds-for-mtk-xhci1.1.patch
This is a note to let you know that I've just added the patch titled
usbip: fix stub_rx: get_pipe() to validate endpoint number
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-fix-stub_rx-get_pipe-to-validate-endpoint-number.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 635f545a7e8be7596b9b2b6a43cab6bbd5a88e43 Mon Sep 17 00:00:00 2001
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Thu, 7 Dec 2017 14:16:47 -0700
Subject: usbip: fix stub_rx: get_pipe() to validate endpoint number
From: Shuah Khan <shuahkh(a)osg.samsung.com>
commit 635f545a7e8be7596b9b2b6a43cab6bbd5a88e43 upstream.
get_pipe() routine doesn't validate the input endpoint number
and uses to reference ep_in and ep_out arrays. Invalid endpoint
number can trigger BUG(). Range check the epnum and returning
error instead of calling BUG().
Change caller stub_recv_cmd_submit() to handle the get_pipe()
error return.
Reported-by: Secunia Research <vuln(a)secunia.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/stub_rx.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -342,15 +342,15 @@ static int get_pipe(struct stub_device *
struct usb_host_endpoint *ep;
struct usb_endpoint_descriptor *epd = NULL;
+ if (epnum < 0 || epnum > 15)
+ goto err_ret;
+
if (dir == USBIP_DIR_IN)
ep = udev->ep_in[epnum & 0x7f];
else
ep = udev->ep_out[epnum & 0x7f];
- if (!ep) {
- dev_err(&sdev->udev->dev, "no such endpoint?, %d\n",
- epnum);
- BUG();
- }
+ if (!ep)
+ goto err_ret;
epd = &ep->desc;
if (usb_endpoint_xfer_control(epd)) {
@@ -381,9 +381,10 @@ static int get_pipe(struct stub_device *
return usb_rcvisocpipe(udev, epnum);
}
+err_ret:
/* NOT REACHED */
- dev_err(&sdev->udev->dev, "get pipe, epnum %d\n", epnum);
- return 0;
+ dev_err(&sdev->udev->dev, "get pipe() invalid epnum %d\n", epnum);
+ return -1;
}
static void masking_bogus_flags(struct urb *urb)
@@ -449,6 +450,9 @@ static void stub_recv_cmd_submit(struct
struct usb_device *udev = sdev->udev;
int pipe = get_pipe(sdev, pdu->base.ep, pdu->base.direction);
+ if (pipe == -1)
+ return;
+
priv = stub_priv_alloc(sdev, pdu);
if (!priv)
return;
Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are
queue-4.9/usbip-fix-stub_rx-harden-cmd_submit-path-to-handle-malicious-input.patch
queue-4.9/usbip-fix-stub_send_ret_submit-vulnerability-to-null-transfer_buffer.patch
queue-4.9/usbip-fix-stub_rx-get_pipe-to-validate-endpoint-number.patch
This is a note to let you know that I've just added the patch titled
USB: core: prevent malicious bNumInterfaces overflow
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-core-prevent-malicious-bnuminterfaces-overflow.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 48a4ff1c7bb5a32d2e396b03132d20d552c0eca7 Mon Sep 17 00:00:00 2001
From: Alan Stern <stern(a)rowland.harvard.edu>
Date: Tue, 12 Dec 2017 14:25:13 -0500
Subject: USB: core: prevent malicious bNumInterfaces overflow
From: Alan Stern <stern(a)rowland.harvard.edu>
commit 48a4ff1c7bb5a32d2e396b03132d20d552c0eca7 upstream.
A malicious USB device with crafted descriptors can cause the kernel
to access unallocated memory by setting the bNumInterfaces value too
high in a configuration descriptor. Although the value is adjusted
during parsing, this adjustment is skipped in one of the error return
paths.
This patch prevents the problem by setting bNumInterfaces to 0
initially. The existing code already sets it to the proper value
after parsing is complete.
Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/config.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -550,6 +550,9 @@ static int usb_parse_configuration(struc
unsigned iad_num = 0;
memcpy(&config->desc, buffer, USB_DT_CONFIG_SIZE);
+ nintf = nintf_orig = config->desc.bNumInterfaces;
+ config->desc.bNumInterfaces = 0; // Adjusted later
+
if (config->desc.bDescriptorType != USB_DT_CONFIG ||
config->desc.bLength < USB_DT_CONFIG_SIZE ||
config->desc.bLength > size) {
@@ -563,7 +566,6 @@ static int usb_parse_configuration(struc
buffer += config->desc.bLength;
size -= config->desc.bLength;
- nintf = nintf_orig = config->desc.bNumInterfaces;
if (nintf > USB_MAXINTERFACES) {
dev_warn(ddev, "config %d has too many interfaces: %d, "
"using maximum allowed: %d\n",
Patches currently in stable-queue which might be from stern(a)rowland.harvard.edu are
queue-4.9/usb-core-prevent-malicious-bnuminterfaces-overflow.patch
queue-4.9/usb-uas-and-storage-add-us_fl_broken_fua-for-another-jmicron-jms567-id.patch
This is a note to let you know that I've just added the patch titled
USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-uas-and-storage-add-us_fl_broken_fua-for-another-jmicron-jms567-id.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 62354454625741f0569c2cbe45b2d192f8fd258e Mon Sep 17 00:00:00 2001
From: David Kozub <zub(a)linux.fjfi.cvut.cz>
Date: Tue, 5 Dec 2017 22:40:04 +0100
Subject: USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID
From: David Kozub <zub(a)linux.fjfi.cvut.cz>
commit 62354454625741f0569c2cbe45b2d192f8fd258e upstream.
There is another JMS567-based USB3 UAS enclosure (152d:0578) that fails
with the following error:
[sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[sda] tag#0 Sense Key : Illegal Request [current]
[sda] tag#0 Add. Sense: Invalid field in cdb
The issue occurs both with UAS (occasionally) and mass storage
(immediately after mounting a FS on a disk in the enclosure).
Enabling US_FL_BROKEN_FUA quirk solves this issue.
This patch adds an UNUSUAL_DEV with US_FL_BROKEN_FUA for the enclosure
for both UAS and mass storage.
Signed-off-by: David Kozub <zub(a)linux.fjfi.cvut.cz>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/unusual_devs.h | 7 +++++++
drivers/usb/storage/unusual_uas.h | 7 +++++++
2 files changed, 14 insertions(+)
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2113,6 +2113,13 @@ UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_BROKEN_FUA ),
+/* Reported by David Kozub <zub(a)linux.fjfi.cvut.cz> */
+UNUSUAL_DEV(0x152d, 0x0578, 0x0000, 0x9999,
+ "JMicron",
+ "JMS567",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BROKEN_FUA),
+
/*
* Reported by Alexandre Oliva <oliva(a)lsd.ic.unicamp.br>
* JMicron responds to USN and several other SCSI ioctls with a
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -142,6 +142,13 @@ UNUSUAL_DEV(0x152d, 0x0567, 0x0000, 0x99
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_BROKEN_FUA | US_FL_NO_REPORT_OPCODES),
+/* Reported-by: David Kozub <zub(a)linux.fjfi.cvut.cz> */
+UNUSUAL_DEV(0x152d, 0x0578, 0x0000, 0x9999,
+ "JMicron",
+ "JMS567",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BROKEN_FUA),
+
/* Reported-by: Hans de Goede <hdegoede(a)redhat.com> */
UNUSUAL_DEV(0x2109, 0x0711, 0x0000, 0x9999,
"VIA",
Patches currently in stable-queue which might be from zub(a)linux.fjfi.cvut.cz are
queue-4.9/usb-uas-and-storage-add-us_fl_broken_fua-for-another-jmicron-jms567-id.patch
This is a note to let you know that I've just added the patch titled
sched/rt: Do not pull from current CPU if only one CPU to pull
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sched-rt-do-not-pull-from-current-cpu-if-only-one-cpu-to-pull.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f73c52a5bcd1710994e53fbccc378c42b97a06b6 Mon Sep 17 00:00:00 2001
From: Steven Rostedt <rostedt(a)goodmis.org>
Date: Sat, 2 Dec 2017 13:04:54 -0500
Subject: sched/rt: Do not pull from current CPU if only one CPU to pull
From: Steven Rostedt <rostedt(a)goodmis.org>
commit f73c52a5bcd1710994e53fbccc378c42b97a06b6 upstream.
Daniel Wagner reported a crash on the BeagleBone Black SoC.
This is a single CPU architecture, and does not have a functional
arch_send_call_function_single_ipi() implementation which can crash
the kernel if that is called.
As it only has one CPU, it shouldn't be called, but if the kernel is
compiled for SMP, the push/pull RT scheduling logic now calls it for
irq_work if the one CPU is overloaded, it can use that function to call
itself and crash the kernel.
Ideally, we should disable the SCHED_FEAT(RT_PUSH_IPI) if the system
only has a single CPU. But SCHED_FEAT is a constant if sched debugging
is turned off. Another fix can also be used, and this should also help
with normal SMP machines. That is, do not initiate the pull code if
there's only one RT overloaded CPU, and that CPU happens to be the
current CPU that is scheduling in a lower priority task.
Even on a system with many CPUs, if there's many RT tasks waiting to
run on a single CPU, and that CPU schedules in another RT task of lower
priority, it will initiate the PULL logic in case there's a higher
priority RT task on another CPU that is waiting to run. But if there is
no other CPU with waiting RT tasks, it will initiate the RT pull logic
on itself (as it still has RT tasks waiting to run). This is a wasted
effort.
Not only does this help with SMP code where the current CPU is the only
one with RT overloaded tasks, it should also solve the issue that
Daniel encountered, because it will prevent the PULL logic from
executing, as there's only one CPU on the system, and the check added
here will cause it to exit the RT pull code.
Reported-by: Daniel Wagner <wagi(a)monom.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Acked-by: Peter Zijlstra <peterz(a)infradead.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-rt-users <linux-rt-users(a)vger.kernel.org>
Fixes: 4bdced5c9 ("sched/rt: Simplify the IPI based RT balancing logic")
Link: http://lkml.kernel.org/r/20171202130454.4cbbfe8d@vmware.local.home
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/sched/rt.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2022,8 +2022,9 @@ static void pull_rt_task(struct rq *this
bool resched = false;
struct task_struct *p;
struct rq *src_rq;
+ int rt_overload_count = rt_overloaded(this_rq);
- if (likely(!rt_overloaded(this_rq)))
+ if (likely(!rt_overload_count))
return;
/*
@@ -2032,6 +2033,11 @@ static void pull_rt_task(struct rq *this
*/
smp_rmb();
+ /* If we are the only overloaded CPU do nothing */
+ if (rt_overload_count == 1 &&
+ cpumask_test_cpu(this_rq->cpu, this_rq->rd->rto_mask))
+ return;
+
#ifdef HAVE_RT_PUSH_IPI
if (sched_feat(RT_PUSH_IPI)) {
tell_cpu_to_push(this_rq);
Patches currently in stable-queue which might be from rostedt(a)goodmis.org are
queue-4.9/sched-rt-do-not-pull-from-current-cpu-if-only-one-cpu-to-pull.patch
queue-4.9/tracing-allocate-mask_str-buffer-dynamically.patch
This is a note to let you know that I've just added the patch titled
tracing: Allocate mask_str buffer dynamically
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tracing-allocate-mask_str-buffer-dynamically.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 90e406f96f630c07d631a021fd4af10aac913e77 Mon Sep 17 00:00:00 2001
From: Changbin Du <changbin.du(a)intel.com>
Date: Thu, 30 Nov 2017 11:39:43 +0800
Subject: tracing: Allocate mask_str buffer dynamically
From: Changbin Du <changbin.du(a)intel.com>
commit 90e406f96f630c07d631a021fd4af10aac913e77 upstream.
The default NR_CPUS can be very large, but actual possible nr_cpu_ids
usually is very small. For my x86 distribution, the NR_CPUS is 8192 and
nr_cpu_ids is 4. About 2 pages are wasted.
Most machines don't have so many CPUs, so define a array with NR_CPUS
just wastes memory. So let's allocate the buffer dynamically when need.
With this change, the mutext tracing_cpumask_update_lock also can be
removed now, which was used to protect mask_str.
Link: http://lkml.kernel.org/r/1512013183-19107-1-git-send-email-changbin.du@inte…
Fixes: 36dfe9252bd4c ("ftrace: make use of tracing_cpumask")
Signed-off-by: Changbin Du <changbin.du(a)intel.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/trace/trace.c | 29 +++++++++--------------------
1 file changed, 9 insertions(+), 20 deletions(-)
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3727,37 +3727,30 @@ static const struct file_operations show
.llseek = seq_lseek,
};
-/*
- * The tracer itself will not take this lock, but still we want
- * to provide a consistent cpumask to user-space:
- */
-static DEFINE_MUTEX(tracing_cpumask_update_lock);
-
-/*
- * Temporary storage for the character representation of the
- * CPU bitmask (and one more byte for the newline):
- */
-static char mask_str[NR_CPUS + 1];
-
static ssize_t
tracing_cpumask_read(struct file *filp, char __user *ubuf,
size_t count, loff_t *ppos)
{
struct trace_array *tr = file_inode(filp)->i_private;
+ char *mask_str;
int len;
- mutex_lock(&tracing_cpumask_update_lock);
+ len = snprintf(NULL, 0, "%*pb\n",
+ cpumask_pr_args(tr->tracing_cpumask)) + 1;
+ mask_str = kmalloc(len, GFP_KERNEL);
+ if (!mask_str)
+ return -ENOMEM;
- len = snprintf(mask_str, count, "%*pb\n",
+ len = snprintf(mask_str, len, "%*pb\n",
cpumask_pr_args(tr->tracing_cpumask));
if (len >= count) {
count = -EINVAL;
goto out_err;
}
- count = simple_read_from_buffer(ubuf, count, ppos, mask_str, NR_CPUS+1);
+ count = simple_read_from_buffer(ubuf, count, ppos, mask_str, len);
out_err:
- mutex_unlock(&tracing_cpumask_update_lock);
+ kfree(mask_str);
return count;
}
@@ -3777,8 +3770,6 @@ tracing_cpumask_write(struct file *filp,
if (err)
goto err_unlock;
- mutex_lock(&tracing_cpumask_update_lock);
-
local_irq_disable();
arch_spin_lock(&tr->max_lock);
for_each_tracing_cpu(cpu) {
@@ -3801,8 +3792,6 @@ tracing_cpumask_write(struct file *filp,
local_irq_enable();
cpumask_copy(tr->tracing_cpumask, tracing_cpumask_new);
-
- mutex_unlock(&tracing_cpumask_update_lock);
free_cpumask_var(tracing_cpumask_new);
return count;
Patches currently in stable-queue which might be from changbin.du(a)intel.com are
queue-4.9/tracing-allocate-mask_str-buffer-dynamically.patch
This is a note to let you know that I've just added the patch titled
nfs: don't wait on commit in nfs_commit_inode() if there were no commit requests
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfs-don-t-wait-on-commit-in-nfs_commit_inode-if-there-were-no-commit-requests.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From dc4fd9ab01ab379ae5af522b3efd4187a7c30a31 Mon Sep 17 00:00:00 2001
From: Scott Mayhew <smayhew(a)redhat.com>
Date: Fri, 8 Dec 2017 16:00:12 -0500
Subject: nfs: don't wait on commit in nfs_commit_inode() if there were no commit requests
From: Scott Mayhew <smayhew(a)redhat.com>
commit dc4fd9ab01ab379ae5af522b3efd4187a7c30a31 upstream.
If there were no commit requests, then nfs_commit_inode() should not
wait on the commit or mark the inode dirty, otherwise the following
BUG_ON can be triggered:
[ 1917.130762] kernel BUG at fs/inode.c:578!
[ 1917.130766] Oops: Exception in kernel mode, sig: 5 [#1]
[ 1917.130768] SMP NR_CPUS=2048 NUMA pSeries
[ 1917.130772] Modules linked in: iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi blocklayoutdriver rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache sunrpc sg nx_crypto pseries_rng ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic crct10dif_common ibmvscsi scsi_transport_srp ibmveth scsi_tgt dm_mirror dm_region_hash dm_log dm_mod
[ 1917.130805] CPU: 2 PID: 14923 Comm: umount.nfs4 Tainted: G ------------ T 3.10.0-768.el7.ppc64 #1
[ 1917.130810] task: c0000005ecd88040 ti: c00000004cea0000 task.ti: c00000004cea0000
[ 1917.130813] NIP: c000000000354178 LR: c000000000354160 CTR: c00000000012db80
[ 1917.130816] REGS: c00000004cea3720 TRAP: 0700 Tainted: G ------------ T (3.10.0-768.el7.ppc64)
[ 1917.130820] MSR: 8000000100029032 <SF,EE,ME,IR,DR,RI> CR: 22002822 XER: 20000000
[ 1917.130828] CFAR: c00000000011f594 SOFTE: 1
GPR00: c000000000354160 c00000004cea39a0 c0000000014c4700 c0000000018cc750
GPR04: 000000000000c750 80c0000000000000 0600000000000000 04eeb76bea749a03
GPR08: 0000000000000034 c0000000018cc758 0000000000000001 d000000005e619e8
GPR12: c00000000012db80 c000000007b31200 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: 0000000000000000 c000000000dfc3ec 0000000000000000 c0000005eefc02c0
GPR28: d0000000079dbd50 c0000005b94a02c0 c0000005b94a0250 c0000005b94a01c8
[ 1917.130867] NIP [c000000000354178] .evict+0x1c8/0x350
[ 1917.130871] LR [c000000000354160] .evict+0x1b0/0x350
[ 1917.130873] Call Trace:
[ 1917.130876] [c00000004cea39a0] [c000000000354160] .evict+0x1b0/0x350 (unreliable)
[ 1917.130880] [c00000004cea3a30] [c0000000003558cc] .evict_inodes+0x13c/0x270
[ 1917.130884] [c00000004cea3af0] [c000000000327d20] .kill_anon_super+0x70/0x1e0
[ 1917.130896] [c00000004cea3b80] [d000000005e43e30] .nfs_kill_super+0x20/0x60 [nfs]
[ 1917.130900] [c00000004cea3c00] [c000000000328a20] .deactivate_locked_super+0xa0/0x1b0
[ 1917.130903] [c00000004cea3c80] [c00000000035ba54] .cleanup_mnt+0xd4/0x180
[ 1917.130907] [c00000004cea3d10] [c000000000119034] .task_work_run+0x114/0x150
[ 1917.130912] [c00000004cea3db0] [c00000000001ba6c] .do_notify_resume+0xcc/0x100
[ 1917.130916] [c00000004cea3e30] [c00000000000a7b0] .ret_from_except_lite+0x5c/0x60
[ 1917.130919] Instruction dump:
[ 1917.130921] 7fc3f378 486734b5 60000000 387f00a0 38800003 4bdcb365 60000000 e95f00a0
[ 1917.130927] 694a0060 7d4a0074 794ad182 694a0001 <0b0a0000> 892d02a4 2f890000 40de0134
Signed-off-by: Scott Mayhew <smayhew(a)redhat.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/write.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1859,6 +1859,8 @@ int nfs_commit_inode(struct inode *inode
if (res)
error = nfs_generic_commit_list(inode, &head, how, &cinfo);
nfs_commit_end(cinfo.mds);
+ if (res == 0)
+ return res;
if (error < 0)
goto out_error;
if (!may_wait)
Patches currently in stable-queue which might be from smayhew(a)redhat.com are
queue-4.9/nfs-don-t-wait-on-commit-in-nfs_commit_inode-if-there-were-no-commit-requests.patch
This is a note to let you know that I've just added the patch titled
ext4: fix fdatasync(2) after fallocate(2) operation
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ext4-fix-fdatasync-2-after-fallocate-2-operation.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c894aa97577e47d3066b27b32499ecf899bfa8b0 Mon Sep 17 00:00:00 2001
From: Eryu Guan <eguan(a)redhat.com>
Date: Sun, 3 Dec 2017 22:52:51 -0500
Subject: ext4: fix fdatasync(2) after fallocate(2) operation
From: Eryu Guan <eguan(a)redhat.com>
commit c894aa97577e47d3066b27b32499ecf899bfa8b0 upstream.
Currently, fallocate(2) with KEEP_SIZE followed by a fdatasync(2)
then crash, we'll see wrong allocated block number (stat -c %b), the
blocks allocated beyond EOF are all lost. fstests generic/468
exposes this bug.
Commit 67a7d5f561f4 ("ext4: fix fdatasync(2) after extent
manipulation operations") fixed all the other extent manipulation
operation paths such as hole punch, zero range, collapse range etc.,
but forgot the fallocate case.
So similarly, fix it by recording the correct journal tid in ext4
inode in fallocate(2) path, so that ext4_sync_file() will wait for
the right tid to be committed on fdatasync(2).
This addresses the test failure in xfstests test generic/468.
Signed-off-by: Eryu Guan <eguan(a)redhat.com>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ext4/extents.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4731,6 +4731,7 @@ retry:
EXT4_INODE_EOFBLOCKS);
}
ext4_mark_inode_dirty(handle, inode);
+ ext4_update_inode_fsync_trans(handle, inode, 1);
ret2 = ext4_journal_stop(handle);
if (ret2)
break;
Patches currently in stable-queue which might be from eguan(a)redhat.com are
queue-4.9/ext4-fix-fdatasync-2-after-fallocate-2-operation.patch
This is a note to let you know that I've just added the patch titled
ext4: fix crash when a directory's i_size is too small
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ext4-fix-crash-when-a-directory-s-i_size-is-too-small.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9d5afec6b8bd46d6ed821aa1579634437f58ef1f Mon Sep 17 00:00:00 2001
From: Chandan Rajendra <chandan(a)linux.vnet.ibm.com>
Date: Mon, 11 Dec 2017 15:00:57 -0500
Subject: ext4: fix crash when a directory's i_size is too small
From: Chandan Rajendra <chandan(a)linux.vnet.ibm.com>
commit 9d5afec6b8bd46d6ed821aa1579634437f58ef1f upstream.
On a ppc64 machine, when mounting a fuzzed ext2 image (generated by
fsfuzzer) the following call trace is seen,
VFS: brelse: Trying to free free buffer
WARNING: CPU: 1 PID: 6913 at /root/repos/linux/fs/buffer.c:1165 .__brelse.part.6+0x24/0x40
.__brelse.part.6+0x20/0x40 (unreliable)
.ext4_find_entry+0x384/0x4f0
.ext4_lookup+0x84/0x250
.lookup_slow+0xdc/0x230
.walk_component+0x268/0x400
.path_lookupat+0xec/0x2d0
.filename_lookup+0x9c/0x1d0
.vfs_statx+0x98/0x140
.SyS_newfstatat+0x48/0x80
system_call+0x58/0x6c
This happens because the directory that ext4_find_entry() looks up has
inode->i_size that is less than the block size of the filesystem. This
causes 'nblocks' to have a value of zero. ext4_bread_batch() ends up not
reading any of the directory file's blocks. This renders the entries in
bh_use[] array to continue to have garbage data. buffer_uptodate() on
bh_use[0] can then return a zero value upon which brelse() function is
invoked.
This commit fixes the bug by returning -ENOENT when the directory file
has no associated blocks.
Reported-by: Abdul Haleem <abdhalee(a)linux.vnet.ibm.com>
Signed-off-by: Chandan Rajendra <chandan(a)linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ext4/namei.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1417,6 +1417,10 @@ static struct buffer_head * ext4_find_en
"falling back\n"));
}
nblocks = dir->i_size >> EXT4_BLOCK_SIZE_BITS(sb);
+ if (!nblocks) {
+ ret = NULL;
+ goto cleanup_and_exit;
+ }
start = EXT4_I(dir)->i_dir_start_lookup;
if (start >= nblocks)
start = 0;
Patches currently in stable-queue which might be from chandan(a)linux.vnet.ibm.com are
queue-4.9/ext4-fix-crash-when-a-directory-s-i_size-is-too-small.patch
This is a note to let you know that I've just added the patch titled
dmaengine: dmatest: move callback wait queue to thread context
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-dmatest-move-callback-wait-queue-to-thread-context.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6f6a23a213be51728502b88741ba6a10cda2441d Mon Sep 17 00:00:00 2001
From: Adam Wallis <awallis(a)codeaurora.org>
Date: Mon, 27 Nov 2017 10:45:01 -0500
Subject: dmaengine: dmatest: move callback wait queue to thread context
From: Adam Wallis <awallis(a)codeaurora.org>
commit 6f6a23a213be51728502b88741ba6a10cda2441d upstream.
Commit adfa543e7314 ("dmatest: don't use set_freezable_with_signal()")
introduced a bug (that is in fact documented by the patch commit text)
that leaves behind a dangling pointer. Since the done_wait structure is
allocated on the stack, future invocations to the DMATEST can produce
undesirable results (e.g., corrupted spinlocks).
Commit a9df21e34b42 ("dmaengine: dmatest: warn user when dma test times
out") attempted to WARN the user that the stack was likely corrupted but
did not fix the actual issue.
This patch fixes the issue by pushing the wait queue and callback
structs into the the thread structure. If a failure occurs due to time,
dmaengine_terminate_all will force the callback to safely call
wake_up_all() without possibility of using a freed pointer.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=197605
Fixes: adfa543e7314 ("dmatest: don't use set_freezable_with_signal()")
Reviewed-by: Sinan Kaya <okaya(a)codeaurora.org>
Suggested-by: Shunyong Yang <shunyong.yang(a)hxt-semitech.com>
Signed-off-by: Adam Wallis <awallis(a)codeaurora.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/dmatest.c | 55 ++++++++++++++++++++++++++++----------------------
1 file changed, 31 insertions(+), 24 deletions(-)
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -158,6 +158,12 @@ MODULE_PARM_DESC(run, "Run the test (def
#define PATTERN_OVERWRITE 0x20
#define PATTERN_COUNT_MASK 0x1f
+/* poor man's completion - we want to use wait_event_freezable() on it */
+struct dmatest_done {
+ bool done;
+ wait_queue_head_t *wait;
+};
+
struct dmatest_thread {
struct list_head node;
struct dmatest_info *info;
@@ -166,6 +172,8 @@ struct dmatest_thread {
u8 **srcs;
u8 **dsts;
enum dma_transaction_type type;
+ wait_queue_head_t done_wait;
+ struct dmatest_done test_done;
bool done;
};
@@ -326,18 +334,25 @@ static unsigned int dmatest_verify(u8 **
return error_count;
}
-/* poor man's completion - we want to use wait_event_freezable() on it */
-struct dmatest_done {
- bool done;
- wait_queue_head_t *wait;
-};
static void dmatest_callback(void *arg)
{
struct dmatest_done *done = arg;
-
- done->done = true;
- wake_up_all(done->wait);
+ struct dmatest_thread *thread =
+ container_of(arg, struct dmatest_thread, done_wait);
+ if (!thread->done) {
+ done->done = true;
+ wake_up_all(done->wait);
+ } else {
+ /*
+ * If thread->done, it means that this callback occurred
+ * after the parent thread has cleaned up. This can
+ * happen in the case that driver doesn't implement
+ * the terminate_all() functionality and a dma operation
+ * did not occur within the timeout period
+ */
+ WARN(1, "dmatest: Kernel memory may be corrupted!!\n");
+ }
}
static unsigned int min_odd(unsigned int x, unsigned int y)
@@ -408,9 +423,8 @@ static unsigned long long dmatest_KBs(s6
*/
static int dmatest_func(void *data)
{
- DECLARE_WAIT_QUEUE_HEAD_ONSTACK(done_wait);
struct dmatest_thread *thread = data;
- struct dmatest_done done = { .wait = &done_wait };
+ struct dmatest_done *done = &thread->test_done;
struct dmatest_info *info;
struct dmatest_params *params;
struct dma_chan *chan;
@@ -637,9 +651,9 @@ static int dmatest_func(void *data)
continue;
}
- done.done = false;
+ done->done = false;
tx->callback = dmatest_callback;
- tx->callback_param = &done;
+ tx->callback_param = done;
cookie = tx->tx_submit(tx);
if (dma_submit_error(cookie)) {
@@ -652,21 +666,12 @@ static int dmatest_func(void *data)
}
dma_async_issue_pending(chan);
- wait_event_freezable_timeout(done_wait, done.done,
+ wait_event_freezable_timeout(thread->done_wait, done->done,
msecs_to_jiffies(params->timeout));
status = dma_async_is_tx_complete(chan, cookie, NULL, NULL);
- if (!done.done) {
- /*
- * We're leaving the timed out dma operation with
- * dangling pointer to done_wait. To make this
- * correct, we'll need to allocate wait_done for
- * each test iteration and perform "who's gonna
- * free it this time?" dancing. For now, just
- * leave it dangling.
- */
- WARN(1, "dmatest: Kernel stack may be corrupted!!\n");
+ if (!done->done) {
dmaengine_unmap_put(um);
result("test timed out", total_tests, src_off, dst_off,
len, 0);
@@ -747,7 +752,7 @@ err_thread_type:
dmatest_KBs(runtime, total_len), ret);
/* terminate all transfers on specified channels */
- if (ret)
+ if (ret || failed_tests)
dmaengine_terminate_all(chan);
thread->done = true;
@@ -807,6 +812,8 @@ static int dmatest_add_threads(struct dm
thread->info = info;
thread->chan = dtc->chan;
thread->type = type;
+ thread->test_done.wait = &thread->done_wait;
+ init_waitqueue_head(&thread->done_wait);
smp_wmb();
thread->task = kthread_create(dmatest_func, thread, "%s-%s%u",
dma_chan_name(chan), op, i);
Patches currently in stable-queue which might be from awallis(a)codeaurora.org are
queue-4.9/dmaengine-dmatest-move-callback-wait-queue-to-thread-context.patch
This is a note to let you know that I've just added the patch titled
eeprom: at24: change nvmem stride to 1
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
eeprom-at24-change-nvmem-stride-to-1.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7f6d2ecd3d7acaf205ea7b3e96f9ffc55b92298b Mon Sep 17 00:00:00 2001
From: David Lechner <david(a)lechnology.com>
Date: Sun, 3 Dec 2017 19:54:41 -0600
Subject: eeprom: at24: change nvmem stride to 1
From: David Lechner <david(a)lechnology.com>
commit 7f6d2ecd3d7acaf205ea7b3e96f9ffc55b92298b upstream.
Trying to read the MAC address from an eeprom that has an offset that
is not a multiple of 4 causes an error currently.
Fix it by changing the nvmem stride to 1.
Signed-off-by: David Lechner <david(a)lechnology.com>
[Bartosz: tweaked the commit message]
Signed-off-by: Bartosz Golaszewski <brgl(a)bgdev.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/eeprom/at24.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -783,7 +783,7 @@ static int at24_probe(struct i2c_client
at24->nvmem_config.reg_read = at24_read;
at24->nvmem_config.reg_write = at24_write;
at24->nvmem_config.priv = at24;
- at24->nvmem_config.stride = 4;
+ at24->nvmem_config.stride = 1;
at24->nvmem_config.word_size = 1;
at24->nvmem_config.size = chip.byte_len;
Patches currently in stable-queue which might be from david(a)lechnology.com are
queue-4.9/eeprom-at24-change-nvmem-stride-to-1.patch
This is a note to let you know that I've just added the patch titled
ceph: drop negative child dentries before try pruning inode's alias
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ceph-drop-negative-child-dentries-before-try-pruning-inode-s-alias.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 040d786032bf59002d374b86d75b04d97624005c Mon Sep 17 00:00:00 2001
From: "Yan, Zheng" <zyan(a)redhat.com>
Date: Thu, 30 Nov 2017 11:59:22 +0800
Subject: ceph: drop negative child dentries before try pruning inode's alias
From: Yan, Zheng <zyan(a)redhat.com>
commit 040d786032bf59002d374b86d75b04d97624005c upstream.
Negative child dentry holds reference on inode's alias, it makes
d_prune_aliases() do nothing.
Signed-off-by: "Yan, Zheng" <zyan(a)redhat.com>
Reviewed-by: Jeff Layton <jlayton(a)redhat.com>
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ceph/mds_client.c | 42 ++++++++++++++++++++++++++++++++++++++----
1 file changed, 38 insertions(+), 4 deletions(-)
--- a/fs/ceph/mds_client.c
+++ b/fs/ceph/mds_client.c
@@ -1396,6 +1396,29 @@ static int __close_session(struct ceph_m
return request_close_session(mdsc, session);
}
+static bool drop_negative_children(struct dentry *dentry)
+{
+ struct dentry *child;
+ bool all_negative = true;
+
+ if (!d_is_dir(dentry))
+ goto out;
+
+ spin_lock(&dentry->d_lock);
+ list_for_each_entry(child, &dentry->d_subdirs, d_child) {
+ if (d_really_is_positive(child)) {
+ all_negative = false;
+ break;
+ }
+ }
+ spin_unlock(&dentry->d_lock);
+
+ if (all_negative)
+ shrink_dcache_parent(dentry);
+out:
+ return all_negative;
+}
+
/*
* Trim old(er) caps.
*
@@ -1441,16 +1464,27 @@ static int trim_caps_cb(struct inode *in
if ((used | wanted) & ~oissued & mine)
goto out; /* we need these caps */
- session->s_trim_caps--;
if (oissued) {
/* we aren't the only cap.. just remove us */
__ceph_remove_cap(cap, true);
+ session->s_trim_caps--;
} else {
+ struct dentry *dentry;
/* try dropping referring dentries */
spin_unlock(&ci->i_ceph_lock);
- d_prune_aliases(inode);
- dout("trim_caps_cb %p cap %p pruned, count now %d\n",
- inode, cap, atomic_read(&inode->i_count));
+ dentry = d_find_any_alias(inode);
+ if (dentry && drop_negative_children(dentry)) {
+ int count;
+ dput(dentry);
+ d_prune_aliases(inode);
+ count = atomic_read(&inode->i_count);
+ if (count == 1)
+ session->s_trim_caps--;
+ dout("trim_caps_cb %p cap %p pruned, count now %d\n",
+ inode, cap, count);
+ } else {
+ dput(dentry);
+ }
return 0;
}
Patches currently in stable-queue which might be from zyan(a)redhat.com are
queue-4.9/ceph-drop-negative-child-dentries-before-try-pruning-inode-s-alias.patch
This is a note to let you know that I've just added the patch titled
autofs: fix careless error in recent commit
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
autofs-fix-careless-error-in-recent-commit.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 302ec300ef8a545a7fc7f667e5fd743b091c2eeb Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb(a)suse.com>
Date: Thu, 14 Dec 2017 15:32:38 -0800
Subject: autofs: fix careless error in recent commit
From: NeilBrown <neilb(a)suse.com>
commit 302ec300ef8a545a7fc7f667e5fd743b091c2eeb upstream.
Commit ecc0c469f277 ("autofs: don't fail mount for transient error") was
meant to replace an 'if' with a 'switch', but instead added the 'switch'
leaving the case in place.
Link: http://lkml.kernel.org/r/87zi6wstmw.fsf@notabene.neil.brown.name
Fixes: ecc0c469f277 ("autofs: don't fail mount for transient error")
Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: NeilBrown <neilb(a)suse.com>
Cc: Ian Kent <raven(a)themaw.net>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/autofs4/waitq.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/autofs4/waitq.c
+++ b/fs/autofs4/waitq.c
@@ -176,7 +176,6 @@ static void autofs4_notify_daemon(struct
mutex_unlock(&sbi->wq_mutex);
- if (autofs4_write(sbi, pipe, &pkt, pktsz))
switch (ret = autofs4_write(sbi, pipe, &pkt, pktsz)) {
case 0:
break;
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-4.9/autofs-fix-careless-error-in-recent-commit.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btusb: driver to enable the usb-wakeup feature
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-btusb-driver-to-enable-the-usb-wakeup-feature.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a0085f2510e8976614ad8f766b209448b385492f Mon Sep 17 00:00:00 2001
From: Sukumar Ghorai <sukumar.ghorai(a)intel.com>
Date: Wed, 16 Aug 2017 14:46:55 -0700
Subject: Bluetooth: btusb: driver to enable the usb-wakeup feature
From: Sukumar Ghorai <sukumar.ghorai(a)intel.com>
commit a0085f2510e8976614ad8f766b209448b385492f upstream.
BT-Controller connected as platform non-root-hub device and
usb-driver initialize such device with wakeup disabled,
Ref. usb_new_device().
At present wakeup-capability get enabled by hid-input device from usb
function driver(e.g. BT HID device) at runtime. Again some functional
driver does not set usb-wakeup capability(e.g LE HID device implement
as HID-over-GATT), and can't wakeup the host on USB.
Most of the device operation (such as mass storage) initiated from host
(except HID) and USB wakeup aligned with host resume procedure. For BT
device, usb-wakeup capability need to enable form btusc driver as a
generic solution for multiple profile use case and required for USB remote
wakeup (in-bus wakeup) while host is suspended. Also usb-wakeup feature
need to enable/disable with HCI interface up and down.
Signed-off-by: Sukumar Ghorai <sukumar.ghorai(a)intel.com>
Signed-off-by: Amit K Bag <amit.k.bag(a)intel.com>
Acked-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1059,6 +1059,10 @@ static int btusb_open(struct hci_dev *hd
}
data->intf->needs_remote_wakeup = 1;
+ /* device specific wakeup source enabled and required for USB
+ * remote wakeup while host is suspended
+ */
+ device_wakeup_enable(&data->udev->dev);
if (test_and_set_bit(BTUSB_INTR_RUNNING, &data->flags))
goto done;
@@ -1122,6 +1126,7 @@ static int btusb_close(struct hci_dev *h
goto failed;
data->intf->needs_remote_wakeup = 0;
+ device_wakeup_disable(&data->udev->dev);
usb_autopm_put_interface(data->intf);
failed:
Patches currently in stable-queue which might be from sukumar.ghorai(a)intel.com are
queue-4.9/bluetooth-btusb-driver-to-enable-the-usb-wakeup-feature.patch
This is a note to let you know that I've just added the patch titled
xhci: Don't add a virt_dev to the devs array before it's fully allocated
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xhci-don-t-add-a-virt_dev-to-the-devs-array-before-it-s-fully-allocated.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5d9b70f7d52eb14bb37861c663bae44de9521c35 Mon Sep 17 00:00:00 2001
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Date: Fri, 8 Dec 2017 18:10:05 +0200
Subject: xhci: Don't add a virt_dev to the devs array before it's fully allocated
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
commit 5d9b70f7d52eb14bb37861c663bae44de9521c35 upstream.
Avoid null pointer dereference if some function is walking through the
devs array accessing members of a new virt_dev that is mid allocation.
Add the virt_dev to xhci->devs[i] _after_ the virt_device and all its
members are properly allocated.
issue found by KASAN: null-ptr-deref in xhci_find_slot_id_by_port
"Quick analysis suggests that xhci_alloc_virt_device() is not mutex
protected. If so, there is a time frame where xhci->devs[slot_id] is set
but not fully initialized. Specifically, xhci->devs[i]->udev can be NULL."
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci-mem.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1017,10 +1017,9 @@ int xhci_alloc_virt_device(struct xhci_h
return 0;
}
- xhci->devs[slot_id] = kzalloc(sizeof(*xhci->devs[slot_id]), flags);
- if (!xhci->devs[slot_id])
+ dev = kzalloc(sizeof(*dev), flags);
+ if (!dev)
return 0;
- dev = xhci->devs[slot_id];
/* Allocate the (output) device context that will be used in the HC. */
dev->out_ctx = xhci_alloc_container_ctx(xhci, XHCI_CTX_TYPE_DEVICE, flags);
@@ -1068,9 +1067,17 @@ int xhci_alloc_virt_device(struct xhci_h
&xhci->dcbaa->dev_context_ptrs[slot_id],
le64_to_cpu(xhci->dcbaa->dev_context_ptrs[slot_id]));
+ xhci->devs[slot_id] = dev;
+
return 1;
fail:
- xhci_free_virt_device(xhci, slot_id);
+
+ if (dev->in_ctx)
+ xhci_free_container_ctx(xhci, dev->in_ctx);
+ if (dev->out_ctx)
+ xhci_free_container_ctx(xhci, dev->out_ctx);
+ kfree(dev);
+
return 0;
}
Patches currently in stable-queue which might be from mathias.nyman(a)linux.intel.com are
queue-4.4/xhci-don-t-add-a-virt_dev-to-the-devs-array-before-it-s-fully-allocated.patch
This is a note to let you know that I've just added the patch titled
sched/rt: Do not pull from current CPU if only one CPU to pull
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sched-rt-do-not-pull-from-current-cpu-if-only-one-cpu-to-pull.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f73c52a5bcd1710994e53fbccc378c42b97a06b6 Mon Sep 17 00:00:00 2001
From: Steven Rostedt <rostedt(a)goodmis.org>
Date: Sat, 2 Dec 2017 13:04:54 -0500
Subject: sched/rt: Do not pull from current CPU if only one CPU to pull
From: Steven Rostedt <rostedt(a)goodmis.org>
commit f73c52a5bcd1710994e53fbccc378c42b97a06b6 upstream.
Daniel Wagner reported a crash on the BeagleBone Black SoC.
This is a single CPU architecture, and does not have a functional
arch_send_call_function_single_ipi() implementation which can crash
the kernel if that is called.
As it only has one CPU, it shouldn't be called, but if the kernel is
compiled for SMP, the push/pull RT scheduling logic now calls it for
irq_work if the one CPU is overloaded, it can use that function to call
itself and crash the kernel.
Ideally, we should disable the SCHED_FEAT(RT_PUSH_IPI) if the system
only has a single CPU. But SCHED_FEAT is a constant if sched debugging
is turned off. Another fix can also be used, and this should also help
with normal SMP machines. That is, do not initiate the pull code if
there's only one RT overloaded CPU, and that CPU happens to be the
current CPU that is scheduling in a lower priority task.
Even on a system with many CPUs, if there's many RT tasks waiting to
run on a single CPU, and that CPU schedules in another RT task of lower
priority, it will initiate the PULL logic in case there's a higher
priority RT task on another CPU that is waiting to run. But if there is
no other CPU with waiting RT tasks, it will initiate the RT pull logic
on itself (as it still has RT tasks waiting to run). This is a wasted
effort.
Not only does this help with SMP code where the current CPU is the only
one with RT overloaded tasks, it should also solve the issue that
Daniel encountered, because it will prevent the PULL logic from
executing, as there's only one CPU on the system, and the check added
here will cause it to exit the RT pull code.
Reported-by: Daniel Wagner <wagi(a)monom.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Acked-by: Peter Zijlstra <peterz(a)infradead.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-rt-users <linux-rt-users(a)vger.kernel.org>
Fixes: 4bdced5c9 ("sched/rt: Simplify the IPI based RT balancing logic")
Link: http://lkml.kernel.org/r/20171202130454.4cbbfe8d@vmware.local.home
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/sched/rt.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1960,8 +1960,9 @@ static void pull_rt_task(struct rq *this
bool resched = false;
struct task_struct *p;
struct rq *src_rq;
+ int rt_overload_count = rt_overloaded(this_rq);
- if (likely(!rt_overloaded(this_rq)))
+ if (likely(!rt_overload_count))
return;
/*
@@ -1970,6 +1971,11 @@ static void pull_rt_task(struct rq *this
*/
smp_rmb();
+ /* If we are the only overloaded CPU do nothing */
+ if (rt_overload_count == 1 &&
+ cpumask_test_cpu(this_rq->cpu, this_rq->rd->rto_mask))
+ return;
+
#ifdef HAVE_RT_PUSH_IPI
if (sched_feat(RT_PUSH_IPI)) {
tell_cpu_to_push(this_rq);
Patches currently in stable-queue which might be from rostedt(a)goodmis.org are
queue-4.4/sched-rt-do-not-pull-from-current-cpu-if-only-one-cpu-to-pull.patch
queue-4.4/tracing-allocate-mask_str-buffer-dynamically.patch
This is a note to let you know that I've just added the patch titled
ext4: fix fdatasync(2) after fallocate(2) operation
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ext4-fix-fdatasync-2-after-fallocate-2-operation.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c894aa97577e47d3066b27b32499ecf899bfa8b0 Mon Sep 17 00:00:00 2001
From: Eryu Guan <eguan(a)redhat.com>
Date: Sun, 3 Dec 2017 22:52:51 -0500
Subject: ext4: fix fdatasync(2) after fallocate(2) operation
From: Eryu Guan <eguan(a)redhat.com>
commit c894aa97577e47d3066b27b32499ecf899bfa8b0 upstream.
Currently, fallocate(2) with KEEP_SIZE followed by a fdatasync(2)
then crash, we'll see wrong allocated block number (stat -c %b), the
blocks allocated beyond EOF are all lost. fstests generic/468
exposes this bug.
Commit 67a7d5f561f4 ("ext4: fix fdatasync(2) after extent
manipulation operations") fixed all the other extent manipulation
operation paths such as hole punch, zero range, collapse range etc.,
but forgot the fallocate case.
So similarly, fix it by recording the correct journal tid in ext4
inode in fallocate(2) path, so that ext4_sync_file() will wait for
the right tid to be committed on fdatasync(2).
This addresses the test failure in xfstests test generic/468.
Signed-off-by: Eryu Guan <eguan(a)redhat.com>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ext4/extents.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4746,6 +4746,7 @@ retry:
EXT4_INODE_EOFBLOCKS);
}
ext4_mark_inode_dirty(handle, inode);
+ ext4_update_inode_fsync_trans(handle, inode, 1);
ret2 = ext4_journal_stop(handle);
if (ret2)
break;
Patches currently in stable-queue which might be from eguan(a)redhat.com are
queue-4.4/ext4-fix-fdatasync-2-after-fallocate-2-operation.patch
This is a note to let you know that I've just added the patch titled
ext4: fix crash when a directory's i_size is too small
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ext4-fix-crash-when-a-directory-s-i_size-is-too-small.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9d5afec6b8bd46d6ed821aa1579634437f58ef1f Mon Sep 17 00:00:00 2001
From: Chandan Rajendra <chandan(a)linux.vnet.ibm.com>
Date: Mon, 11 Dec 2017 15:00:57 -0500
Subject: ext4: fix crash when a directory's i_size is too small
From: Chandan Rajendra <chandan(a)linux.vnet.ibm.com>
commit 9d5afec6b8bd46d6ed821aa1579634437f58ef1f upstream.
On a ppc64 machine, when mounting a fuzzed ext2 image (generated by
fsfuzzer) the following call trace is seen,
VFS: brelse: Trying to free free buffer
WARNING: CPU: 1 PID: 6913 at /root/repos/linux/fs/buffer.c:1165 .__brelse.part.6+0x24/0x40
.__brelse.part.6+0x20/0x40 (unreliable)
.ext4_find_entry+0x384/0x4f0
.ext4_lookup+0x84/0x250
.lookup_slow+0xdc/0x230
.walk_component+0x268/0x400
.path_lookupat+0xec/0x2d0
.filename_lookup+0x9c/0x1d0
.vfs_statx+0x98/0x140
.SyS_newfstatat+0x48/0x80
system_call+0x58/0x6c
This happens because the directory that ext4_find_entry() looks up has
inode->i_size that is less than the block size of the filesystem. This
causes 'nblocks' to have a value of zero. ext4_bread_batch() ends up not
reading any of the directory file's blocks. This renders the entries in
bh_use[] array to continue to have garbage data. buffer_uptodate() on
bh_use[0] can then return a zero value upon which brelse() function is
invoked.
This commit fixes the bug by returning -ENOENT when the directory file
has no associated blocks.
Reported-by: Abdul Haleem <abdhalee(a)linux.vnet.ibm.com>
Signed-off-by: Chandan Rajendra <chandan(a)linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ext4/namei.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1403,6 +1403,10 @@ static struct buffer_head * ext4_find_en
"falling back\n"));
}
nblocks = dir->i_size >> EXT4_BLOCK_SIZE_BITS(sb);
+ if (!nblocks) {
+ ret = NULL;
+ goto cleanup_and_exit;
+ }
start = EXT4_I(dir)->i_dir_start_lookup;
if (start >= nblocks)
start = 0;
Patches currently in stable-queue which might be from chandan(a)linux.vnet.ibm.com are
queue-4.4/ext4-fix-crash-when-a-directory-s-i_size-is-too-small.patch
This is a note to let you know that I've just added the patch titled
dmaengine: dmatest: move callback wait queue to thread context
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-dmatest-move-callback-wait-queue-to-thread-context.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6f6a23a213be51728502b88741ba6a10cda2441d Mon Sep 17 00:00:00 2001
From: Adam Wallis <awallis(a)codeaurora.org>
Date: Mon, 27 Nov 2017 10:45:01 -0500
Subject: dmaengine: dmatest: move callback wait queue to thread context
From: Adam Wallis <awallis(a)codeaurora.org>
commit 6f6a23a213be51728502b88741ba6a10cda2441d upstream.
Commit adfa543e7314 ("dmatest: don't use set_freezable_with_signal()")
introduced a bug (that is in fact documented by the patch commit text)
that leaves behind a dangling pointer. Since the done_wait structure is
allocated on the stack, future invocations to the DMATEST can produce
undesirable results (e.g., corrupted spinlocks).
Commit a9df21e34b42 ("dmaengine: dmatest: warn user when dma test times
out") attempted to WARN the user that the stack was likely corrupted but
did not fix the actual issue.
This patch fixes the issue by pushing the wait queue and callback
structs into the the thread structure. If a failure occurs due to time,
dmaengine_terminate_all will force the callback to safely call
wake_up_all() without possibility of using a freed pointer.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=197605
Fixes: adfa543e7314 ("dmatest: don't use set_freezable_with_signal()")
Reviewed-by: Sinan Kaya <okaya(a)codeaurora.org>
Suggested-by: Shunyong Yang <shunyong.yang(a)hxt-semitech.com>
Signed-off-by: Adam Wallis <awallis(a)codeaurora.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/dmatest.c | 55 ++++++++++++++++++++++++++++----------------------
1 file changed, 31 insertions(+), 24 deletions(-)
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -148,6 +148,12 @@ MODULE_PARM_DESC(run, "Run the test (def
#define PATTERN_OVERWRITE 0x20
#define PATTERN_COUNT_MASK 0x1f
+/* poor man's completion - we want to use wait_event_freezable() on it */
+struct dmatest_done {
+ bool done;
+ wait_queue_head_t *wait;
+};
+
struct dmatest_thread {
struct list_head node;
struct dmatest_info *info;
@@ -156,6 +162,8 @@ struct dmatest_thread {
u8 **srcs;
u8 **dsts;
enum dma_transaction_type type;
+ wait_queue_head_t done_wait;
+ struct dmatest_done test_done;
bool done;
};
@@ -316,18 +324,25 @@ static unsigned int dmatest_verify(u8 **
return error_count;
}
-/* poor man's completion - we want to use wait_event_freezable() on it */
-struct dmatest_done {
- bool done;
- wait_queue_head_t *wait;
-};
static void dmatest_callback(void *arg)
{
struct dmatest_done *done = arg;
-
- done->done = true;
- wake_up_all(done->wait);
+ struct dmatest_thread *thread =
+ container_of(arg, struct dmatest_thread, done_wait);
+ if (!thread->done) {
+ done->done = true;
+ wake_up_all(done->wait);
+ } else {
+ /*
+ * If thread->done, it means that this callback occurred
+ * after the parent thread has cleaned up. This can
+ * happen in the case that driver doesn't implement
+ * the terminate_all() functionality and a dma operation
+ * did not occur within the timeout period
+ */
+ WARN(1, "dmatest: Kernel memory may be corrupted!!\n");
+ }
}
static unsigned int min_odd(unsigned int x, unsigned int y)
@@ -398,9 +413,8 @@ static unsigned long long dmatest_KBs(s6
*/
static int dmatest_func(void *data)
{
- DECLARE_WAIT_QUEUE_HEAD_ONSTACK(done_wait);
struct dmatest_thread *thread = data;
- struct dmatest_done done = { .wait = &done_wait };
+ struct dmatest_done *done = &thread->test_done;
struct dmatest_info *info;
struct dmatest_params *params;
struct dma_chan *chan;
@@ -605,9 +619,9 @@ static int dmatest_func(void *data)
continue;
}
- done.done = false;
+ done->done = false;
tx->callback = dmatest_callback;
- tx->callback_param = &done;
+ tx->callback_param = done;
cookie = tx->tx_submit(tx);
if (dma_submit_error(cookie)) {
@@ -620,21 +634,12 @@ static int dmatest_func(void *data)
}
dma_async_issue_pending(chan);
- wait_event_freezable_timeout(done_wait, done.done,
+ wait_event_freezable_timeout(thread->done_wait, done->done,
msecs_to_jiffies(params->timeout));
status = dma_async_is_tx_complete(chan, cookie, NULL, NULL);
- if (!done.done) {
- /*
- * We're leaving the timed out dma operation with
- * dangling pointer to done_wait. To make this
- * correct, we'll need to allocate wait_done for
- * each test iteration and perform "who's gonna
- * free it this time?" dancing. For now, just
- * leave it dangling.
- */
- WARN(1, "dmatest: Kernel stack may be corrupted!!\n");
+ if (!done->done) {
dmaengine_unmap_put(um);
result("test timed out", total_tests, src_off, dst_off,
len, 0);
@@ -708,7 +713,7 @@ err_thread_type:
dmatest_KBs(runtime, total_len), ret);
/* terminate all transfers on specified channels */
- if (ret)
+ if (ret || failed_tests)
dmaengine_terminate_all(chan);
thread->done = true;
@@ -766,6 +771,8 @@ static int dmatest_add_threads(struct dm
thread->info = info;
thread->chan = dtc->chan;
thread->type = type;
+ thread->test_done.wait = &thread->done_wait;
+ init_waitqueue_head(&thread->done_wait);
smp_wmb();
thread->task = kthread_create(dmatest_func, thread, "%s-%s%u",
dma_chan_name(chan), op, i);
Patches currently in stable-queue which might be from awallis(a)codeaurora.org are
queue-4.4/dmaengine-dmatest-move-callback-wait-queue-to-thread-context.patch
This is a note to let you know that I've just added the patch titled
x86/boot/compressed/64: Print error if 5-level paging is not supported
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-boot-compressed-64-print-error-if-5-level-paging-is-not-supported.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6d7e0ba2d2be9e50cccba213baf07e0e183c1b24 Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Date: Mon, 4 Dec 2017 15:40:56 +0300
Subject: x86/boot/compressed/64: Print error if 5-level paging is not supported
From: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
commit 6d7e0ba2d2be9e50cccba213baf07e0e183c1b24 upstream.
If the machine does not support the paging mode for which the kernel was
compiled, the boot process cannot continue.
It's not possible to let the kernel detect the mismatch as it does not even
reach the point where cpu features can be evaluted due to a triple fault in
the KASLR setup.
Instead of instantaneous silent reboot, emit an error message which gives
the user the information why the boot fails.
Fixes: 77ef56e4f0fb ("x86: Enable 5-level paging support via CONFIG_X86_5LEVEL=y")
Reported-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Tested-by: Borislav Petkov <bp(a)suse.de>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Andy Lutomirski <luto(a)amacapital.net>
Cc: linux-mm(a)kvack.org
Cc: Cyrill Gorcunov <gorcunov(a)openvz.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Link: https://lkml.kernel.org/r/20171204124059.63515-3-kirill.shutemov@linux.inte…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/boot/compressed/misc.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -169,6 +169,16 @@ void __puthex(unsigned long value)
}
}
+static bool l5_supported(void)
+{
+ /* Check if leaf 7 is supported. */
+ if (native_cpuid_eax(0) < 7)
+ return 0;
+
+ /* Check if la57 is supported. */
+ return native_cpuid_ecx(7) & (1 << (X86_FEATURE_LA57 & 31));
+}
+
#if CONFIG_X86_NEED_RELOCS
static void handle_relocations(void *output, unsigned long output_len,
unsigned long virt_addr)
@@ -362,6 +372,12 @@ asmlinkage __visible void *extract_kerne
console_init();
debug_putstr("early console in extract_kernel\n");
+ if (IS_ENABLED(CONFIG_X86_5LEVEL) && !l5_supported()) {
+ error("This linux kernel as configured requires 5-level paging\n"
+ "This CPU does not support the required 'cr4.la57' feature\n"
+ "Unable to boot - please use a kernel appropriate for your CPU\n");
+ }
+
free_mem_ptr = heap; /* Heap */
free_mem_end_ptr = heap + BOOT_HEAP_SIZE;
Patches currently in stable-queue which might be from kirill.shutemov(a)linux.intel.com are
queue-4.14/x86-boot-compressed-64-print-error-if-5-level-paging-is-not-supported.patch
queue-4.14/x86-boot-compressed-64-detect-and-handle-5-level-paging-at-boot-time.patch
This is a note to let you know that I've just added the patch titled
xhci: Don't add a virt_dev to the devs array before it's fully allocated
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xhci-don-t-add-a-virt_dev-to-the-devs-array-before-it-s-fully-allocated.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5d9b70f7d52eb14bb37861c663bae44de9521c35 Mon Sep 17 00:00:00 2001
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Date: Fri, 8 Dec 2017 18:10:05 +0200
Subject: xhci: Don't add a virt_dev to the devs array before it's fully allocated
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
commit 5d9b70f7d52eb14bb37861c663bae44de9521c35 upstream.
Avoid null pointer dereference if some function is walking through the
devs array accessing members of a new virt_dev that is mid allocation.
Add the virt_dev to xhci->devs[i] _after_ the virt_device and all its
members are properly allocated.
issue found by KASAN: null-ptr-deref in xhci_find_slot_id_by_port
"Quick analysis suggests that xhci_alloc_virt_device() is not mutex
protected. If so, there is a time frame where xhci->devs[slot_id] is set
but not fully initialized. Specifically, xhci->devs[i]->udev can be NULL."
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci-mem.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -983,10 +983,9 @@ int xhci_alloc_virt_device(struct xhci_h
return 0;
}
- xhci->devs[slot_id] = kzalloc(sizeof(*xhci->devs[slot_id]), flags);
- if (!xhci->devs[slot_id])
+ dev = kzalloc(sizeof(*dev), flags);
+ if (!dev)
return 0;
- dev = xhci->devs[slot_id];
/* Allocate the (output) device context that will be used in the HC. */
dev->out_ctx = xhci_alloc_container_ctx(xhci, XHCI_CTX_TYPE_DEVICE, flags);
@@ -1027,9 +1026,17 @@ int xhci_alloc_virt_device(struct xhci_h
trace_xhci_alloc_virt_device(dev);
+ xhci->devs[slot_id] = dev;
+
return 1;
fail:
- xhci_free_virt_device(xhci, slot_id);
+
+ if (dev->in_ctx)
+ xhci_free_container_ctx(xhci, dev->in_ctx);
+ if (dev->out_ctx)
+ xhci_free_container_ctx(xhci, dev->out_ctx);
+ kfree(dev);
+
return 0;
}
Patches currently in stable-queue which might be from mathias.nyman(a)linux.intel.com are
queue-4.14/usb-xhci-fix-tds-for-mtk-xhci1.1.patch
queue-4.14/xhci-don-t-add-a-virt_dev-to-the-devs-array-before-it-s-fully-allocated.patch
This is a note to let you know that I've just added the patch titled
x86/boot/compressed/64: Detect and handle 5-level paging at boot-time
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-boot-compressed-64-detect-and-handle-5-level-paging-at-boot-time.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 08529078d8d9adf689bf39cc38d53979a0869970 Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Date: Mon, 4 Dec 2017 15:40:55 +0300
Subject: x86/boot/compressed/64: Detect and handle 5-level paging at boot-time
From: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
commit 08529078d8d9adf689bf39cc38d53979a0869970 upstream.
Prerequisite for fixing the current problem of instantaneous reboots when a
5-level paging kernel is booted on 4-level paging hardware.
At the same time this change prepares the decompression code to boot-time
switching between 4- and 5-level paging.
[ tglx: Folded the GCC < 5 fix. ]
Fixes: 77ef56e4f0fb ("x86: Enable 5-level paging support via CONFIG_X86_5LEVEL=y")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Andy Lutomirski <luto(a)amacapital.net>
Cc: linux-mm(a)kvack.org
Cc: Cyrill Gorcunov <gorcunov(a)openvz.org>
Cc: Borislav Petkov <bp(a)suse.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Link: https://lkml.kernel.org/r/20171204124059.63515-2-kirill.shutemov@linux.inte…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/boot/compressed/Makefile | 1 +
arch/x86/boot/compressed/head_64.S | 16 ++++++++++++----
arch/x86/boot/compressed/pgtable_64.c | 28 ++++++++++++++++++++++++++++
3 files changed, 41 insertions(+), 4 deletions(-)
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -78,6 +78,7 @@ vmlinux-objs-$(CONFIG_EARLY_PRINTK) += $
vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/kaslr.o
ifdef CONFIG_X86_64
vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/pagetable.o
+ vmlinux-objs-y += $(obj)/pgtable_64.o
endif
$(obj)/eboot.o: KBUILD_CFLAGS += -fshort-wchar -mno-red-zone
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -289,10 +289,18 @@ ENTRY(startup_64)
leaq boot_stack_end(%rbx), %rsp
#ifdef CONFIG_X86_5LEVEL
- /* Check if 5-level paging has already enabled */
- movq %cr4, %rax
- testl $X86_CR4_LA57, %eax
- jnz lvl5
+ /*
+ * Check if we need to enable 5-level paging.
+ * RSI holds real mode data and need to be preserved across
+ * a function call.
+ */
+ pushq %rsi
+ call l5_paging_required
+ popq %rsi
+
+ /* If l5_paging_required() returned zero, we're done here. */
+ cmpq $0, %rax
+ je lvl5
/*
* At this point we are in long mode with 4-level paging enabled,
--- /dev/null
+++ b/arch/x86/boot/compressed/pgtable_64.c
@@ -0,0 +1,28 @@
+#include <asm/processor.h>
+
+/*
+ * __force_order is used by special_insns.h asm code to force instruction
+ * serialization.
+ *
+ * It is not referenced from the code, but GCC < 5 with -fPIE would fail
+ * due to an undefined symbol. Define it to make these ancient GCCs work.
+ */
+unsigned long __force_order;
+
+int l5_paging_required(void)
+{
+ /* Check if leaf 7 is supported. */
+
+ if (native_cpuid_eax(0) < 7)
+ return 0;
+
+ /* Check if la57 is supported. */
+ if (!(native_cpuid_ecx(7) & (1 << (X86_FEATURE_LA57 & 31))))
+ return 0;
+
+ /* Check if 5-level paging has already been enabled. */
+ if (native_read_cr4() & X86_CR4_LA57)
+ return 0;
+
+ return 1;
+}
Patches currently in stable-queue which might be from kirill.shutemov(a)linux.intel.com are
queue-4.14/x86-boot-compressed-64-print-error-if-5-level-paging-is-not-supported.patch
queue-4.14/x86-boot-compressed-64-detect-and-handle-5-level-paging-at-boot-time.patch
This is a note to let you know that I've just added the patch titled
usbip: prevent vhci_hcd driver from leaking a socket pointer address
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-prevent-vhci_hcd-driver-from-leaking-a-socket-pointer-address.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2f2d0088eb93db5c649d2a5e34a3800a8a935fc5 Mon Sep 17 00:00:00 2001
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Thu, 7 Dec 2017 14:16:49 -0700
Subject: usbip: prevent vhci_hcd driver from leaking a socket pointer address
From: Shuah Khan <shuahkh(a)osg.samsung.com>
commit 2f2d0088eb93db5c649d2a5e34a3800a8a935fc5 upstream.
When a client has a USB device attached over IP, the vhci_hcd driver is
locally leaking a socket pointer address via the
/sys/devices/platform/vhci_hcd/status file (world-readable) and in debug
output when "usbip --debug port" is run.
Fix it to not leak. The socket pointer address is not used at the moment
and it was made visible as a convenient way to find IP address from socket
pointer address by looking up /proc/net/{tcp,tcp6}.
As this opens a security hole, the fix replaces socket pointer address with
sockfd.
Reported-by: Secunia Research <vuln(a)secunia.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/usbip_common.h | 1 +
drivers/usb/usbip/vhci_sysfs.c | 25 ++++++++++++++++---------
tools/usb/usbip/libsrc/vhci_driver.c | 8 ++++----
3 files changed, 21 insertions(+), 13 deletions(-)
--- a/drivers/usb/usbip/usbip_common.h
+++ b/drivers/usb/usbip/usbip_common.h
@@ -270,6 +270,7 @@ struct usbip_device {
/* lock for status */
spinlock_t lock;
+ int sockfd;
struct socket *tcp_socket;
struct task_struct *tcp_rx;
--- a/drivers/usb/usbip/vhci_sysfs.c
+++ b/drivers/usb/usbip/vhci_sysfs.c
@@ -31,15 +31,20 @@
/*
* output example:
- * hub port sta spd dev socket local_busid
- * hs 0000 004 000 00000000 c5a7bb80 1-2.3
+ * hub port sta spd dev sockfd local_busid
+ * hs 0000 004 000 00000000 3 1-2.3
* ................................................
- * ss 0008 004 000 00000000 d8cee980 2-3.4
+ * ss 0008 004 000 00000000 4 2-3.4
* ................................................
*
- * IP address can be retrieved from a socket pointer address by looking
- * up /proc/net/{tcp,tcp6}. Also, a userland program may remember a
- * port number and its peer IP address.
+ * Output includes socket fd instead of socket pointer address to avoid
+ * leaking kernel memory address in:
+ * /sys/devices/platform/vhci_hcd.0/status and in debug output.
+ * The socket pointer address is not used at the moment and it was made
+ * visible as a convenient way to find IP address from socket pointer
+ * address by looking up /proc/net/{tcp,tcp6}. As this opens a security
+ * hole, the change is made to use sockfd instead.
+ *
*/
static void port_show_vhci(char **out, int hub, int port, struct vhci_device *vdev)
{
@@ -53,8 +58,8 @@ static void port_show_vhci(char **out, i
if (vdev->ud.status == VDEV_ST_USED) {
*out += sprintf(*out, "%03u %08x ",
vdev->speed, vdev->devid);
- *out += sprintf(*out, "%16p %s",
- vdev->ud.tcp_socket,
+ *out += sprintf(*out, "%u %s",
+ vdev->ud.sockfd,
dev_name(&vdev->udev->dev));
} else {
@@ -174,7 +179,8 @@ static ssize_t nports_show(struct device
char *s = out;
/*
- * Half the ports are for SPEED_HIGH and half for SPEED_SUPER, thus the * 2.
+ * Half the ports are for SPEED_HIGH and half for SPEED_SUPER,
+ * thus the * 2.
*/
out += sprintf(out, "%d\n", VHCI_PORTS * vhci_num_controllers);
return out - s;
@@ -380,6 +386,7 @@ static ssize_t store_attach(struct devic
vdev->devid = devid;
vdev->speed = speed;
+ vdev->ud.sockfd = sockfd;
vdev->ud.tcp_socket = socket;
vdev->ud.status = VDEV_ST_NOTASSIGNED;
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -50,14 +50,14 @@ static int parse_status(const char *valu
while (*c != '\0') {
int port, status, speed, devid;
- unsigned long socket;
+ int sockfd;
char lbusid[SYSFS_BUS_ID_SIZE];
struct usbip_imported_device *idev;
char hub[3];
- ret = sscanf(c, "%2s %d %d %d %x %lx %31s\n",
+ ret = sscanf(c, "%2s %d %d %d %x %u %31s\n",
hub, &port, &status, &speed,
- &devid, &socket, lbusid);
+ &devid, &sockfd, lbusid);
if (ret < 5) {
dbg("sscanf failed: %d", ret);
@@ -66,7 +66,7 @@ static int parse_status(const char *valu
dbg("hub %s port %d status %d speed %d devid %x",
hub, port, status, speed, devid);
- dbg("socket %lx lbusid %s", socket, lbusid);
+ dbg("sockfd %u lbusid %s", sockfd, lbusid);
/* if a device is connected, look at it */
idev = &vhci_driver->idev[port];
Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are
queue-4.14/usbip-fix-stub_rx-harden-cmd_submit-path-to-handle-malicious-input.patch
queue-4.14/usbip-fix-stub_send_ret_submit-vulnerability-to-null-transfer_buffer.patch
queue-4.14/usbip-fix-stub_rx-get_pipe-to-validate-endpoint-number.patch
queue-4.14/usbip-prevent-vhci_hcd-driver-from-leaking-a-socket-pointer-address.patch
This is a note to let you know that I've just added the patch titled
usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-fix-stub_send_ret_submit-vulnerability-to-null-transfer_buffer.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From be6123df1ea8f01ee2f896a16c2b7be3e4557a5a Mon Sep 17 00:00:00 2001
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Thu, 7 Dec 2017 14:16:50 -0700
Subject: usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer
From: Shuah Khan <shuahkh(a)osg.samsung.com>
commit be6123df1ea8f01ee2f896a16c2b7be3e4557a5a upstream.
stub_send_ret_submit() handles urb with a potential null transfer_buffer,
when it replays a packet with potential malicious data that could contain
a null buffer. Add a check for the condition when actual_length > 0 and
transfer_buffer is null.
Reported-by: Secunia Research <vuln(a)secunia.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/stub_tx.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/usb/usbip/stub_tx.c
+++ b/drivers/usb/usbip/stub_tx.c
@@ -181,6 +181,13 @@ static int stub_send_ret_submit(struct s
memset(&pdu_header, 0, sizeof(pdu_header));
memset(&msg, 0, sizeof(msg));
+ if (urb->actual_length > 0 && !urb->transfer_buffer) {
+ dev_err(&sdev->udev->dev,
+ "urb: actual_length %d transfer_buffer null\n",
+ urb->actual_length);
+ return -1;
+ }
+
if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS)
iovnum = 2 + urb->number_of_packets;
else
Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are
queue-4.14/usbip-fix-stub_rx-harden-cmd_submit-path-to-handle-malicious-input.patch
queue-4.14/usbip-fix-stub_send_ret_submit-vulnerability-to-null-transfer_buffer.patch
queue-4.14/usbip-fix-stub_rx-get_pipe-to-validate-endpoint-number.patch
queue-4.14/usbip-prevent-vhci_hcd-driver-from-leaking-a-socket-pointer-address.patch
This is a note to let you know that I've just added the patch titled
usbip: fix stub_rx: get_pipe() to validate endpoint number
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-fix-stub_rx-get_pipe-to-validate-endpoint-number.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 635f545a7e8be7596b9b2b6a43cab6bbd5a88e43 Mon Sep 17 00:00:00 2001
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Thu, 7 Dec 2017 14:16:47 -0700
Subject: usbip: fix stub_rx: get_pipe() to validate endpoint number
From: Shuah Khan <shuahkh(a)osg.samsung.com>
commit 635f545a7e8be7596b9b2b6a43cab6bbd5a88e43 upstream.
get_pipe() routine doesn't validate the input endpoint number
and uses to reference ep_in and ep_out arrays. Invalid endpoint
number can trigger BUG(). Range check the epnum and returning
error instead of calling BUG().
Change caller stub_recv_cmd_submit() to handle the get_pipe()
error return.
Reported-by: Secunia Research <vuln(a)secunia.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/stub_rx.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -342,15 +342,15 @@ static int get_pipe(struct stub_device *
struct usb_host_endpoint *ep;
struct usb_endpoint_descriptor *epd = NULL;
+ if (epnum < 0 || epnum > 15)
+ goto err_ret;
+
if (dir == USBIP_DIR_IN)
ep = udev->ep_in[epnum & 0x7f];
else
ep = udev->ep_out[epnum & 0x7f];
- if (!ep) {
- dev_err(&sdev->udev->dev, "no such endpoint?, %d\n",
- epnum);
- BUG();
- }
+ if (!ep)
+ goto err_ret;
epd = &ep->desc;
if (usb_endpoint_xfer_control(epd)) {
@@ -381,9 +381,10 @@ static int get_pipe(struct stub_device *
return usb_rcvisocpipe(udev, epnum);
}
+err_ret:
/* NOT REACHED */
- dev_err(&sdev->udev->dev, "get pipe, epnum %d\n", epnum);
- return 0;
+ dev_err(&sdev->udev->dev, "get pipe() invalid epnum %d\n", epnum);
+ return -1;
}
static void masking_bogus_flags(struct urb *urb)
@@ -449,6 +450,9 @@ static void stub_recv_cmd_submit(struct
struct usb_device *udev = sdev->udev;
int pipe = get_pipe(sdev, pdu->base.ep, pdu->base.direction);
+ if (pipe == -1)
+ return;
+
priv = stub_priv_alloc(sdev, pdu);
if (!priv)
return;
Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are
queue-4.14/usbip-fix-stub_rx-harden-cmd_submit-path-to-handle-malicious-input.patch
queue-4.14/usbip-fix-stub_send_ret_submit-vulnerability-to-null-transfer_buffer.patch
queue-4.14/usbip-fix-stub_rx-get_pipe-to-validate-endpoint-number.patch
queue-4.14/usbip-prevent-vhci_hcd-driver-from-leaking-a-socket-pointer-address.patch
This is a note to let you know that I've just added the patch titled
usb: xhci: fix TDS for MTK xHCI1.1
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-xhci-fix-tds-for-mtk-xhci1.1.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 72b663a99c074a8d073e7ecdae446cfb024ef551 Mon Sep 17 00:00:00 2001
From: Chunfeng Yun <chunfeng.yun(a)mediatek.com>
Date: Fri, 8 Dec 2017 18:10:06 +0200
Subject: usb: xhci: fix TDS for MTK xHCI1.1
From: Chunfeng Yun <chunfeng.yun(a)mediatek.com>
commit 72b663a99c074a8d073e7ecdae446cfb024ef551 upstream.
For MTK's xHCI 1.0 or latter, TD size is the number of max
packet sized packets remaining in the TD, not including
this TRB (following spec).
For MTK's xHCI 0.96 and older, TD size is the number of max
packet sized packets remaining in the TD, including this TRB
(not following spec).
Signed-off-by: Chunfeng Yun <chunfeng.yun(a)mediatek.com>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci-ring.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3121,7 +3121,7 @@ static u32 xhci_td_remainder(struct xhci
{
u32 maxp, total_packet_count;
- /* MTK xHCI is mostly 0.97 but contains some features from 1.0 */
+ /* MTK xHCI 0.96 contains some features from 1.0 */
if (xhci->hci_version < 0x100 && !(xhci->quirks & XHCI_MTK_HOST))
return ((td_total_len - transferred) >> 10);
@@ -3130,8 +3130,8 @@ static u32 xhci_td_remainder(struct xhci
trb_buff_len == td_total_len)
return 0;
- /* for MTK xHCI, TD size doesn't include this TRB */
- if (xhci->quirks & XHCI_MTK_HOST)
+ /* for MTK xHCI 0.96, TD size include this TRB, but not in 1.x */
+ if ((xhci->quirks & XHCI_MTK_HOST) && (xhci->hci_version < 0x100))
trb_buff_len = 0;
maxp = usb_endpoint_maxp(&urb->ep->desc);
Patches currently in stable-queue which might be from chunfeng.yun(a)mediatek.com are
queue-4.14/usb-xhci-fix-tds-for-mtk-xhci1.1.patch
This is a note to let you know that I've just added the patch titled
USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-uas-and-storage-add-us_fl_broken_fua-for-another-jmicron-jms567-id.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 62354454625741f0569c2cbe45b2d192f8fd258e Mon Sep 17 00:00:00 2001
From: David Kozub <zub(a)linux.fjfi.cvut.cz>
Date: Tue, 5 Dec 2017 22:40:04 +0100
Subject: USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID
From: David Kozub <zub(a)linux.fjfi.cvut.cz>
commit 62354454625741f0569c2cbe45b2d192f8fd258e upstream.
There is another JMS567-based USB3 UAS enclosure (152d:0578) that fails
with the following error:
[sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[sda] tag#0 Sense Key : Illegal Request [current]
[sda] tag#0 Add. Sense: Invalid field in cdb
The issue occurs both with UAS (occasionally) and mass storage
(immediately after mounting a FS on a disk in the enclosure).
Enabling US_FL_BROKEN_FUA quirk solves this issue.
This patch adds an UNUSUAL_DEV with US_FL_BROKEN_FUA for the enclosure
for both UAS and mass storage.
Signed-off-by: David Kozub <zub(a)linux.fjfi.cvut.cz>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/unusual_devs.h | 7 +++++++
drivers/usb/storage/unusual_uas.h | 7 +++++++
2 files changed, 14 insertions(+)
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2113,6 +2113,13 @@ UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_BROKEN_FUA ),
+/* Reported by David Kozub <zub(a)linux.fjfi.cvut.cz> */
+UNUSUAL_DEV(0x152d, 0x0578, 0x0000, 0x9999,
+ "JMicron",
+ "JMS567",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BROKEN_FUA),
+
/*
* Reported by Alexandre Oliva <oliva(a)lsd.ic.unicamp.br>
* JMicron responds to USN and several other SCSI ioctls with a
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -142,6 +142,13 @@ UNUSUAL_DEV(0x152d, 0x0567, 0x0000, 0x99
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_BROKEN_FUA | US_FL_NO_REPORT_OPCODES),
+/* Reported-by: David Kozub <zub(a)linux.fjfi.cvut.cz> */
+UNUSUAL_DEV(0x152d, 0x0578, 0x0000, 0x9999,
+ "JMicron",
+ "JMS567",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BROKEN_FUA),
+
/* Reported-by: Hans de Goede <hdegoede(a)redhat.com> */
UNUSUAL_DEV(0x2109, 0x0711, 0x0000, 0x9999,
"VIA",
Patches currently in stable-queue which might be from zub(a)linux.fjfi.cvut.cz are
queue-4.14/usb-uas-and-storage-add-us_fl_broken_fua-for-another-jmicron-jms567-id.patch
This is a note to let you know that I've just added the patch titled
tracing: Allocate mask_str buffer dynamically
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tracing-allocate-mask_str-buffer-dynamically.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 90e406f96f630c07d631a021fd4af10aac913e77 Mon Sep 17 00:00:00 2001
From: Changbin Du <changbin.du(a)intel.com>
Date: Thu, 30 Nov 2017 11:39:43 +0800
Subject: tracing: Allocate mask_str buffer dynamically
From: Changbin Du <changbin.du(a)intel.com>
commit 90e406f96f630c07d631a021fd4af10aac913e77 upstream.
The default NR_CPUS can be very large, but actual possible nr_cpu_ids
usually is very small. For my x86 distribution, the NR_CPUS is 8192 and
nr_cpu_ids is 4. About 2 pages are wasted.
Most machines don't have so many CPUs, so define a array with NR_CPUS
just wastes memory. So let's allocate the buffer dynamically when need.
With this change, the mutext tracing_cpumask_update_lock also can be
removed now, which was used to protect mask_str.
Link: http://lkml.kernel.org/r/1512013183-19107-1-git-send-email-changbin.du@inte…
Fixes: 36dfe9252bd4c ("ftrace: make use of tracing_cpumask")
Signed-off-by: Changbin Du <changbin.du(a)intel.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/trace/trace.c | 29 +++++++++--------------------
1 file changed, 9 insertions(+), 20 deletions(-)
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4178,37 +4178,30 @@ static const struct file_operations show
.llseek = seq_lseek,
};
-/*
- * The tracer itself will not take this lock, but still we want
- * to provide a consistent cpumask to user-space:
- */
-static DEFINE_MUTEX(tracing_cpumask_update_lock);
-
-/*
- * Temporary storage for the character representation of the
- * CPU bitmask (and one more byte for the newline):
- */
-static char mask_str[NR_CPUS + 1];
-
static ssize_t
tracing_cpumask_read(struct file *filp, char __user *ubuf,
size_t count, loff_t *ppos)
{
struct trace_array *tr = file_inode(filp)->i_private;
+ char *mask_str;
int len;
- mutex_lock(&tracing_cpumask_update_lock);
+ len = snprintf(NULL, 0, "%*pb\n",
+ cpumask_pr_args(tr->tracing_cpumask)) + 1;
+ mask_str = kmalloc(len, GFP_KERNEL);
+ if (!mask_str)
+ return -ENOMEM;
- len = snprintf(mask_str, count, "%*pb\n",
+ len = snprintf(mask_str, len, "%*pb\n",
cpumask_pr_args(tr->tracing_cpumask));
if (len >= count) {
count = -EINVAL;
goto out_err;
}
- count = simple_read_from_buffer(ubuf, count, ppos, mask_str, NR_CPUS+1);
+ count = simple_read_from_buffer(ubuf, count, ppos, mask_str, len);
out_err:
- mutex_unlock(&tracing_cpumask_update_lock);
+ kfree(mask_str);
return count;
}
@@ -4228,8 +4221,6 @@ tracing_cpumask_write(struct file *filp,
if (err)
goto err_unlock;
- mutex_lock(&tracing_cpumask_update_lock);
-
local_irq_disable();
arch_spin_lock(&tr->max_lock);
for_each_tracing_cpu(cpu) {
@@ -4252,8 +4243,6 @@ tracing_cpumask_write(struct file *filp,
local_irq_enable();
cpumask_copy(tr->tracing_cpumask, tracing_cpumask_new);
-
- mutex_unlock(&tracing_cpumask_update_lock);
free_cpumask_var(tracing_cpumask_new);
return count;
Patches currently in stable-queue which might be from changbin.du(a)intel.com are
queue-4.14/tracing-allocate-mask_str-buffer-dynamically.patch
This is a note to let you know that I've just added the patch titled
USB: core: prevent malicious bNumInterfaces overflow
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-core-prevent-malicious-bnuminterfaces-overflow.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 48a4ff1c7bb5a32d2e396b03132d20d552c0eca7 Mon Sep 17 00:00:00 2001
From: Alan Stern <stern(a)rowland.harvard.edu>
Date: Tue, 12 Dec 2017 14:25:13 -0500
Subject: USB: core: prevent malicious bNumInterfaces overflow
From: Alan Stern <stern(a)rowland.harvard.edu>
commit 48a4ff1c7bb5a32d2e396b03132d20d552c0eca7 upstream.
A malicious USB device with crafted descriptors can cause the kernel
to access unallocated memory by setting the bNumInterfaces value too
high in a configuration descriptor. Although the value is adjusted
during parsing, this adjustment is skipped in one of the error return
paths.
This patch prevents the problem by setting bNumInterfaces to 0
initially. The existing code already sets it to the proper value
after parsing is complete.
Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/config.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -555,6 +555,9 @@ static int usb_parse_configuration(struc
unsigned iad_num = 0;
memcpy(&config->desc, buffer, USB_DT_CONFIG_SIZE);
+ nintf = nintf_orig = config->desc.bNumInterfaces;
+ config->desc.bNumInterfaces = 0; // Adjusted later
+
if (config->desc.bDescriptorType != USB_DT_CONFIG ||
config->desc.bLength < USB_DT_CONFIG_SIZE ||
config->desc.bLength > size) {
@@ -568,7 +571,6 @@ static int usb_parse_configuration(struc
buffer += config->desc.bLength;
size -= config->desc.bLength;
- nintf = nintf_orig = config->desc.bNumInterfaces;
if (nintf > USB_MAXINTERFACES) {
dev_warn(ddev, "config %d has too many interfaces: %d, "
"using maximum allowed: %d\n",
Patches currently in stable-queue which might be from stern(a)rowland.harvard.edu are
queue-4.14/usb-core-prevent-malicious-bnuminterfaces-overflow.patch
queue-4.14/usb-uas-and-storage-add-us_fl_broken_fua-for-another-jmicron-jms567-id.patch
This is a note to let you know that I've just added the patch titled
scsi: libsas: fix length error in sas_smp_handler()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-libsas-fix-length-error-in-sas_smp_handler.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 621f6401fdeefe96dfe9eab4b167c7c39f552bb0 Mon Sep 17 00:00:00 2001
From: Jason Yan <yanaijie(a)huawei.com>
Date: Mon, 11 Dec 2017 15:03:33 +0800
Subject: scsi: libsas: fix length error in sas_smp_handler()
From: Jason Yan <yanaijie(a)huawei.com>
commit 621f6401fdeefe96dfe9eab4b167c7c39f552bb0 upstream.
The return value of smp_execute_task_sg() is the untransferred residual,
but bsg_job_done() requires the length of payload received. This makes
SMP passthrough commands from userland by sg ioctl to libsas get a wrong
response. The userland tools such as smp_utils failed because of these
wrong responses:
~#smp_discover /dev/bsg/expander-2\:13
response too short, len=0
~#smp_discover /dev/bsg/expander-2\:134
response too short, len=0
Fix this by passing the actual received length to bsg_job_done(). And if
smp_execute_task_sg() returns 0, this means received length is exactly
the buffer length.
[mkp: typo]
Fixes: 651a01364994 ("scsi: scsi_transport_sas: switch to bsg-lib for SMP passthrough")
Signed-off-by: Jason Yan <yanaijie(a)huawei.com>
Reported-by: chenqilin <chenqilin2(a)huawei.com>
Tested-by: chenqilin <chenqilin2(a)huawei.com>
CC: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/libsas/sas_expander.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -2145,7 +2145,7 @@ void sas_smp_handler(struct bsg_job *job
struct sas_rphy *rphy)
{
struct domain_device *dev;
- unsigned int reslen = 0;
+ unsigned int rcvlen = 0;
int ret = -EINVAL;
/* no rphy means no smp target support (ie aic94xx host) */
@@ -2179,12 +2179,12 @@ void sas_smp_handler(struct bsg_job *job
ret = smp_execute_task_sg(dev, job->request_payload.sg_list,
job->reply_payload.sg_list);
- if (ret > 0) {
- /* positive number is the untransferred residual */
- reslen = ret;
+ if (ret >= 0) {
+ /* bsg_job_done() requires the length received */
+ rcvlen = job->reply_payload.payload_len - ret;
ret = 0;
}
out:
- bsg_job_done(job, ret, reslen);
+ bsg_job_done(job, ret, rcvlen);
}
Patches currently in stable-queue which might be from yanaijie(a)huawei.com are
queue-4.14/scsi-libsas-fix-length-error-in-sas_smp_handler.patch
This is a note to let you know that I've just added the patch titled
SUNRPC: Fix a race in the receive code path
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sunrpc-fix-a-race-in-the-receive-code-path.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 90d91b0cd371193d9dbfa9beacab8ab9a4cb75e0 Mon Sep 17 00:00:00 2001
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Thu, 14 Dec 2017 21:24:08 -0500
Subject: SUNRPC: Fix a race in the receive code path
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
commit 90d91b0cd371193d9dbfa9beacab8ab9a4cb75e0 upstream.
We must ensure that the call to rpc_sleep_on() in xprt_transmit() cannot
race with the call to xprt_complete_rqst().
Reported-by: Chuck Lever <chuck.lever(a)oracle.com>
Link: https://bugzilla.linux-nfs.org/show_bug.cgi?id=317
Fixes: ce7c252a8c74 ("SUNRPC: Add a separate spinlock to protect..")
Reviewed-by: Chuck Lever <chuck.lever(a)oracle.com>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sunrpc/xprt.c | 28 +++++++++++++++++++---------
1 file changed, 19 insertions(+), 9 deletions(-)
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -1001,6 +1001,7 @@ void xprt_transmit(struct rpc_task *task
{
struct rpc_rqst *req = task->tk_rqstp;
struct rpc_xprt *xprt = req->rq_xprt;
+ unsigned int connect_cookie;
int status, numreqs;
dprintk("RPC: %5u xprt_transmit(%u)\n", task->tk_pid, req->rq_slen);
@@ -1024,6 +1025,7 @@ void xprt_transmit(struct rpc_task *task
} else if (!req->rq_bytes_sent)
return;
+ connect_cookie = xprt->connect_cookie;
req->rq_xtime = ktime_get();
status = xprt->ops->send_request(task);
trace_xprt_transmit(xprt, req->rq_xid, status);
@@ -1047,20 +1049,28 @@ void xprt_transmit(struct rpc_task *task
xprt->stat.bklog_u += xprt->backlog.qlen;
xprt->stat.sending_u += xprt->sending.qlen;
xprt->stat.pending_u += xprt->pending.qlen;
+ spin_unlock_bh(&xprt->transport_lock);
- /* Don't race with disconnect */
- if (!xprt_connected(xprt))
- task->tk_status = -ENOTCONN;
- else {
+ req->rq_connect_cookie = connect_cookie;
+ if (rpc_reply_expected(task) && !READ_ONCE(req->rq_reply_bytes_recvd)) {
/*
- * Sleep on the pending queue since
- * we're expecting a reply.
+ * Sleep on the pending queue if we're expecting a reply.
+ * The spinlock ensures atomicity between the test of
+ * req->rq_reply_bytes_recvd, and the call to rpc_sleep_on().
*/
- if (!req->rq_reply_bytes_recvd && rpc_reply_expected(task))
+ spin_lock(&xprt->recv_lock);
+ if (!req->rq_reply_bytes_recvd) {
rpc_sleep_on(&xprt->pending, task, xprt_timer);
- req->rq_connect_cookie = xprt->connect_cookie;
+ /*
+ * Send an extra queue wakeup call if the
+ * connection was dropped in case the call to
+ * rpc_sleep_on() raced.
+ */
+ if (!xprt_connected(xprt))
+ xprt_wake_pending_tasks(xprt, -ENOTCONN);
+ }
+ spin_unlock(&xprt->recv_lock);
}
- spin_unlock_bh(&xprt->transport_lock);
}
static void xprt_add_backlog(struct rpc_xprt *xprt, struct rpc_task *task)
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.14/sunrpc-fix-a-race-in-the-receive-code-path.patch
This is a note to let you know that I've just added the patch titled
scsi: core: Fix a scsi_show_rq() NULL pointer dereference
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-core-fix-a-scsi_show_rq-null-pointer-dereference.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 14e3062fb18532175af4d1c4073597999f7a2248 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Tue, 5 Dec 2017 16:57:51 -0800
Subject: scsi: core: Fix a scsi_show_rq() NULL pointer dereference
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit 14e3062fb18532175af4d1c4073597999f7a2248 upstream.
Avoid that scsi_show_rq() triggers a NULL pointer dereference if called
after sd_uninit_command(). Swap the NULL pointer assignment and the
mempool_free() call in sd_uninit_command() to make it less likely that
scsi_show_rq() triggers a use-after-free. Note: even with these changes
scsi_show_rq() can trigger a use-after-free but that's a lesser evil
than e.g. suppressing debug information for T10 PI Type 2 commands
completely. This patch fixes the following oops:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: scsi_format_opcode_name+0x1a/0x1c0
CPU: 1 PID: 1881 Comm: cat Not tainted 4.14.0-rc2.blk_mq_io_hang+ #516
Call Trace:
__scsi_format_command+0x27/0xc0
scsi_show_rq+0x5c/0xc0
__blk_mq_debugfs_rq_show+0x116/0x130
blk_mq_debugfs_rq_show+0xe/0x10
seq_read+0xfe/0x3b0
full_proxy_read+0x54/0x90
__vfs_read+0x37/0x160
vfs_read+0x96/0x130
SyS_read+0x55/0xc0
entry_SYSCALL_64_fastpath+0x1a/0xa5
[mkp: added Type 2]
Fixes: 0eebd005dd07 ("scsi: Implement blk_mq_ops.show_rq()")
Reported-by: Ming Lei <ming.lei(a)redhat.com>
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: James E.J. Bottomley <jejb(a)linux.vnet.ibm.com>
Cc: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: Ming Lei <ming.lei(a)redhat.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/scsi_debugfs.c | 6 ++++--
drivers/scsi/sd.c | 4 +++-
2 files changed, 7 insertions(+), 3 deletions(-)
--- a/drivers/scsi/scsi_debugfs.c
+++ b/drivers/scsi/scsi_debugfs.c
@@ -8,9 +8,11 @@ void scsi_show_rq(struct seq_file *m, st
{
struct scsi_cmnd *cmd = container_of(scsi_req(rq), typeof(*cmd), req);
int msecs = jiffies_to_msecs(jiffies - cmd->jiffies_at_alloc);
- char buf[80];
+ const u8 *const cdb = READ_ONCE(cmd->cmnd);
+ char buf[80] = "(?)";
- __scsi_format_command(buf, sizeof(buf), cmd->cmnd, cmd->cmd_len);
+ if (cdb)
+ __scsi_format_command(buf, sizeof(buf), cdb, cmd->cmd_len);
seq_printf(m, ", .cmd=%s, .retries=%d, allocated %d.%03d s ago", buf,
cmd->retries, msecs / 1000, msecs % 1000);
}
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1284,6 +1284,7 @@ static int sd_init_command(struct scsi_c
static void sd_uninit_command(struct scsi_cmnd *SCpnt)
{
struct request *rq = SCpnt->request;
+ u8 *cmnd;
if (SCpnt->flags & SCMD_ZONE_WRITE_LOCK)
sd_zbc_write_unlock_zone(SCpnt);
@@ -1292,9 +1293,10 @@ static void sd_uninit_command(struct scs
__free_page(rq->special_vec.bv_page);
if (SCpnt->cmnd != scsi_req(rq)->cmd) {
- mempool_free(SCpnt->cmnd, sd_cdb_pool);
+ cmnd = SCpnt->cmnd;
SCpnt->cmnd = NULL;
SCpnt->cmd_len = 0;
+ mempool_free(cmnd, sd_cdb_pool);
}
}
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.14/scsi-core-fix-a-scsi_show_rq-null-pointer-dereference.patch
This is a note to let you know that I've just added the patch titled
sched/rt: Do not pull from current CPU if only one CPU to pull
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sched-rt-do-not-pull-from-current-cpu-if-only-one-cpu-to-pull.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f73c52a5bcd1710994e53fbccc378c42b97a06b6 Mon Sep 17 00:00:00 2001
From: Steven Rostedt <rostedt(a)goodmis.org>
Date: Sat, 2 Dec 2017 13:04:54 -0500
Subject: sched/rt: Do not pull from current CPU if only one CPU to pull
From: Steven Rostedt <rostedt(a)goodmis.org>
commit f73c52a5bcd1710994e53fbccc378c42b97a06b6 upstream.
Daniel Wagner reported a crash on the BeagleBone Black SoC.
This is a single CPU architecture, and does not have a functional
arch_send_call_function_single_ipi() implementation which can crash
the kernel if that is called.
As it only has one CPU, it shouldn't be called, but if the kernel is
compiled for SMP, the push/pull RT scheduling logic now calls it for
irq_work if the one CPU is overloaded, it can use that function to call
itself and crash the kernel.
Ideally, we should disable the SCHED_FEAT(RT_PUSH_IPI) if the system
only has a single CPU. But SCHED_FEAT is a constant if sched debugging
is turned off. Another fix can also be used, and this should also help
with normal SMP machines. That is, do not initiate the pull code if
there's only one RT overloaded CPU, and that CPU happens to be the
current CPU that is scheduling in a lower priority task.
Even on a system with many CPUs, if there's many RT tasks waiting to
run on a single CPU, and that CPU schedules in another RT task of lower
priority, it will initiate the PULL logic in case there's a higher
priority RT task on another CPU that is waiting to run. But if there is
no other CPU with waiting RT tasks, it will initiate the RT pull logic
on itself (as it still has RT tasks waiting to run). This is a wasted
effort.
Not only does this help with SMP code where the current CPU is the only
one with RT overloaded tasks, it should also solve the issue that
Daniel encountered, because it will prevent the PULL logic from
executing, as there's only one CPU on the system, and the check added
here will cause it to exit the RT pull code.
Reported-by: Daniel Wagner <wagi(a)monom.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Acked-by: Peter Zijlstra <peterz(a)infradead.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-rt-users <linux-rt-users(a)vger.kernel.org>
Fixes: 4bdced5c9 ("sched/rt: Simplify the IPI based RT balancing logic")
Link: http://lkml.kernel.org/r/20171202130454.4cbbfe8d@vmware.local.home
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/sched/rt.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2034,8 +2034,9 @@ static void pull_rt_task(struct rq *this
bool resched = false;
struct task_struct *p;
struct rq *src_rq;
+ int rt_overload_count = rt_overloaded(this_rq);
- if (likely(!rt_overloaded(this_rq)))
+ if (likely(!rt_overload_count))
return;
/*
@@ -2044,6 +2045,11 @@ static void pull_rt_task(struct rq *this
*/
smp_rmb();
+ /* If we are the only overloaded CPU do nothing */
+ if (rt_overload_count == 1 &&
+ cpumask_test_cpu(this_rq->cpu, this_rq->rd->rto_mask))
+ return;
+
#ifdef HAVE_RT_PUSH_IPI
if (sched_feat(RT_PUSH_IPI)) {
tell_cpu_to_push(this_rq);
Patches currently in stable-queue which might be from rostedt(a)goodmis.org are
queue-4.14/sched-rt-do-not-pull-from-current-cpu-if-only-one-cpu-to-pull.patch
queue-4.14/tracing-allocate-mask_str-buffer-dynamically.patch
This is a note to let you know that I've just added the patch titled
Revert "exec: avoid RLIMIT_STACK races with prlimit()"
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-exec-avoid-rlimit_stack-races-with-prlimit.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 779f4e1c6c7c661db40dfebd6dd6bda7b5f88aa3 Mon Sep 17 00:00:00 2001
From: Kees Cook <keescook(a)chromium.org>
Date: Tue, 12 Dec 2017 11:28:38 -0800
Subject: Revert "exec: avoid RLIMIT_STACK races with prlimit()"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Kees Cook <keescook(a)chromium.org>
commit 779f4e1c6c7c661db40dfebd6dd6bda7b5f88aa3 upstream.
This reverts commit 04e35f4495dd560db30c25efca4eecae8ec8c375.
SELinux runs with secureexec for all non-"noatsecure" domain transitions,
which means lots of processes end up hitting the stack hard-limit change
that was introduced in order to fix a race with prlimit(). That race fix
will need to be redesigned.
Reported-by: Laura Abbott <labbott(a)redhat.com>
Reported-by: Tomáš Trnka <trnka(a)scm.com>
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/exec.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1340,15 +1340,10 @@ void setup_new_exec(struct linux_binprm
* avoid bad behavior from the prior rlimits. This has to
* happen before arch_pick_mmap_layout(), which examines
* RLIMIT_STACK, but after the point of no return to avoid
- * races from other threads changing the limits. This also
- * must be protected from races with prlimit() calls.
+ * needing to clean up the change on failure.
*/
- task_lock(current->group_leader);
if (current->signal->rlim[RLIMIT_STACK].rlim_cur > _STK_LIM)
current->signal->rlim[RLIMIT_STACK].rlim_cur = _STK_LIM;
- if (current->signal->rlim[RLIMIT_STACK].rlim_max > _STK_LIM)
- current->signal->rlim[RLIMIT_STACK].rlim_max = _STK_LIM;
- task_unlock(current->group_leader);
}
arch_pick_mmap_layout(current->mm);
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.14/revert-exec-avoid-rlimit_stack-races-with-prlimit.patch
queue-4.14/string.h-workaround-for-increased-stack-usage.patch
queue-4.14/arm64-fix-config_debug_wx-address-reporting.patch
This is a note to let you know that I've just added the patch titled
ovl: update ctx->pos on impure dir iteration
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ovl-update-ctx-pos-on-impure-dir-iteration.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b02a16e6413a2f782e542ef60bad9ff6bf212f8a Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Wed, 29 Nov 2017 07:35:21 +0200
Subject: ovl: update ctx->pos on impure dir iteration
From: Amir Goldstein <amir73il(a)gmail.com>
commit b02a16e6413a2f782e542ef60bad9ff6bf212f8a upstream.
This fixes a regression with readdir of impure dir in overlayfs
that is shared to VM via 9p fs.
Reported-by: Miguel Bernal Marin <miguel.bernal.marin(a)linux.intel.com>
Fixes: 4edb83bb1041 ("ovl: constant d_ino for non-merge dirs")
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Tested-by: Miguel Bernal Marin <miguel.bernal.marin(a)linux.intel.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/overlayfs/readdir.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -645,7 +645,10 @@ static int ovl_iterate_real(struct file
return PTR_ERR(rdt.cache);
}
- return iterate_dir(od->realfile, &rdt.ctx);
+ err = iterate_dir(od->realfile, &rdt.ctx);
+ ctx->pos = rdt.ctx.pos;
+
+ return err;
}
Patches currently in stable-queue which might be from amir73il(a)gmail.com are
queue-4.14/ovl-pass-ovl_get_nlink-parameters-in-right-order.patch
queue-4.14/ovl-update-ctx-pos-on-impure-dir-iteration.patch
This is a note to let you know that I've just added the patch titled
posix-timer: Properly check sigevent->sigev_notify
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
posix-timer-properly-check-sigevent-sigev_notify.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From cef31d9af908243421258f1df35a4a644604efbe Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <tglx(a)linutronix.de>
Date: Fri, 15 Dec 2017 10:32:03 +0100
Subject: posix-timer: Properly check sigevent->sigev_notify
From: Thomas Gleixner <tglx(a)linutronix.de>
commit cef31d9af908243421258f1df35a4a644604efbe upstream.
timer_create() specifies via sigevent->sigev_notify the signal delivery for
the new timer. The valid modes are SIGEV_NONE, SIGEV_SIGNAL, SIGEV_THREAD
and (SIGEV_SIGNAL | SIGEV_THREAD_ID).
The sanity check in good_sigevent() is only checking the valid combination
for the SIGEV_THREAD_ID bit, i.e. SIGEV_SIGNAL, but if SIGEV_THREAD_ID is
not set it accepts any random value.
This has no real effects on the posix timer and signal delivery code, but
it affects show_timer() which handles the output of /proc/$PID/timers. That
function uses a string array to pretty print sigev_notify. The access to
that array has no bound checks, so random sigev_notify cause access beyond
the array bounds.
Add proper checks for the valid notify modes and remove the SIGEV_THREAD_ID
masking from various code pathes as SIGEV_NONE can never be set in
combination with SIGEV_THREAD_ID.
Reported-by: Eric Biggers <ebiggers3(a)gmail.com>
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Reported-by: Alexey Dobriyan <adobriyan(a)gmail.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/posix-timers.c | 29 +++++++++++++++++------------
1 file changed, 17 insertions(+), 12 deletions(-)
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -434,17 +434,22 @@ static struct pid *good_sigevent(sigeven
{
struct task_struct *rtn = current->group_leader;
- if ((event->sigev_notify & SIGEV_THREAD_ID ) &&
- (!(rtn = find_task_by_vpid(event->sigev_notify_thread_id)) ||
- !same_thread_group(rtn, current) ||
- (event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_SIGNAL))
+ switch (event->sigev_notify) {
+ case SIGEV_SIGNAL | SIGEV_THREAD_ID:
+ rtn = find_task_by_vpid(event->sigev_notify_thread_id);
+ if (!rtn || !same_thread_group(rtn, current))
+ return NULL;
+ /* FALLTHRU */
+ case SIGEV_SIGNAL:
+ case SIGEV_THREAD:
+ if (event->sigev_signo <= 0 || event->sigev_signo > SIGRTMAX)
+ return NULL;
+ /* FALLTHRU */
+ case SIGEV_NONE:
+ return task_pid(rtn);
+ default:
return NULL;
-
- if (((event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_NONE) &&
- ((event->sigev_signo <= 0) || (event->sigev_signo > SIGRTMAX)))
- return NULL;
-
- return task_pid(rtn);
+ }
}
static struct k_itimer * alloc_posix_timer(void)
@@ -669,7 +674,7 @@ void common_timer_get(struct k_itimer *t
struct timespec64 ts64;
bool sig_none;
- sig_none = (timr->it_sigev_notify & ~SIGEV_THREAD_ID) == SIGEV_NONE;
+ sig_none = timr->it_sigev_notify == SIGEV_NONE;
iv = timr->it_interval;
/* interval timer ? */
@@ -856,7 +861,7 @@ int common_timer_set(struct k_itimer *ti
timr->it_interval = timespec64_to_ktime(new_setting->it_interval);
expires = timespec64_to_ktime(new_setting->it_value);
- sigev_none = (timr->it_sigev_notify & ~SIGEV_THREAD_ID) == SIGEV_NONE;
+ sigev_none = timr->it_sigev_notify == SIGEV_NONE;
kc->timer_arm(timr, expires, flags & TIMER_ABSTIME, sigev_none);
timr->it_active = !sigev_none;
Patches currently in stable-queue which might be from tglx(a)linutronix.de are
queue-4.14/sched-rt-do-not-pull-from-current-cpu-if-only-one-cpu-to-pull.patch
queue-4.14/x86-boot-compressed-64-print-error-if-5-level-paging-is-not-supported.patch
queue-4.14/posix-timer-properly-check-sigevent-sigev_notify.patch
queue-4.14/x86-boot-compressed-64-detect-and-handle-5-level-paging-at-boot-time.patch
This is a note to let you know that I've just added the patch titled
ovl: Pass ovl_get_nlink() parameters in right order
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ovl-pass-ovl_get_nlink-parameters-in-right-order.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 08d8f8a5b094b66b29936e8751b4a818b8db1207 Mon Sep 17 00:00:00 2001
From: Vivek Goyal <vgoyal(a)redhat.com>
Date: Mon, 27 Nov 2017 10:12:44 -0500
Subject: ovl: Pass ovl_get_nlink() parameters in right order
From: Vivek Goyal <vgoyal(a)redhat.com>
commit 08d8f8a5b094b66b29936e8751b4a818b8db1207 upstream.
Right now we seem to be passing index as "lowerdentry" and origin.dentry
as "upperdentry". IIUC, we should pass these parameters in reversed order
and this looks like a bug.
Signed-off-by: Vivek Goyal <vgoyal(a)redhat.com>
Acked-by: Amir Goldstein <amir73il(a)gmail.com>
Fixes: caf70cb2ba5d ("ovl: cleanup orphan index entries")
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/overlayfs/namei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/overlayfs/namei.c
+++ b/fs/overlayfs/namei.c
@@ -437,7 +437,7 @@ int ovl_verify_index(struct dentry *inde
/* Check if index is orphan and don't warn before cleaning it */
if (d_inode(index)->i_nlink == 1 &&
- ovl_get_nlink(index, origin.dentry, 0) == 0)
+ ovl_get_nlink(origin.dentry, index, 0) == 0)
err = -ENOENT;
dput(origin.dentry);
Patches currently in stable-queue which might be from vgoyal(a)redhat.com are
queue-4.14/ovl-pass-ovl_get_nlink-parameters-in-right-order.patch
This is a note to let you know that I've just added the patch titled
nfs: don't wait on commit in nfs_commit_inode() if there were no commit requests
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfs-don-t-wait-on-commit-in-nfs_commit_inode-if-there-were-no-commit-requests.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From dc4fd9ab01ab379ae5af522b3efd4187a7c30a31 Mon Sep 17 00:00:00 2001
From: Scott Mayhew <smayhew(a)redhat.com>
Date: Fri, 8 Dec 2017 16:00:12 -0500
Subject: nfs: don't wait on commit in nfs_commit_inode() if there were no commit requests
From: Scott Mayhew <smayhew(a)redhat.com>
commit dc4fd9ab01ab379ae5af522b3efd4187a7c30a31 upstream.
If there were no commit requests, then nfs_commit_inode() should not
wait on the commit or mark the inode dirty, otherwise the following
BUG_ON can be triggered:
[ 1917.130762] kernel BUG at fs/inode.c:578!
[ 1917.130766] Oops: Exception in kernel mode, sig: 5 [#1]
[ 1917.130768] SMP NR_CPUS=2048 NUMA pSeries
[ 1917.130772] Modules linked in: iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi blocklayoutdriver rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache sunrpc sg nx_crypto pseries_rng ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic crct10dif_common ibmvscsi scsi_transport_srp ibmveth scsi_tgt dm_mirror dm_region_hash dm_log dm_mod
[ 1917.130805] CPU: 2 PID: 14923 Comm: umount.nfs4 Tainted: G ------------ T 3.10.0-768.el7.ppc64 #1
[ 1917.130810] task: c0000005ecd88040 ti: c00000004cea0000 task.ti: c00000004cea0000
[ 1917.130813] NIP: c000000000354178 LR: c000000000354160 CTR: c00000000012db80
[ 1917.130816] REGS: c00000004cea3720 TRAP: 0700 Tainted: G ------------ T (3.10.0-768.el7.ppc64)
[ 1917.130820] MSR: 8000000100029032 <SF,EE,ME,IR,DR,RI> CR: 22002822 XER: 20000000
[ 1917.130828] CFAR: c00000000011f594 SOFTE: 1
GPR00: c000000000354160 c00000004cea39a0 c0000000014c4700 c0000000018cc750
GPR04: 000000000000c750 80c0000000000000 0600000000000000 04eeb76bea749a03
GPR08: 0000000000000034 c0000000018cc758 0000000000000001 d000000005e619e8
GPR12: c00000000012db80 c000000007b31200 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR24: 0000000000000000 c000000000dfc3ec 0000000000000000 c0000005eefc02c0
GPR28: d0000000079dbd50 c0000005b94a02c0 c0000005b94a0250 c0000005b94a01c8
[ 1917.130867] NIP [c000000000354178] .evict+0x1c8/0x350
[ 1917.130871] LR [c000000000354160] .evict+0x1b0/0x350
[ 1917.130873] Call Trace:
[ 1917.130876] [c00000004cea39a0] [c000000000354160] .evict+0x1b0/0x350 (unreliable)
[ 1917.130880] [c00000004cea3a30] [c0000000003558cc] .evict_inodes+0x13c/0x270
[ 1917.130884] [c00000004cea3af0] [c000000000327d20] .kill_anon_super+0x70/0x1e0
[ 1917.130896] [c00000004cea3b80] [d000000005e43e30] .nfs_kill_super+0x20/0x60 [nfs]
[ 1917.130900] [c00000004cea3c00] [c000000000328a20] .deactivate_locked_super+0xa0/0x1b0
[ 1917.130903] [c00000004cea3c80] [c00000000035ba54] .cleanup_mnt+0xd4/0x180
[ 1917.130907] [c00000004cea3d10] [c000000000119034] .task_work_run+0x114/0x150
[ 1917.130912] [c00000004cea3db0] [c00000000001ba6c] .do_notify_resume+0xcc/0x100
[ 1917.130916] [c00000004cea3e30] [c00000000000a7b0] .ret_from_except_lite+0x5c/0x60
[ 1917.130919] Instruction dump:
[ 1917.130921] 7fc3f378 486734b5 60000000 387f00a0 38800003 4bdcb365 60000000 e95f00a0
[ 1917.130927] 694a0060 7d4a0074 794ad182 694a0001 <0b0a0000> 892d02a4 2f890000 40de0134
Signed-off-by: Scott Mayhew <smayhew(a)redhat.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/write.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1889,6 +1889,8 @@ int nfs_commit_inode(struct inode *inode
if (res)
error = nfs_generic_commit_list(inode, &head, how, &cinfo);
nfs_commit_end(cinfo.mds);
+ if (res == 0)
+ return res;
if (error < 0)
goto out_error;
if (!may_wait)
Patches currently in stable-queue which might be from smayhew(a)redhat.com are
queue-4.14/nfs-don-t-wait-on-commit-in-nfs_commit_inode-if-there-were-no-commit-requests.patch
This is a note to let you know that I've just added the patch titled
mmc: core: apply NO_CMD23 quirk to some specific cards
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mmc-core-apply-no_cmd23-quirk-to-some-specific-cards.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 91516a2a4734614d62ee3ed921f8f88acc67c000 Mon Sep 17 00:00:00 2001
From: Christoph Fritz <chf.fritz(a)googlemail.com>
Date: Sat, 9 Dec 2017 23:47:55 +0100
Subject: mmc: core: apply NO_CMD23 quirk to some specific cards
From: Christoph Fritz <chf.fritz(a)googlemail.com>
commit 91516a2a4734614d62ee3ed921f8f88acc67c000 upstream.
To get an usdhc Apacer and some ATP SD cards work reliable, CMD23 needs
to be disabled. This has been tested on i.MX6 (sdhci-esdhc) and rk3288
(dw_mmc-rockchip).
Without this patch on i.MX6 (sdhci-esdhc):
$ dd if=/dev/urandom of=/mnt/test bs=1M count=10 conv=fsync
| <mmc0: starting CMD23 arg 00000400 flags 00000015>
| mmc0: starting CMD25 arg 00a71f00 flags 000000b5
| mmc0: blksz 512 blocks 1024 flags 00000100 tsac 3000 ms nsac 0
| mmc0: CMD12 arg 00000000 flags 0000049d
| sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
| mmc0: Timeout waiting for hardware interrupt.
Without this patch on rk3288 (dw_mmc-rockchip):
| mmc1: Card stuck in programming state! mmcblk1 card_busy_detect
| dwmmc_rockchip ff0c0000.dwmmc: Busy; trying anyway
| mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz,
| actual 400000HZ div = 0)
| mmc1: card never left busy state
| mmc1: tried to reset card, got error -110
| blk_update_request: I/O error, dev mmcblk1, sector 139778
| Buffer I/O error on dev mmcblk1p1, logical block 131586, lost async
| page write
Signed-off-by: Christoph Fritz <chf.fritz(a)googlemail.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/core/card.h | 2 ++
drivers/mmc/core/quirks.h | 8 ++++++++
2 files changed, 10 insertions(+)
--- a/drivers/mmc/core/card.h
+++ b/drivers/mmc/core/card.h
@@ -75,9 +75,11 @@ struct mmc_fixup {
#define EXT_CSD_REV_ANY (-1u)
#define CID_MANFID_SANDISK 0x2
+#define CID_MANFID_ATP 0x9
#define CID_MANFID_TOSHIBA 0x11
#define CID_MANFID_MICRON 0x13
#define CID_MANFID_SAMSUNG 0x15
+#define CID_MANFID_APACER 0x27
#define CID_MANFID_KINGSTON 0x70
#define CID_MANFID_HYNIX 0x90
--- a/drivers/mmc/core/quirks.h
+++ b/drivers/mmc/core/quirks.h
@@ -53,6 +53,14 @@ static const struct mmc_fixup mmc_blk_fi
MMC_QUIRK_BLK_NO_CMD23),
/*
+ * Some SD cards lockup while using CMD23 multiblock transfers.
+ */
+ MMC_FIXUP("AF SD", CID_MANFID_ATP, CID_OEMID_ANY, add_quirk_sd,
+ MMC_QUIRK_BLK_NO_CMD23),
+ MMC_FIXUP("APUSD", CID_MANFID_APACER, 0x5048, add_quirk_sd,
+ MMC_QUIRK_BLK_NO_CMD23),
+
+ /*
* Some MMC cards need longer data read timeout than indicated in CSD.
*/
MMC_FIXUP(CID_NAME_ANY, CID_MANFID_MICRON, 0x200, add_quirk_mmc,
Patches currently in stable-queue which might be from chf.fritz(a)googlemail.com are
queue-4.14/mmc-core-apply-no_cmd23-quirk-to-some-specific-cards.patch
This is a note to let you know that I've just added the patch titled
mm, oom_reaper: fix memory corruption
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mm-oom_reaper-fix-memory-corruption.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4837fe37adff1d159904f0c013471b1ecbcb455e Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko(a)suse.com>
Date: Thu, 14 Dec 2017 15:33:15 -0800
Subject: mm, oom_reaper: fix memory corruption
From: Michal Hocko <mhocko(a)suse.com>
commit 4837fe37adff1d159904f0c013471b1ecbcb455e upstream.
David Rientjes has reported the following memory corruption while the
oom reaper tries to unmap the victims address space
BUG: Bad page map in process oom_reaper pte:6353826300000000 pmd:00000000
addr:00007f50cab1d000 vm_flags:08100073 anon_vma:ffff9eea335603f0 mapping: (null) index:7f50cab1d
file: (null) fault: (null) mmap: (null) readpage: (null)
CPU: 2 PID: 1001 Comm: oom_reaper
Call Trace:
unmap_page_range+0x1068/0x1130
__oom_reap_task_mm+0xd5/0x16b
oom_reaper+0xff/0x14c
kthread+0xc1/0xe0
Tetsuo Handa has noticed that the synchronization inside exit_mmap is
insufficient. We only synchronize with the oom reaper if
tsk_is_oom_victim which is not true if the final __mmput is called from
a different context than the oom victim exit path. This can trivially
happen from context of any task which has grabbed mm reference (e.g. to
read /proc/<pid>/ file which requires mm etc.).
The race would look like this
oom_reaper oom_victim task
mmget_not_zero
do_exit
mmput
__oom_reap_task_mm mmput
__mmput
exit_mmap
remove_vma
unmap_page_range
Fix this issue by providing a new mm_is_oom_victim() helper which
operates on the mm struct rather than a task. Any context which
operates on a remote mm struct should use this helper in place of
tsk_is_oom_victim. The flag is set in mark_oom_victim and never cleared
so it is stable in the exit_mmap path.
Debugged by Tetsuo Handa.
Link: http://lkml.kernel.org/r/20171210095130.17110-1-mhocko@kernel.org
Fixes: 212925802454 ("mm: oom: let oom_reap_task and exit_mmap run concurrently")
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: David Rientjes <rientjes(a)google.com>
Acked-by: David Rientjes <rientjes(a)google.com>
Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Cc: Andrea Argangeli <andrea(a)kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/oom.h | 9 +++++++++
include/linux/sched/coredump.h | 1 +
mm/mmap.c | 10 +++++-----
mm/oom_kill.c | 4 +++-
4 files changed, 18 insertions(+), 6 deletions(-)
--- a/include/linux/oom.h
+++ b/include/linux/oom.h
@@ -67,6 +67,15 @@ static inline bool tsk_is_oom_victim(str
}
/*
+ * Use this helper if tsk->mm != mm and the victim mm needs a special
+ * handling. This is guaranteed to stay true after once set.
+ */
+static inline bool mm_is_oom_victim(struct mm_struct *mm)
+{
+ return test_bit(MMF_OOM_VICTIM, &mm->flags);
+}
+
+/*
* Checks whether a page fault on the given mm is still reliable.
* This is no longer true if the oom reaper started to reap the
* address space which is reflected by MMF_UNSTABLE flag set in
--- a/include/linux/sched/coredump.h
+++ b/include/linux/sched/coredump.h
@@ -70,6 +70,7 @@ static inline int get_dumpable(struct mm
#define MMF_UNSTABLE 22 /* mm is unstable for copy_from_user */
#define MMF_HUGE_ZERO_PAGE 23 /* mm has ever used the global huge zero page */
#define MMF_DISABLE_THP 24 /* disable THP for all VMAs */
+#define MMF_OOM_VICTIM 25 /* mm is the oom victim */
#define MMF_DISABLE_THP_MASK (1 << MMF_DISABLE_THP)
#define MMF_INIT_MASK (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK |\
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3004,20 +3004,20 @@ void exit_mmap(struct mm_struct *mm)
/* Use -1 here to ensure all VMAs in the mm are unmapped */
unmap_vmas(&tlb, vma, 0, -1);
- set_bit(MMF_OOM_SKIP, &mm->flags);
- if (unlikely(tsk_is_oom_victim(current))) {
+ if (unlikely(mm_is_oom_victim(mm))) {
/*
* Wait for oom_reap_task() to stop working on this
* mm. Because MMF_OOM_SKIP is already set before
* calling down_read(), oom_reap_task() will not run
* on this "mm" post up_write().
*
- * tsk_is_oom_victim() cannot be set from under us
- * either because current->mm is already set to NULL
+ * mm_is_oom_victim() cannot be set from under us
+ * either because victim->mm is already set to NULL
* under task_lock before calling mmput and oom_mm is
- * set not NULL by the OOM killer only if current->mm
+ * set not NULL by the OOM killer only if victim->mm
* is found not NULL while holding the task_lock.
*/
+ set_bit(MMF_OOM_SKIP, &mm->flags);
down_write(&mm->mmap_sem);
up_write(&mm->mmap_sem);
}
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -673,8 +673,10 @@ static void mark_oom_victim(struct task_
return;
/* oom_mm is bound to the signal struct life time. */
- if (!cmpxchg(&tsk->signal->oom_mm, NULL, mm))
+ if (!cmpxchg(&tsk->signal->oom_mm, NULL, mm)) {
mmgrab(tsk->signal->oom_mm);
+ set_bit(MMF_OOM_VICTIM, &mm->flags);
+ }
/*
* Make sure that the task is woken up from uninterruptible sleep
Patches currently in stable-queue which might be from mhocko(a)suse.com are
queue-4.14/mm-oom_reaper-fix-memory-corruption.patch
This is a note to let you know that I've just added the patch titled
iw_cxgb4: only insert drain cqes if wq is flushed
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iw_cxgb4-only-insert-drain-cqes-if-wq-is-flushed.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c058ecf6e455fac7346d46197a02398ead90851f Mon Sep 17 00:00:00 2001
From: Steve Wise <swise(a)opengridcomputing.com>
Date: Mon, 27 Nov 2017 13:16:32 -0800
Subject: iw_cxgb4: only insert drain cqes if wq is flushed
From: Steve Wise <swise(a)opengridcomputing.com>
commit c058ecf6e455fac7346d46197a02398ead90851f upstream.
Only insert our special drain CQEs to support ib_drain_sq/rq() after
the wq is flushed. Otherwise, existing but not yet polled CQEs can be
returned out of order to the user application. This can happen when the
QP has exited RTS but not yet flushed the QP, which can happen during
a normal close (vs abortive close).
In addition never count the drain CQEs when determining how many CQEs
need to be synthesized during the flush operation. This latter issue
should never happen if the QP is properly flushed before inserting the
drain CQE, but I wanted to avoid corrupting the CQ state. So we handle
it and log a warning once.
Fixes: 4fe7c2962e11 ("iw_cxgb4: refactor sq/rq drain logic")
Signed-off-by: Steve Wise <swise(a)opengridcomputing.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/cxgb4/cq.c | 5 +++++
drivers/infiniband/hw/cxgb4/qp.c | 14 ++++++++++++--
2 files changed, 17 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/hw/cxgb4/cq.c
+++ b/drivers/infiniband/hw/cxgb4/cq.c
@@ -410,6 +410,11 @@ next_cqe:
static int cqe_completes_wr(struct t4_cqe *cqe, struct t4_wq *wq)
{
+ if (CQE_OPCODE(cqe) == C4IW_DRAIN_OPCODE) {
+ WARN_ONCE(1, "Unexpected DRAIN CQE qp id %u!\n", wq->sq.qid);
+ return 0;
+ }
+
if (CQE_OPCODE(cqe) == FW_RI_TERMINATE)
return 0;
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -868,7 +868,12 @@ int c4iw_post_send(struct ib_qp *ibqp, s
qhp = to_c4iw_qp(ibqp);
spin_lock_irqsave(&qhp->lock, flag);
- if (t4_wq_in_error(&qhp->wq)) {
+
+ /*
+ * If the qp has been flushed, then just insert a special
+ * drain cqe.
+ */
+ if (qhp->wq.flushed) {
spin_unlock_irqrestore(&qhp->lock, flag);
complete_sq_drain_wr(qhp, wr);
return err;
@@ -1012,7 +1017,12 @@ int c4iw_post_receive(struct ib_qp *ibqp
qhp = to_c4iw_qp(ibqp);
spin_lock_irqsave(&qhp->lock, flag);
- if (t4_wq_in_error(&qhp->wq)) {
+
+ /*
+ * If the qp has been flushed, then just insert a special
+ * drain cqe.
+ */
+ if (qhp->wq.flushed) {
spin_unlock_irqrestore(&qhp->lock, flag);
complete_rq_drain_wr(qhp, wr);
return err;
Patches currently in stable-queue which might be from swise(a)opengridcomputing.com are
queue-4.14/iw_cxgb4-only-insert-drain-cqes-if-wq-is-flushed.patch
This is a note to let you know that I've just added the patch titled
IB/core: Don't enforce PKey security on SMI MADs
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-core-don-t-enforce-pkey-security-on-smi-mads.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0fbe8f575b15585eec3326e43708fbbc024e8486 Mon Sep 17 00:00:00 2001
From: Daniel Jurgens <danielj(a)mellanox.com>
Date: Tue, 5 Dec 2017 22:30:02 +0200
Subject: IB/core: Don't enforce PKey security on SMI MADs
From: Daniel Jurgens <danielj(a)mellanox.com>
commit 0fbe8f575b15585eec3326e43708fbbc024e8486 upstream.
Per the infiniband spec an SMI MAD can have any PKey. Checking the pkey
on SMI MADs is not necessary, and it seems that some older adapters
using the mthca driver don't follow the convention of using the default
PKey, resulting in false denials, or errors querying the PKey cache.
SMI MAD security is still enforced, only agents allowed to manage the
subnet are able to receive or send SMI MADs.
Reported-by: Chris Blake <chrisrblake93(a)gmail.com>
Fixes: 47a2b338fe63 ("IB/core: Enforce security on management datagrams")
Signed-off-by: Daniel Jurgens <danielj(a)mellanox.com>
Reviewed-by: Parav Pandit <parav(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/security.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/core/security.c
+++ b/drivers/infiniband/core/security.c
@@ -739,8 +739,11 @@ int ib_mad_enforce_security(struct ib_ma
if (!rdma_protocol_ib(map->agent.device, map->agent.port_num))
return 0;
- if (map->agent.qp->qp_type == IB_QPT_SMI && !map->agent.smp_allowed)
- return -EACCES;
+ if (map->agent.qp->qp_type == IB_QPT_SMI) {
+ if (!map->agent.smp_allowed)
+ return -EACCES;
+ return 0;
+ }
return ib_security_pkey_access(map->agent.device,
map->agent.port_num,
Patches currently in stable-queue which might be from danielj(a)mellanox.com are
queue-4.14/ib-core-don-t-enforce-pkey-security-on-smi-mads.patch
queue-4.14/ib-core-bound-check-alternate-path-port-number.patch
This is a note to let you know that I've just added the patch titled
IB/core: Bound check alternate path port number
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-core-bound-check-alternate-path-port-number.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4cae8ff136782d77b108cb3a5ba53e60597ba3a6 Mon Sep 17 00:00:00 2001
From: Daniel Jurgens <danielj(a)mellanox.com>
Date: Tue, 5 Dec 2017 22:30:01 +0200
Subject: IB/core: Bound check alternate path port number
From: Daniel Jurgens <danielj(a)mellanox.com>
commit 4cae8ff136782d77b108cb3a5ba53e60597ba3a6 upstream.
The alternate port number is used as an array index in the IB
security implementation, invalid values can result in a kernel panic.
Fixes: d291f1a65232 ("IB/core: Enforce PKey security on QPs")
Signed-off-by: Daniel Jurgens <danielj(a)mellanox.com>
Reviewed-by: Parav Pandit <parav(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/uverbs_cmd.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -1982,6 +1982,12 @@ static int modify_qp(struct ib_uverbs_fi
goto release_qp;
}
+ if ((cmd->base.attr_mask & IB_QP_ALT_PATH) &&
+ !rdma_is_port_valid(qp->device, cmd->base.alt_port_num)) {
+ ret = -EINVAL;
+ goto release_qp;
+ }
+
attr->qp_state = cmd->base.qp_state;
attr->cur_qp_state = cmd->base.cur_qp_state;
attr->path_mtu = cmd->base.path_mtu;
Patches currently in stable-queue which might be from danielj(a)mellanox.com are
queue-4.14/ib-core-don-t-enforce-pkey-security-on-smi-mads.patch
queue-4.14/ib-core-bound-check-alternate-path-port-number.patch
This is a note to let you know that I've just added the patch titled
ext4: support fast symlinks from ext3 file systems
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ext4-support-fast-symlinks-from-ext3-file-systems.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From fc82228a5e3860502dbf3bfa4a9570cb7093cf7f Mon Sep 17 00:00:00 2001
From: Andi Kleen <ak(a)linux.intel.com>
Date: Sun, 3 Dec 2017 20:38:01 -0500
Subject: ext4: support fast symlinks from ext3 file systems
From: Andi Kleen <ak(a)linux.intel.com>
commit fc82228a5e3860502dbf3bfa4a9570cb7093cf7f upstream.
407cd7fb83c0 (ext4: change fast symlink test to not rely on i_blocks)
broke ~10 years old ext3 file systems created by 2.6.17. Any ELF
executable fails because the /lib/ld-linux.so.2 fast symlink
cannot be read anymore.
The patch assumed fast symlinks were created in a specific way,
but that's not true on these really old file systems.
The new behavior is apparently needed only with the large EA inode
feature.
Revert to the old behavior if the large EA inode feature is not set.
This makes my old VM boot again.
Fixes: 407cd7fb83c0 (ext4: change fast symlink test to not rely on i_blocks)
Signed-off-by: Andi Kleen <ak(a)linux.intel.com>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Reviewed-by: Andreas Dilger <adilger(a)dilger.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ext4/inode.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -149,6 +149,15 @@ static int ext4_meta_trans_blocks(struct
*/
int ext4_inode_is_fast_symlink(struct inode *inode)
{
+ if (!(EXT4_I(inode)->i_flags & EXT4_EA_INODE_FL)) {
+ int ea_blocks = EXT4_I(inode)->i_file_acl ?
+ EXT4_CLUSTER_SIZE(inode->i_sb) >> 9 : 0;
+
+ if (ext4_has_inline_data(inode))
+ return 0;
+
+ return (S_ISLNK(inode->i_mode) && inode->i_blocks - ea_blocks == 0);
+ }
return S_ISLNK(inode->i_mode) && inode->i_size &&
(inode->i_size < EXT4_N_BLOCKS * 4);
}
Patches currently in stable-queue which might be from ak(a)linux.intel.com are
queue-4.14/x86-boot-compressed-64-print-error-if-5-level-paging-is-not-supported.patch
queue-4.14/x86-boot-compressed-64-detect-and-handle-5-level-paging-at-boot-time.patch
queue-4.14/ext4-support-fast-symlinks-from-ext3-file-systems.patch
This is a note to let you know that I've just added the patch titled
ext4: fix fdatasync(2) after fallocate(2) operation
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ext4-fix-fdatasync-2-after-fallocate-2-operation.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c894aa97577e47d3066b27b32499ecf899bfa8b0 Mon Sep 17 00:00:00 2001
From: Eryu Guan <eguan(a)redhat.com>
Date: Sun, 3 Dec 2017 22:52:51 -0500
Subject: ext4: fix fdatasync(2) after fallocate(2) operation
From: Eryu Guan <eguan(a)redhat.com>
commit c894aa97577e47d3066b27b32499ecf899bfa8b0 upstream.
Currently, fallocate(2) with KEEP_SIZE followed by a fdatasync(2)
then crash, we'll see wrong allocated block number (stat -c %b), the
blocks allocated beyond EOF are all lost. fstests generic/468
exposes this bug.
Commit 67a7d5f561f4 ("ext4: fix fdatasync(2) after extent
manipulation operations") fixed all the other extent manipulation
operation paths such as hole punch, zero range, collapse range etc.,
but forgot the fallocate case.
So similarly, fix it by recording the correct journal tid in ext4
inode in fallocate(2) path, so that ext4_sync_file() will wait for
the right tid to be committed on fdatasync(2).
This addresses the test failure in xfstests test generic/468.
Signed-off-by: Eryu Guan <eguan(a)redhat.com>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ext4/extents.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4722,6 +4722,7 @@ retry:
EXT4_INODE_EOFBLOCKS);
}
ext4_mark_inode_dirty(handle, inode);
+ ext4_update_inode_fsync_trans(handle, inode, 1);
ret2 = ext4_journal_stop(handle);
if (ret2)
break;
Patches currently in stable-queue which might be from eguan(a)redhat.com are
queue-4.14/ext4-fix-fdatasync-2-after-fallocate-2-operation.patch
This is a note to let you know that I've just added the patch titled
ext4: fix crash when a directory's i_size is too small
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ext4-fix-crash-when-a-directory-s-i_size-is-too-small.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9d5afec6b8bd46d6ed821aa1579634437f58ef1f Mon Sep 17 00:00:00 2001
From: Chandan Rajendra <chandan(a)linux.vnet.ibm.com>
Date: Mon, 11 Dec 2017 15:00:57 -0500
Subject: ext4: fix crash when a directory's i_size is too small
From: Chandan Rajendra <chandan(a)linux.vnet.ibm.com>
commit 9d5afec6b8bd46d6ed821aa1579634437f58ef1f upstream.
On a ppc64 machine, when mounting a fuzzed ext2 image (generated by
fsfuzzer) the following call trace is seen,
VFS: brelse: Trying to free free buffer
WARNING: CPU: 1 PID: 6913 at /root/repos/linux/fs/buffer.c:1165 .__brelse.part.6+0x24/0x40
.__brelse.part.6+0x20/0x40 (unreliable)
.ext4_find_entry+0x384/0x4f0
.ext4_lookup+0x84/0x250
.lookup_slow+0xdc/0x230
.walk_component+0x268/0x400
.path_lookupat+0xec/0x2d0
.filename_lookup+0x9c/0x1d0
.vfs_statx+0x98/0x140
.SyS_newfstatat+0x48/0x80
system_call+0x58/0x6c
This happens because the directory that ext4_find_entry() looks up has
inode->i_size that is less than the block size of the filesystem. This
causes 'nblocks' to have a value of zero. ext4_bread_batch() ends up not
reading any of the directory file's blocks. This renders the entries in
bh_use[] array to continue to have garbage data. buffer_uptodate() on
bh_use[0] can then return a zero value upon which brelse() function is
invoked.
This commit fixes the bug by returning -ENOENT when the directory file
has no associated blocks.
Reported-by: Abdul Haleem <abdhalee(a)linux.vnet.ibm.com>
Signed-off-by: Chandan Rajendra <chandan(a)linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ext4/namei.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1399,6 +1399,10 @@ static struct buffer_head * ext4_find_en
"falling back\n"));
}
nblocks = dir->i_size >> EXT4_BLOCK_SIZE_BITS(sb);
+ if (!nblocks) {
+ ret = NULL;
+ goto cleanup_and_exit;
+ }
start = EXT4_I(dir)->i_dir_start_lookup;
if (start >= nblocks)
start = 0;
Patches currently in stable-queue which might be from chandan(a)linux.vnet.ibm.com are
queue-4.14/ext4-fix-crash-when-a-directory-s-i_size-is-too-small.patch
This is a note to let you know that I've just added the patch titled
ext4: add missing error check in __ext4_new_inode()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ext4-add-missing-error-check-in-__ext4_new_inode.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 996fc4477a0ea28226b30d175f053fb6f9a4fa36 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso(a)mit.edu>
Date: Sun, 10 Dec 2017 23:44:11 -0500
Subject: ext4: add missing error check in __ext4_new_inode()
From: Theodore Ts'o <tytso(a)mit.edu>
commit 996fc4477a0ea28226b30d175f053fb6f9a4fa36 upstream.
It's possible for ext4_get_acl() to return an ERR_PTR. So we need to
add a check for this case in __ext4_new_inode(). Otherwise on an
error we can end up oops the kernel.
This was getting triggered by xfstests generic/388, which is a test
which exercises the shutdown code path.
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ext4/ialloc.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -816,6 +816,8 @@ struct inode *__ext4_new_inode(handle_t
#ifdef CONFIG_EXT4_FS_POSIX_ACL
struct posix_acl *p = get_acl(dir, ACL_TYPE_DEFAULT);
+ if (IS_ERR(p))
+ return ERR_CAST(p);
if (p) {
int acl_size = p->a_count * sizeof(ext4_acl_entry);
Patches currently in stable-queue which might be from tytso(a)mit.edu are
queue-4.14/ext4-add-missing-error-check-in-__ext4_new_inode.patch
queue-4.14/ext4-fix-fdatasync-2-after-fallocate-2-operation.patch
queue-4.14/ext4-support-fast-symlinks-from-ext3-file-systems.patch
This is a note to let you know that I've just added the patch titled
eeprom: at24: change nvmem stride to 1
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
eeprom-at24-change-nvmem-stride-to-1.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7f6d2ecd3d7acaf205ea7b3e96f9ffc55b92298b Mon Sep 17 00:00:00 2001
From: David Lechner <david(a)lechnology.com>
Date: Sun, 3 Dec 2017 19:54:41 -0600
Subject: eeprom: at24: change nvmem stride to 1
From: David Lechner <david(a)lechnology.com>
commit 7f6d2ecd3d7acaf205ea7b3e96f9ffc55b92298b upstream.
Trying to read the MAC address from an eeprom that has an offset that
is not a multiple of 4 causes an error currently.
Fix it by changing the nvmem stride to 1.
Signed-off-by: David Lechner <david(a)lechnology.com>
[Bartosz: tweaked the commit message]
Signed-off-by: Bartosz Golaszewski <brgl(a)bgdev.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/eeprom/at24.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -776,7 +776,7 @@ static int at24_probe(struct i2c_client
at24->nvmem_config.reg_read = at24_read;
at24->nvmem_config.reg_write = at24_write;
at24->nvmem_config.priv = at24;
- at24->nvmem_config.stride = 4;
+ at24->nvmem_config.stride = 1;
at24->nvmem_config.word_size = 1;
at24->nvmem_config.size = chip.byte_len;
Patches currently in stable-queue which might be from david(a)lechnology.com are
queue-4.14/eeprom-at24-change-nvmem-stride-to-1.patch
This is a note to let you know that I've just added the patch titled
dmaengine: dmatest: move callback wait queue to thread context
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-dmatest-move-callback-wait-queue-to-thread-context.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6f6a23a213be51728502b88741ba6a10cda2441d Mon Sep 17 00:00:00 2001
From: Adam Wallis <awallis(a)codeaurora.org>
Date: Mon, 27 Nov 2017 10:45:01 -0500
Subject: dmaengine: dmatest: move callback wait queue to thread context
From: Adam Wallis <awallis(a)codeaurora.org>
commit 6f6a23a213be51728502b88741ba6a10cda2441d upstream.
Commit adfa543e7314 ("dmatest: don't use set_freezable_with_signal()")
introduced a bug (that is in fact documented by the patch commit text)
that leaves behind a dangling pointer. Since the done_wait structure is
allocated on the stack, future invocations to the DMATEST can produce
undesirable results (e.g., corrupted spinlocks).
Commit a9df21e34b42 ("dmaengine: dmatest: warn user when dma test times
out") attempted to WARN the user that the stack was likely corrupted but
did not fix the actual issue.
This patch fixes the issue by pushing the wait queue and callback
structs into the the thread structure. If a failure occurs due to time,
dmaengine_terminate_all will force the callback to safely call
wake_up_all() without possibility of using a freed pointer.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=197605
Fixes: adfa543e7314 ("dmatest: don't use set_freezable_with_signal()")
Reviewed-by: Sinan Kaya <okaya(a)codeaurora.org>
Suggested-by: Shunyong Yang <shunyong.yang(a)hxt-semitech.com>
Signed-off-by: Adam Wallis <awallis(a)codeaurora.org>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/dmatest.c | 55 ++++++++++++++++++++++++++++----------------------
1 file changed, 31 insertions(+), 24 deletions(-)
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -155,6 +155,12 @@ MODULE_PARM_DESC(run, "Run the test (def
#define PATTERN_COUNT_MASK 0x1f
#define PATTERN_MEMSET_IDX 0x01
+/* poor man's completion - we want to use wait_event_freezable() on it */
+struct dmatest_done {
+ bool done;
+ wait_queue_head_t *wait;
+};
+
struct dmatest_thread {
struct list_head node;
struct dmatest_info *info;
@@ -165,6 +171,8 @@ struct dmatest_thread {
u8 **dsts;
u8 **udsts;
enum dma_transaction_type type;
+ wait_queue_head_t done_wait;
+ struct dmatest_done test_done;
bool done;
};
@@ -342,18 +350,25 @@ static unsigned int dmatest_verify(u8 **
return error_count;
}
-/* poor man's completion - we want to use wait_event_freezable() on it */
-struct dmatest_done {
- bool done;
- wait_queue_head_t *wait;
-};
static void dmatest_callback(void *arg)
{
struct dmatest_done *done = arg;
-
- done->done = true;
- wake_up_all(done->wait);
+ struct dmatest_thread *thread =
+ container_of(arg, struct dmatest_thread, done_wait);
+ if (!thread->done) {
+ done->done = true;
+ wake_up_all(done->wait);
+ } else {
+ /*
+ * If thread->done, it means that this callback occurred
+ * after the parent thread has cleaned up. This can
+ * happen in the case that driver doesn't implement
+ * the terminate_all() functionality and a dma operation
+ * did not occur within the timeout period
+ */
+ WARN(1, "dmatest: Kernel memory may be corrupted!!\n");
+ }
}
static unsigned int min_odd(unsigned int x, unsigned int y)
@@ -424,9 +439,8 @@ static unsigned long long dmatest_KBs(s6
*/
static int dmatest_func(void *data)
{
- DECLARE_WAIT_QUEUE_HEAD_ONSTACK(done_wait);
struct dmatest_thread *thread = data;
- struct dmatest_done done = { .wait = &done_wait };
+ struct dmatest_done *done = &thread->test_done;
struct dmatest_info *info;
struct dmatest_params *params;
struct dma_chan *chan;
@@ -673,9 +687,9 @@ static int dmatest_func(void *data)
continue;
}
- done.done = false;
+ done->done = false;
tx->callback = dmatest_callback;
- tx->callback_param = &done;
+ tx->callback_param = done;
cookie = tx->tx_submit(tx);
if (dma_submit_error(cookie)) {
@@ -688,21 +702,12 @@ static int dmatest_func(void *data)
}
dma_async_issue_pending(chan);
- wait_event_freezable_timeout(done_wait, done.done,
+ wait_event_freezable_timeout(thread->done_wait, done->done,
msecs_to_jiffies(params->timeout));
status = dma_async_is_tx_complete(chan, cookie, NULL, NULL);
- if (!done.done) {
- /*
- * We're leaving the timed out dma operation with
- * dangling pointer to done_wait. To make this
- * correct, we'll need to allocate wait_done for
- * each test iteration and perform "who's gonna
- * free it this time?" dancing. For now, just
- * leave it dangling.
- */
- WARN(1, "dmatest: Kernel stack may be corrupted!!\n");
+ if (!done->done) {
dmaengine_unmap_put(um);
result("test timed out", total_tests, src_off, dst_off,
len, 0);
@@ -789,7 +794,7 @@ err_thread_type:
dmatest_KBs(runtime, total_len), ret);
/* terminate all transfers on specified channels */
- if (ret)
+ if (ret || failed_tests)
dmaengine_terminate_all(chan);
thread->done = true;
@@ -849,6 +854,8 @@ static int dmatest_add_threads(struct dm
thread->info = info;
thread->chan = dtc->chan;
thread->type = type;
+ thread->test_done.wait = &thread->done_wait;
+ init_waitqueue_head(&thread->done_wait);
smp_wmb();
thread->task = kthread_create(dmatest_func, thread, "%s-%s%u",
dma_chan_name(chan), op, i);
Patches currently in stable-queue which might be from awallis(a)codeaurora.org are
queue-4.14/dmaengine-dmatest-move-callback-wait-queue-to-thread-context.patch
This is a note to let you know that I've just added the patch titled
ceph: drop negative child dentries before try pruning inode's alias
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ceph-drop-negative-child-dentries-before-try-pruning-inode-s-alias.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 040d786032bf59002d374b86d75b04d97624005c Mon Sep 17 00:00:00 2001
From: "Yan, Zheng" <zyan(a)redhat.com>
Date: Thu, 30 Nov 2017 11:59:22 +0800
Subject: ceph: drop negative child dentries before try pruning inode's alias
From: Yan, Zheng <zyan(a)redhat.com>
commit 040d786032bf59002d374b86d75b04d97624005c upstream.
Negative child dentry holds reference on inode's alias, it makes
d_prune_aliases() do nothing.
Signed-off-by: "Yan, Zheng" <zyan(a)redhat.com>
Reviewed-by: Jeff Layton <jlayton(a)redhat.com>
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ceph/mds_client.c | 42 ++++++++++++++++++++++++++++++++++++++----
1 file changed, 38 insertions(+), 4 deletions(-)
--- a/fs/ceph/mds_client.c
+++ b/fs/ceph/mds_client.c
@@ -1428,6 +1428,29 @@ static int __close_session(struct ceph_m
return request_close_session(mdsc, session);
}
+static bool drop_negative_children(struct dentry *dentry)
+{
+ struct dentry *child;
+ bool all_negative = true;
+
+ if (!d_is_dir(dentry))
+ goto out;
+
+ spin_lock(&dentry->d_lock);
+ list_for_each_entry(child, &dentry->d_subdirs, d_child) {
+ if (d_really_is_positive(child)) {
+ all_negative = false;
+ break;
+ }
+ }
+ spin_unlock(&dentry->d_lock);
+
+ if (all_negative)
+ shrink_dcache_parent(dentry);
+out:
+ return all_negative;
+}
+
/*
* Trim old(er) caps.
*
@@ -1473,16 +1496,27 @@ static int trim_caps_cb(struct inode *in
if ((used | wanted) & ~oissued & mine)
goto out; /* we need these caps */
- session->s_trim_caps--;
if (oissued) {
/* we aren't the only cap.. just remove us */
__ceph_remove_cap(cap, true);
+ session->s_trim_caps--;
} else {
+ struct dentry *dentry;
/* try dropping referring dentries */
spin_unlock(&ci->i_ceph_lock);
- d_prune_aliases(inode);
- dout("trim_caps_cb %p cap %p pruned, count now %d\n",
- inode, cap, atomic_read(&inode->i_count));
+ dentry = d_find_any_alias(inode);
+ if (dentry && drop_negative_children(dentry)) {
+ int count;
+ dput(dentry);
+ d_prune_aliases(inode);
+ count = atomic_read(&inode->i_count);
+ if (count == 1)
+ session->s_trim_caps--;
+ dout("trim_caps_cb %p cap %p pruned, count now %d\n",
+ inode, cap, count);
+ } else {
+ dput(dentry);
+ }
return 0;
}
Patches currently in stable-queue which might be from zyan(a)redhat.com are
queue-4.14/ceph-drop-negative-child-dentries-before-try-pruning-inode-s-alias.patch
This is a note to let you know that I've just added the patch titled
autofs: fix careless error in recent commit
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
autofs-fix-careless-error-in-recent-commit.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 302ec300ef8a545a7fc7f667e5fd743b091c2eeb Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb(a)suse.com>
Date: Thu, 14 Dec 2017 15:32:38 -0800
Subject: autofs: fix careless error in recent commit
From: NeilBrown <neilb(a)suse.com>
commit 302ec300ef8a545a7fc7f667e5fd743b091c2eeb upstream.
Commit ecc0c469f277 ("autofs: don't fail mount for transient error") was
meant to replace an 'if' with a 'switch', but instead added the 'switch'
leaving the case in place.
Link: http://lkml.kernel.org/r/87zi6wstmw.fsf@notabene.neil.brown.name
Fixes: ecc0c469f277 ("autofs: don't fail mount for transient error")
Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: NeilBrown <neilb(a)suse.com>
Cc: Ian Kent <raven(a)themaw.net>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/autofs4/waitq.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/autofs4/waitq.c
+++ b/fs/autofs4/waitq.c
@@ -170,7 +170,6 @@ static void autofs4_notify_daemon(struct
mutex_unlock(&sbi->wq_mutex);
- if (autofs4_write(sbi, pipe, &pkt, pktsz))
switch (ret = autofs4_write(sbi, pipe, &pkt, pktsz)) {
case 0:
break;
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-4.14/autofs-fix-careless-error-in-recent-commit.patch
queue-4.14/kernel-make-groups_sort-calling-a-responsibility-group_info-allocators.patch
This is a note to let you know that I've just added the patch titled
arm64: mm: Fix pte_mkclean, pte_mkdirty semantics
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-mm-fix-pte_mkclean-pte_mkdirty-semantics.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 8781bcbc5e69d7da69e84c7044ca0284848d5d01 Mon Sep 17 00:00:00 2001
From: Steve Capper <steve.capper(a)arm.com>
Date: Fri, 1 Dec 2017 17:22:14 +0000
Subject: arm64: mm: Fix pte_mkclean, pte_mkdirty semantics
From: Steve Capper <steve.capper(a)arm.com>
commit 8781bcbc5e69d7da69e84c7044ca0284848d5d01 upstream.
On systems with hardware dirty bit management, the ltp madvise09 unit
test fails due to dirty bit information being lost and pages being
incorrectly freed.
This was bisected to:
arm64: Ignore hardware dirty bit updates in ptep_set_wrprotect()
Reverting this commit leads to a separate problem, that the unit test
retains pages that should have been dropped due to the function
madvise_free_pte_range(.) not cleaning pte's properly.
Currently pte_mkclean only clears the software dirty bit, thus the
following code sequence can appear:
pte = pte_mkclean(pte);
if (pte_dirty(pte))
// this condition can return true with HW DBM!
This patch also adjusts pte_mkclean to set PTE_RDONLY thus effectively
clearing both the SW and HW dirty information.
In order for this to function on systems without HW DBM, we need to
also adjust pte_mkdirty to remove the read only bit from writable pte's
to avoid infinite fault loops.
Fixes: 64c26841b349 ("arm64: Ignore hardware dirty bit updates in ptep_set_wrprotect()")
Reported-by: Bhupinder Thakur <bhupinder.thakur(a)linaro.org>
Tested-by: Bhupinder Thakur <bhupinder.thakur(a)linaro.org>
Reviewed-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Steve Capper <steve.capper(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/pgtable.h | 33 ++++++++++++++++++---------------
1 file changed, 18 insertions(+), 15 deletions(-)
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -149,12 +149,20 @@ static inline pte_t pte_mkwrite(pte_t pt
static inline pte_t pte_mkclean(pte_t pte)
{
- return clear_pte_bit(pte, __pgprot(PTE_DIRTY));
+ pte = clear_pte_bit(pte, __pgprot(PTE_DIRTY));
+ pte = set_pte_bit(pte, __pgprot(PTE_RDONLY));
+
+ return pte;
}
static inline pte_t pte_mkdirty(pte_t pte)
{
- return set_pte_bit(pte, __pgprot(PTE_DIRTY));
+ pte = set_pte_bit(pte, __pgprot(PTE_DIRTY));
+
+ if (pte_write(pte))
+ pte = clear_pte_bit(pte, __pgprot(PTE_RDONLY));
+
+ return pte;
}
static inline pte_t pte_mkold(pte_t pte)
@@ -642,28 +650,23 @@ static inline pmd_t pmdp_huge_get_and_cl
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
/*
- * ptep_set_wrprotect - mark read-only while preserving the hardware update of
- * the Access Flag.
+ * ptep_set_wrprotect - mark read-only while trasferring potential hardware
+ * dirty status (PTE_DBM && !PTE_RDONLY) to the software PTE_DIRTY bit.
*/
#define __HAVE_ARCH_PTEP_SET_WRPROTECT
static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long address, pte_t *ptep)
{
pte_t old_pte, pte;
- /*
- * ptep_set_wrprotect() is only called on CoW mappings which are
- * private (!VM_SHARED) with the pte either read-only (!PTE_WRITE &&
- * PTE_RDONLY) or writable and software-dirty (PTE_WRITE &&
- * !PTE_RDONLY && PTE_DIRTY); see is_cow_mapping() and
- * protection_map[]. There is no race with the hardware update of the
- * dirty state: clearing of PTE_RDONLY when PTE_WRITE (a.k.a. PTE_DBM)
- * is set.
- */
- VM_WARN_ONCE(pte_write(*ptep) && !pte_dirty(*ptep),
- "%s: potential race with hardware DBM", __func__);
pte = READ_ONCE(*ptep);
do {
old_pte = pte;
+ /*
+ * If hardware-dirty (PTE_WRITE/DBM bit set and PTE_RDONLY
+ * clear), set the PTE_DIRTY bit.
+ */
+ if (pte_hw_dirty(pte))
+ pte = pte_mkdirty(pte);
pte = pte_wrprotect(pte);
pte_val(pte) = cmpxchg_relaxed(&pte_val(*ptep),
pte_val(old_pte), pte_val(pte));
Patches currently in stable-queue which might be from steve.capper(a)arm.com are
queue-4.14/arm64-initialise-high_memory-global-variable-earlier.patch
queue-4.14/arm64-mm-fix-pte_mkclean-pte_mkdirty-semantics.patch
This is a note to let you know that I've just added the patch titled
arm64: Initialise high_memory global variable earlier
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-initialise-high_memory-global-variable-earlier.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f24e5834a2c3f6c5f814a417f858226f0a010ade Mon Sep 17 00:00:00 2001
From: Steve Capper <steve.capper(a)arm.com>
Date: Mon, 4 Dec 2017 14:13:05 +0000
Subject: arm64: Initialise high_memory global variable earlier
From: Steve Capper <steve.capper(a)arm.com>
commit f24e5834a2c3f6c5f814a417f858226f0a010ade upstream.
The high_memory global variable is used by
cma_declare_contiguous(.) before it is defined.
We don't notice this as we compute __pa(high_memory - 1), and it looks
like we're processing a VA from the direct linear map.
This problem becomes apparent when we flip the kernel virtual address
space and the linear map is moved to the bottom of the kernel VA space.
This patch moves the initialisation of high_memory before it used.
Fixes: f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory boundary")
Signed-off-by: Steve Capper <steve.capper(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/mm/init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -476,6 +476,8 @@ void __init arm64_memblock_init(void)
reserve_elfcorehdr();
+ high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
+
dma_contiguous_reserve(arm64_dma_phys_limit);
memblock_allow_resize();
@@ -502,7 +504,6 @@ void __init bootmem_init(void)
sparse_init();
zone_sizes_init(min, max);
- high_memory = __va((max << PAGE_SHIFT) - 1) + 1;
memblock_dump_all();
}
Patches currently in stable-queue which might be from steve.capper(a)arm.com are
queue-4.14/arm64-initialise-high_memory-global-variable-earlier.patch
queue-4.14/arm64-mm-fix-pte_mkclean-pte_mkdirty-semantics.patch
This is a note to let you know that I've just added the patch titled
arm64: fix CONFIG_DEBUG_WX address reporting
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-fix-config_debug_wx-address-reporting.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 1d08a044cf12aee37dfd54837558e3295287b343 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland(a)arm.com>
Date: Wed, 13 Dec 2017 11:45:42 +0000
Subject: arm64: fix CONFIG_DEBUG_WX address reporting
From: Mark Rutland <mark.rutland(a)arm.com>
commit 1d08a044cf12aee37dfd54837558e3295287b343 upstream.
In ptdump_check_wx(), we pass walk_pgd() a start address of 0 (rather
than VA_START) for the init_mm. This means that any reported W&X
addresses are offset by VA_START, which is clearly wrong and can make
them appear like userspace addresses.
Fix this by telling the ptdump code that we're walking init_mm starting
at VA_START. We don't need to update the addr_markers, since these are
still valid bounds regardless.
Fixes: 1404d6f13e47 ("arm64: dump: Add checking for writable and exectuable pages")
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Laura Abbott <labbott(a)redhat.com>
Reported-by: Timur Tabi <timur(a)codeaurora.org>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/mm/dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -389,7 +389,7 @@ void ptdump_check_wx(void)
.check_wx = true,
};
- walk_pgd(&st, &init_mm, 0);
+ walk_pgd(&st, &init_mm, VA_START);
note_page(&st, 0, 0, 0);
if (st.wx_pages || st.uxn_pages)
pr_warn("Checked W+X mappings: FAILED, %lu W+X pages found, %lu non-UXN pages found\n",
Patches currently in stable-queue which might be from mark.rutland(a)arm.com are
queue-4.14/arm64-fix-config_debug_wx-address-reporting.patch
This is a note to let you know that I've just added the patch titled
usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-fix-stub_send_ret_submit-vulnerability-to-null-transfer_buffer.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From be6123df1ea8f01ee2f896a16c2b7be3e4557a5a Mon Sep 17 00:00:00 2001
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Thu, 7 Dec 2017 14:16:50 -0700
Subject: usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer
From: Shuah Khan <shuahkh(a)osg.samsung.com>
commit be6123df1ea8f01ee2f896a16c2b7be3e4557a5a upstream.
stub_send_ret_submit() handles urb with a potential null transfer_buffer,
when it replays a packet with potential malicious data that could contain
a null buffer. Add a check for the condition when actual_length > 0 and
transfer_buffer is null.
Reported-by: Secunia Research <vuln(a)secunia.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/stub_tx.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/usb/usbip/stub_tx.c
+++ b/drivers/usb/usbip/stub_tx.c
@@ -178,6 +178,13 @@ static int stub_send_ret_submit(struct s
memset(&pdu_header, 0, sizeof(pdu_header));
memset(&msg, 0, sizeof(msg));
+ if (urb->actual_length > 0 && !urb->transfer_buffer) {
+ dev_err(&sdev->udev->dev,
+ "urb: actual_length %d transfer_buffer null\n",
+ urb->actual_length);
+ return -1;
+ }
+
if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS)
iovnum = 2 + urb->number_of_packets;
else
Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are
queue-3.18/usbip-fix-stub_send_ret_submit-vulnerability-to-null-transfer_buffer.patch
This is a note to let you know that I've just added the patch titled
xhci: Don't add a virt_dev to the devs array before it's fully allocated
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xhci-don-t-add-a-virt_dev-to-the-devs-array-before-it-s-fully-allocated.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5d9b70f7d52eb14bb37861c663bae44de9521c35 Mon Sep 17 00:00:00 2001
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Date: Fri, 8 Dec 2017 18:10:05 +0200
Subject: xhci: Don't add a virt_dev to the devs array before it's fully allocated
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
commit 5d9b70f7d52eb14bb37861c663bae44de9521c35 upstream.
Avoid null pointer dereference if some function is walking through the
devs array accessing members of a new virt_dev that is mid allocation.
Add the virt_dev to xhci->devs[i] _after_ the virt_device and all its
members are properly allocated.
issue found by KASAN: null-ptr-deref in xhci_find_slot_id_by_port
"Quick analysis suggests that xhci_alloc_virt_device() is not mutex
protected. If so, there is a time frame where xhci->devs[slot_id] is set
but not fully initialized. Specifically, xhci->devs[i]->udev can be NULL."
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/host/xhci-mem.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -978,10 +978,9 @@ int xhci_alloc_virt_device(struct xhci_h
return 0;
}
- xhci->devs[slot_id] = kzalloc(sizeof(*xhci->devs[slot_id]), flags);
- if (!xhci->devs[slot_id])
+ dev = kzalloc(sizeof(*dev), flags);
+ if (!dev)
return 0;
- dev = xhci->devs[slot_id];
/* Allocate the (output) device context that will be used in the HC. */
dev->out_ctx = xhci_alloc_container_ctx(xhci, XHCI_CTX_TYPE_DEVICE, flags);
@@ -1029,9 +1028,17 @@ int xhci_alloc_virt_device(struct xhci_h
&xhci->dcbaa->dev_context_ptrs[slot_id],
le64_to_cpu(xhci->dcbaa->dev_context_ptrs[slot_id]));
+ xhci->devs[slot_id] = dev;
+
return 1;
fail:
- xhci_free_virt_device(xhci, slot_id);
+
+ if (dev->in_ctx)
+ xhci_free_container_ctx(xhci, dev->in_ctx);
+ if (dev->out_ctx)
+ xhci_free_container_ctx(xhci, dev->out_ctx);
+ kfree(dev);
+
return 0;
}
Patches currently in stable-queue which might be from mathias.nyman(a)linux.intel.com are
queue-3.18/xhci-don-t-add-a-virt_dev-to-the-devs-array-before-it-s-fully-allocated.patch
This is a note to let you know that I've just added the patch titled
USB: core: prevent malicious bNumInterfaces overflow
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-core-prevent-malicious-bnuminterfaces-overflow.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 48a4ff1c7bb5a32d2e396b03132d20d552c0eca7 Mon Sep 17 00:00:00 2001
From: Alan Stern <stern(a)rowland.harvard.edu>
Date: Tue, 12 Dec 2017 14:25:13 -0500
Subject: USB: core: prevent malicious bNumInterfaces overflow
From: Alan Stern <stern(a)rowland.harvard.edu>
commit 48a4ff1c7bb5a32d2e396b03132d20d552c0eca7 upstream.
A malicious USB device with crafted descriptors can cause the kernel
to access unallocated memory by setting the bNumInterfaces value too
high in a configuration descriptor. Although the value is adjusted
during parsing, this adjustment is skipped in one of the error return
paths.
This patch prevents the problem by setting bNumInterfaces to 0
initially. The existing code already sets it to the proper value
after parsing is complete.
Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/config.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -450,6 +450,9 @@ static int usb_parse_configuration(struc
unsigned iad_num = 0;
memcpy(&config->desc, buffer, USB_DT_CONFIG_SIZE);
+ nintf = nintf_orig = config->desc.bNumInterfaces;
+ config->desc.bNumInterfaces = 0; // Adjusted later
+
if (config->desc.bDescriptorType != USB_DT_CONFIG ||
config->desc.bLength < USB_DT_CONFIG_SIZE ||
config->desc.bLength > size) {
@@ -463,7 +466,6 @@ static int usb_parse_configuration(struc
buffer += config->desc.bLength;
size -= config->desc.bLength;
- nintf = nintf_orig = config->desc.bNumInterfaces;
if (nintf > USB_MAXINTERFACES) {
dev_warn(ddev, "config %d has too many interfaces: %d, "
"using maximum allowed: %d\n",
Patches currently in stable-queue which might be from stern(a)rowland.harvard.edu are
queue-3.18/usb-core-prevent-malicious-bnuminterfaces-overflow.patch
queue-3.18/usb-uas-and-storage-add-us_fl_broken_fua-for-another-jmicron-jms567-id.patch
This is a note to let you know that I've just added the patch titled
USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-uas-and-storage-add-us_fl_broken_fua-for-another-jmicron-jms567-id.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 62354454625741f0569c2cbe45b2d192f8fd258e Mon Sep 17 00:00:00 2001
From: David Kozub <zub(a)linux.fjfi.cvut.cz>
Date: Tue, 5 Dec 2017 22:40:04 +0100
Subject: USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID
From: David Kozub <zub(a)linux.fjfi.cvut.cz>
commit 62354454625741f0569c2cbe45b2d192f8fd258e upstream.
There is another JMS567-based USB3 UAS enclosure (152d:0578) that fails
with the following error:
[sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[sda] tag#0 Sense Key : Illegal Request [current]
[sda] tag#0 Add. Sense: Invalid field in cdb
The issue occurs both with UAS (occasionally) and mass storage
(immediately after mounting a FS on a disk in the enclosure).
Enabling US_FL_BROKEN_FUA quirk solves this issue.
This patch adds an UNUSUAL_DEV with US_FL_BROKEN_FUA for the enclosure
for both UAS and mass storage.
Signed-off-by: David Kozub <zub(a)linux.fjfi.cvut.cz>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/unusual_devs.h | 7 +++++++
drivers/usb/storage/unusual_uas.h | 7 +++++++
2 files changed, 14 insertions(+)
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2131,6 +2131,13 @@ UNUSUAL_DEV( 0x22b8, 0x3010, 0x0001, 0x
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY | US_FL_IGNORE_RESIDUE ),
+/* Reported by David Kozub <zub(a)linux.fjfi.cvut.cz> */
+UNUSUAL_DEV(0x152d, 0x0578, 0x0000, 0x9999,
+ "JMicron",
+ "JMS567",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BROKEN_FUA),
+
/*
* Patch by Constantin Baranov <const(a)tltsu.ru>
* Report by Andreas Koenecke.
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -139,6 +139,13 @@ UNUSUAL_DEV(0x174c, 0x5106, 0x0000, 0x99
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_IGNORE_UAS),
+/* Reported-by: David Kozub <zub(a)linux.fjfi.cvut.cz> */
+UNUSUAL_DEV(0x152d, 0x0578, 0x0000, 0x9999,
+ "JMicron",
+ "JMS567",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BROKEN_FUA),
+
/* Reported-by: Hans de Goede <hdegoede(a)redhat.com> */
UNUSUAL_DEV(0x2109, 0x0711, 0x0000, 0x9999,
"VIA",
Patches currently in stable-queue which might be from zub(a)linux.fjfi.cvut.cz are
queue-3.18/usb-uas-and-storage-add-us_fl_broken_fua-for-another-jmicron-jms567-id.patch
This is a note to let you know that I've just added the patch titled
ext4: fix crash when a directory's i_size is too small
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ext4-fix-crash-when-a-directory-s-i_size-is-too-small.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9d5afec6b8bd46d6ed821aa1579634437f58ef1f Mon Sep 17 00:00:00 2001
From: Chandan Rajendra <chandan(a)linux.vnet.ibm.com>
Date: Mon, 11 Dec 2017 15:00:57 -0500
Subject: ext4: fix crash when a directory's i_size is too small
From: Chandan Rajendra <chandan(a)linux.vnet.ibm.com>
commit 9d5afec6b8bd46d6ed821aa1579634437f58ef1f upstream.
On a ppc64 machine, when mounting a fuzzed ext2 image (generated by
fsfuzzer) the following call trace is seen,
VFS: brelse: Trying to free free buffer
WARNING: CPU: 1 PID: 6913 at /root/repos/linux/fs/buffer.c:1165 .__brelse.part.6+0x24/0x40
.__brelse.part.6+0x20/0x40 (unreliable)
.ext4_find_entry+0x384/0x4f0
.ext4_lookup+0x84/0x250
.lookup_slow+0xdc/0x230
.walk_component+0x268/0x400
.path_lookupat+0xec/0x2d0
.filename_lookup+0x9c/0x1d0
.vfs_statx+0x98/0x140
.SyS_newfstatat+0x48/0x80
system_call+0x58/0x6c
This happens because the directory that ext4_find_entry() looks up has
inode->i_size that is less than the block size of the filesystem. This
causes 'nblocks' to have a value of zero. ext4_bread_batch() ends up not
reading any of the directory file's blocks. This renders the entries in
bh_use[] array to continue to have garbage data. buffer_uptodate() on
bh_use[0] can then return a zero value upon which brelse() function is
invoked.
This commit fixes the bug by returning -ENOENT when the directory file
has no associated blocks.
Reported-by: Abdul Haleem <abdhalee(a)linux.vnet.ibm.com>
Signed-off-by: Chandan Rajendra <chandan(a)linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ext4/namei.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1244,6 +1244,10 @@ static struct buffer_head * ext4_find_en
"falling back\n"));
}
nblocks = dir->i_size >> EXT4_BLOCK_SIZE_BITS(sb);
+ if (!nblocks) {
+ ret = NULL;
+ goto cleanup_and_exit;
+ }
start = EXT4_I(dir)->i_dir_start_lookup;
if (start >= nblocks)
start = 0;
Patches currently in stable-queue which might be from chandan(a)linux.vnet.ibm.com are
queue-3.18/ext4-fix-crash-when-a-directory-s-i_size-is-too-small.patch
This is a note to let you know that I've just added the patch titled
autofs: fix careless error in recent commit
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
autofs-fix-careless-error-in-recent-commit.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 302ec300ef8a545a7fc7f667e5fd743b091c2eeb Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb(a)suse.com>
Date: Thu, 14 Dec 2017 15:32:38 -0800
Subject: autofs: fix careless error in recent commit
From: NeilBrown <neilb(a)suse.com>
commit 302ec300ef8a545a7fc7f667e5fd743b091c2eeb upstream.
Commit ecc0c469f277 ("autofs: don't fail mount for transient error") was
meant to replace an 'if' with a 'switch', but instead added the 'switch'
leaving the case in place.
Link: http://lkml.kernel.org/r/87zi6wstmw.fsf@notabene.neil.brown.name
Fixes: ecc0c469f277 ("autofs: don't fail mount for transient error")
Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: NeilBrown <neilb(a)suse.com>
Cc: Ian Kent <raven(a)themaw.net>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/autofs4/waitq.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/autofs4/waitq.c
+++ b/fs/autofs4/waitq.c
@@ -174,7 +174,6 @@ static void autofs4_notify_daemon(struct
mutex_unlock(&sbi->wq_mutex);
- if (autofs4_write(sbi, pipe, &pkt, pktsz))
switch (ret = autofs4_write(sbi, pipe, &pkt, pktsz)) {
case 0:
break;
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-3.18/autofs-fix-careless-error-in-recent-commit.patch
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 996fc4477a0ea28226b30d175f053fb6f9a4fa36 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso(a)mit.edu>
Date: Sun, 10 Dec 2017 23:44:11 -0500
Subject: [PATCH] ext4: add missing error check in __ext4_new_inode()
It's possible for ext4_get_acl() to return an ERR_PTR. So we need to
add a check for this case in __ext4_new_inode(). Otherwise on an
error we can end up oops the kernel.
This was getting triggered by xfstests generic/388, which is a test
which exercises the shutdown code path.
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)vger.kernel.org
diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index b4267d72f249..b32cf263750d 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -816,6 +816,8 @@ struct inode *__ext4_new_inode(handle_t *handle, struct inode *dir,
#ifdef CONFIG_EXT4_FS_POSIX_ACL
struct posix_acl *p = get_acl(dir, ACL_TYPE_DEFAULT);
+ if (IS_ERR(p))
+ return ERR_CAST(p);
if (p) {
int acl_size = p->a_count * sizeof(ext4_acl_entry);
The patch below does not apply to the 4.9-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 996fc4477a0ea28226b30d175f053fb6f9a4fa36 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso(a)mit.edu>
Date: Sun, 10 Dec 2017 23:44:11 -0500
Subject: [PATCH] ext4: add missing error check in __ext4_new_inode()
It's possible for ext4_get_acl() to return an ERR_PTR. So we need to
add a check for this case in __ext4_new_inode(). Otherwise on an
error we can end up oops the kernel.
This was getting triggered by xfstests generic/388, which is a test
which exercises the shutdown code path.
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Cc: stable(a)vger.kernel.org
diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index b4267d72f249..b32cf263750d 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -816,6 +816,8 @@ struct inode *__ext4_new_inode(handle_t *handle, struct inode *dir,
#ifdef CONFIG_EXT4_FS_POSIX_ACL
struct posix_acl *p = get_acl(dir, ACL_TYPE_DEFAULT);
+ if (IS_ERR(p))
+ return ERR_CAST(p);
if (p) {
int acl_size = p->a_count * sizeof(ext4_acl_entry);
The patch below does not apply to the 4.14-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 c1fd0abee0d52eb7e2871194b6c79d54792f515f Mon Sep 17 00:00:00 2001
From: Mike Snitzer <snitzer(a)redhat.com>
Date: Thu, 7 Dec 2017 22:42:27 -0500
Subject: [PATCH] dm mpath: fix bio-based multipath queue_if_no_path handling
Commit ca5beb76 ("dm mpath: micro-optimize the hot path relative to
MPATHF_QUEUE_IF_NO_PATH") caused bio-based DM-multipath to fail mptest's
"test_02_sdev_delete".
Restoring the logic that existed prior to commit ca5beb76 fixes this
bio-based DM-multipath regression. Also verified all mptest tests pass
with request-based DM-multipath.
This commit effectively reverts commit ca5beb76 -- but it does so
without reintroducing the need to take the m->lock spinlock in
must_push_back_{rq,bio}.
Fixes: ca5beb76 ("dm mpath: micro-optimize the hot path relative to MPATHF_QUEUE_IF_NO_PATH")
Cc: stable(a)vger.kernel.org # 4.12+
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
index 35a2a2fa477f..f7810cc869ac 100644
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -457,6 +457,38 @@ do { \
dm_noflush_suspending((m)->ti)); \
} while (0)
+/*
+ * Check whether bios must be queued in the device-mapper core rather
+ * than here in the target.
+ *
+ * If MPATHF_QUEUE_IF_NO_PATH and MPATHF_SAVED_QUEUE_IF_NO_PATH hold
+ * the same value then we are not between multipath_presuspend()
+ * and multipath_resume() calls and we have no need to check
+ * for the DMF_NOFLUSH_SUSPENDING flag.
+ */
+static bool __must_push_back(struct multipath *m, unsigned long flags)
+{
+ return ((test_bit(MPATHF_QUEUE_IF_NO_PATH, &flags) !=
+ test_bit(MPATHF_SAVED_QUEUE_IF_NO_PATH, &flags)) &&
+ dm_noflush_suspending(m->ti));
+}
+
+/*
+ * Following functions use READ_ONCE to get atomic access to
+ * all m->flags to avoid taking spinlock
+ */
+static bool must_push_back_rq(struct multipath *m)
+{
+ unsigned long flags = READ_ONCE(m->flags);
+ return test_bit(MPATHF_QUEUE_IF_NO_PATH, &flags) || __must_push_back(m, flags);
+}
+
+static bool must_push_back_bio(struct multipath *m)
+{
+ unsigned long flags = READ_ONCE(m->flags);
+ return __must_push_back(m, flags);
+}
+
/*
* Map cloned requests (request-based multipath)
*/
@@ -478,7 +510,7 @@ static int multipath_clone_and_map(struct dm_target *ti, struct request *rq,
pgpath = choose_pgpath(m, nr_bytes);
if (!pgpath) {
- if (test_bit(MPATHF_QUEUE_IF_NO_PATH, &m->flags))
+ if (must_push_back_rq(m))
return DM_MAPIO_DELAY_REQUEUE;
dm_report_EIO(m); /* Failed */
return DM_MAPIO_KILL;
@@ -553,7 +585,7 @@ static int __multipath_map_bio(struct multipath *m, struct bio *bio, struct dm_m
}
if (!pgpath) {
- if (test_bit(MPATHF_QUEUE_IF_NO_PATH, &m->flags))
+ if (must_push_back_bio(m))
return DM_MAPIO_REQUEUE;
dm_report_EIO(m);
return DM_MAPIO_KILL;
@@ -651,8 +683,7 @@ static int queue_if_no_path(struct multipath *m, bool queue_if_no_path,
assign_bit(MPATHF_SAVED_QUEUE_IF_NO_PATH, &m->flags,
(save_old_value && test_bit(MPATHF_QUEUE_IF_NO_PATH, &m->flags)) ||
(!save_old_value && queue_if_no_path));
- assign_bit(MPATHF_QUEUE_IF_NO_PATH, &m->flags,
- queue_if_no_path || dm_noflush_suspending(m->ti));
+ assign_bit(MPATHF_QUEUE_IF_NO_PATH, &m->flags, queue_if_no_path);
spin_unlock_irqrestore(&m->lock, flags);
if (!queue_if_no_path) {
@@ -1486,7 +1517,7 @@ static int multipath_end_io(struct dm_target *ti, struct request *clone,
fail_path(pgpath);
if (atomic_read(&m->nr_valid_paths) == 0 &&
- !test_bit(MPATHF_QUEUE_IF_NO_PATH, &m->flags)) {
+ !must_push_back_rq(m)) {
if (error == BLK_STS_IOERR)
dm_report_EIO(m);
/* complete with the original error */
@@ -1521,8 +1552,12 @@ static int multipath_end_io_bio(struct dm_target *ti, struct bio *clone,
if (atomic_read(&m->nr_valid_paths) == 0 &&
!test_bit(MPATHF_QUEUE_IF_NO_PATH, &m->flags)) {
- dm_report_EIO(m);
- *error = BLK_STS_IOERR;
+ if (must_push_back_bio(m)) {
+ r = DM_ENDIO_REQUEUE;
+ } else {
+ dm_report_EIO(m);
+ *error = BLK_STS_IOERR;
+ }
goto done;
}
The patch below does not apply to the 3.18-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 f24e5834a2c3f6c5f814a417f858226f0a010ade Mon Sep 17 00:00:00 2001
From: Steve Capper <steve.capper(a)arm.com>
Date: Mon, 4 Dec 2017 14:13:05 +0000
Subject: [PATCH] arm64: Initialise high_memory global variable earlier
The high_memory global variable is used by
cma_declare_contiguous(.) before it is defined.
We don't notice this as we compute __pa(high_memory - 1), and it looks
like we're processing a VA from the direct linear map.
This problem becomes apparent when we flip the kernel virtual address
space and the linear map is moved to the bottom of the kernel VA space.
This patch moves the initialisation of high_memory before it used.
Cc: <stable(a)vger.kernel.org>
Fixes: f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory boundary")
Signed-off-by: Steve Capper <steve.capper(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5960bef0170d..00e7b900ca41 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -476,6 +476,8 @@ void __init arm64_memblock_init(void)
reserve_elfcorehdr();
+ high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
+
dma_contiguous_reserve(arm64_dma_phys_limit);
memblock_allow_resize();
@@ -502,7 +504,6 @@ void __init bootmem_init(void)
sparse_init();
zone_sizes_init(min, max);
- high_memory = __va((max << PAGE_SHIFT) - 1) + 1;
memblock_dump_all();
}
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 f24e5834a2c3f6c5f814a417f858226f0a010ade Mon Sep 17 00:00:00 2001
From: Steve Capper <steve.capper(a)arm.com>
Date: Mon, 4 Dec 2017 14:13:05 +0000
Subject: [PATCH] arm64: Initialise high_memory global variable earlier
The high_memory global variable is used by
cma_declare_contiguous(.) before it is defined.
We don't notice this as we compute __pa(high_memory - 1), and it looks
like we're processing a VA from the direct linear map.
This problem becomes apparent when we flip the kernel virtual address
space and the linear map is moved to the bottom of the kernel VA space.
This patch moves the initialisation of high_memory before it used.
Cc: <stable(a)vger.kernel.org>
Fixes: f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory boundary")
Signed-off-by: Steve Capper <steve.capper(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5960bef0170d..00e7b900ca41 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -476,6 +476,8 @@ void __init arm64_memblock_init(void)
reserve_elfcorehdr();
+ high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
+
dma_contiguous_reserve(arm64_dma_phys_limit);
memblock_allow_resize();
@@ -502,7 +504,6 @@ void __init bootmem_init(void)
sparse_init();
zone_sizes_init(min, max);
- high_memory = __va((max << PAGE_SHIFT) - 1) + 1;
memblock_dump_all();
}
The patch below does not apply to the 4.9-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 f24e5834a2c3f6c5f814a417f858226f0a010ade Mon Sep 17 00:00:00 2001
From: Steve Capper <steve.capper(a)arm.com>
Date: Mon, 4 Dec 2017 14:13:05 +0000
Subject: [PATCH] arm64: Initialise high_memory global variable earlier
The high_memory global variable is used by
cma_declare_contiguous(.) before it is defined.
We don't notice this as we compute __pa(high_memory - 1), and it looks
like we're processing a VA from the direct linear map.
This problem becomes apparent when we flip the kernel virtual address
space and the linear map is moved to the bottom of the kernel VA space.
This patch moves the initialisation of high_memory before it used.
Cc: <stable(a)vger.kernel.org>
Fixes: f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory boundary")
Signed-off-by: Steve Capper <steve.capper(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5960bef0170d..00e7b900ca41 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -476,6 +476,8 @@ void __init arm64_memblock_init(void)
reserve_elfcorehdr();
+ high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
+
dma_contiguous_reserve(arm64_dma_phys_limit);
memblock_allow_resize();
@@ -502,7 +504,6 @@ void __init bootmem_init(void)
sparse_init();
zone_sizes_init(min, max);
- high_memory = __va((max << PAGE_SHIFT) - 1) + 1;
memblock_dump_all();
}
This is a note to let you know that I've just added the patch titled
usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-fix-stub_send_ret_submit-vulnerability-to-null-transfer_buffer.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From be6123df1ea8f01ee2f896a16c2b7be3e4557a5a Mon Sep 17 00:00:00 2001
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Thu, 7 Dec 2017 14:16:50 -0700
Subject: usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer
From: Shuah Khan <shuahkh(a)osg.samsung.com>
commit be6123df1ea8f01ee2f896a16c2b7be3e4557a5a upstream.
stub_send_ret_submit() handles urb with a potential null transfer_buffer,
when it replays a packet with potential malicious data that could contain
a null buffer. Add a check for the condition when actual_length > 0 and
transfer_buffer is null.
Reported-by: Secunia Research <vuln(a)secunia.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/stub_tx.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/usb/usbip/stub_tx.c
+++ b/drivers/usb/usbip/stub_tx.c
@@ -178,6 +178,13 @@ static int stub_send_ret_submit(struct s
memset(&pdu_header, 0, sizeof(pdu_header));
memset(&msg, 0, sizeof(msg));
+ if (urb->actual_length > 0 && !urb->transfer_buffer) {
+ dev_err(&sdev->udev->dev,
+ "urb: actual_length %d transfer_buffer null\n",
+ urb->actual_length);
+ return -1;
+ }
+
if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS)
iovnum = 2 + urb->number_of_packets;
else
Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are
queue-4.4/usbip-fix-stub_send_ret_submit-vulnerability-to-null-transfer_buffer.patch
This is a note to let you know that I've just added the patch titled
USB: core: prevent malicious bNumInterfaces overflow
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-core-prevent-malicious-bnuminterfaces-overflow.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 48a4ff1c7bb5a32d2e396b03132d20d552c0eca7 Mon Sep 17 00:00:00 2001
From: Alan Stern <stern(a)rowland.harvard.edu>
Date: Tue, 12 Dec 2017 14:25:13 -0500
Subject: USB: core: prevent malicious bNumInterfaces overflow
From: Alan Stern <stern(a)rowland.harvard.edu>
commit 48a4ff1c7bb5a32d2e396b03132d20d552c0eca7 upstream.
A malicious USB device with crafted descriptors can cause the kernel
to access unallocated memory by setting the bNumInterfaces value too
high in a configuration descriptor. Although the value is adjusted
during parsing, this adjustment is skipped in one of the error return
paths.
This patch prevents the problem by setting bNumInterfaces to 0
initially. The existing code already sets it to the proper value
after parsing is complete.
Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/config.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -521,6 +521,9 @@ static int usb_parse_configuration(struc
unsigned iad_num = 0;
memcpy(&config->desc, buffer, USB_DT_CONFIG_SIZE);
+ nintf = nintf_orig = config->desc.bNumInterfaces;
+ config->desc.bNumInterfaces = 0; // Adjusted later
+
if (config->desc.bDescriptorType != USB_DT_CONFIG ||
config->desc.bLength < USB_DT_CONFIG_SIZE ||
config->desc.bLength > size) {
@@ -534,7 +537,6 @@ static int usb_parse_configuration(struc
buffer += config->desc.bLength;
size -= config->desc.bLength;
- nintf = nintf_orig = config->desc.bNumInterfaces;
if (nintf > USB_MAXINTERFACES) {
dev_warn(ddev, "config %d has too many interfaces: %d, "
"using maximum allowed: %d\n",
Patches currently in stable-queue which might be from stern(a)rowland.harvard.edu are
queue-4.4/usb-core-prevent-malicious-bnuminterfaces-overflow.patch
queue-4.4/usb-uas-and-storage-add-us_fl_broken_fua-for-another-jmicron-jms567-id.patch
This is a note to let you know that I've just added the patch titled
USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-uas-and-storage-add-us_fl_broken_fua-for-another-jmicron-jms567-id.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 62354454625741f0569c2cbe45b2d192f8fd258e Mon Sep 17 00:00:00 2001
From: David Kozub <zub(a)linux.fjfi.cvut.cz>
Date: Tue, 5 Dec 2017 22:40:04 +0100
Subject: USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID
From: David Kozub <zub(a)linux.fjfi.cvut.cz>
commit 62354454625741f0569c2cbe45b2d192f8fd258e upstream.
There is another JMS567-based USB3 UAS enclosure (152d:0578) that fails
with the following error:
[sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[sda] tag#0 Sense Key : Illegal Request [current]
[sda] tag#0 Add. Sense: Invalid field in cdb
The issue occurs both with UAS (occasionally) and mass storage
(immediately after mounting a FS on a disk in the enclosure).
Enabling US_FL_BROKEN_FUA quirk solves this issue.
This patch adds an UNUSUAL_DEV with US_FL_BROKEN_FUA for the enclosure
for both UAS and mass storage.
Signed-off-by: David Kozub <zub(a)linux.fjfi.cvut.cz>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/storage/unusual_devs.h | 7 +++++++
drivers/usb/storage/unusual_uas.h | 7 +++++++
2 files changed, 14 insertions(+)
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2149,6 +2149,13 @@ UNUSUAL_DEV(0x152d, 0x9561, 0x0000, 0x99
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_NO_REPORT_OPCODES),
+/* Reported by David Kozub <zub(a)linux.fjfi.cvut.cz> */
+UNUSUAL_DEV(0x152d, 0x0578, 0x0000, 0x9999,
+ "JMicron",
+ "JMS567",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BROKEN_FUA),
+
/*
* Patch by Constantin Baranov <const(a)tltsu.ru>
* Report by Andreas Koenecke.
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -141,6 +141,13 @@ UNUSUAL_DEV(0x152d, 0x0567, 0x0000, 0x99
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_BROKEN_FUA | US_FL_NO_REPORT_OPCODES),
+/* Reported-by: David Kozub <zub(a)linux.fjfi.cvut.cz> */
+UNUSUAL_DEV(0x152d, 0x0578, 0x0000, 0x9999,
+ "JMicron",
+ "JMS567",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_BROKEN_FUA),
+
/* Reported-by: Hans de Goede <hdegoede(a)redhat.com> */
UNUSUAL_DEV(0x2109, 0x0711, 0x0000, 0x9999,
"VIA",
Patches currently in stable-queue which might be from zub(a)linux.fjfi.cvut.cz are
queue-4.4/usb-uas-and-storage-add-us_fl_broken_fua-for-another-jmicron-jms567-id.patch
This is a note to let you know that I've just added the patch titled
tracing: Allocate mask_str buffer dynamically
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
tracing-allocate-mask_str-buffer-dynamically.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 90e406f96f630c07d631a021fd4af10aac913e77 Mon Sep 17 00:00:00 2001
From: Changbin Du <changbin.du(a)intel.com>
Date: Thu, 30 Nov 2017 11:39:43 +0800
Subject: tracing: Allocate mask_str buffer dynamically
From: Changbin Du <changbin.du(a)intel.com>
commit 90e406f96f630c07d631a021fd4af10aac913e77 upstream.
The default NR_CPUS can be very large, but actual possible nr_cpu_ids
usually is very small. For my x86 distribution, the NR_CPUS is 8192 and
nr_cpu_ids is 4. About 2 pages are wasted.
Most machines don't have so many CPUs, so define a array with NR_CPUS
just wastes memory. So let's allocate the buffer dynamically when need.
With this change, the mutext tracing_cpumask_update_lock also can be
removed now, which was used to protect mask_str.
Link: http://lkml.kernel.org/r/1512013183-19107-1-git-send-email-changbin.du@inte…
Fixes: 36dfe9252bd4c ("ftrace: make use of tracing_cpumask")
Signed-off-by: Changbin Du <changbin.du(a)intel.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/trace/trace.c | 29 +++++++++--------------------
1 file changed, 9 insertions(+), 20 deletions(-)
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3384,37 +3384,30 @@ static const struct file_operations show
.llseek = seq_lseek,
};
-/*
- * The tracer itself will not take this lock, but still we want
- * to provide a consistent cpumask to user-space:
- */
-static DEFINE_MUTEX(tracing_cpumask_update_lock);
-
-/*
- * Temporary storage for the character representation of the
- * CPU bitmask (and one more byte for the newline):
- */
-static char mask_str[NR_CPUS + 1];
-
static ssize_t
tracing_cpumask_read(struct file *filp, char __user *ubuf,
size_t count, loff_t *ppos)
{
struct trace_array *tr = file_inode(filp)->i_private;
+ char *mask_str;
int len;
- mutex_lock(&tracing_cpumask_update_lock);
+ len = snprintf(NULL, 0, "%*pb\n",
+ cpumask_pr_args(tr->tracing_cpumask)) + 1;
+ mask_str = kmalloc(len, GFP_KERNEL);
+ if (!mask_str)
+ return -ENOMEM;
- len = snprintf(mask_str, count, "%*pb\n",
+ len = snprintf(mask_str, len, "%*pb\n",
cpumask_pr_args(tr->tracing_cpumask));
if (len >= count) {
count = -EINVAL;
goto out_err;
}
- count = simple_read_from_buffer(ubuf, count, ppos, mask_str, NR_CPUS+1);
+ count = simple_read_from_buffer(ubuf, count, ppos, mask_str, len);
out_err:
- mutex_unlock(&tracing_cpumask_update_lock);
+ kfree(mask_str);
return count;
}
@@ -3434,8 +3427,6 @@ tracing_cpumask_write(struct file *filp,
if (err)
goto err_unlock;
- mutex_lock(&tracing_cpumask_update_lock);
-
local_irq_disable();
arch_spin_lock(&tr->max_lock);
for_each_tracing_cpu(cpu) {
@@ -3458,8 +3449,6 @@ tracing_cpumask_write(struct file *filp,
local_irq_enable();
cpumask_copy(tr->tracing_cpumask, tracing_cpumask_new);
-
- mutex_unlock(&tracing_cpumask_update_lock);
free_cpumask_var(tracing_cpumask_new);
return count;
Patches currently in stable-queue which might be from changbin.du(a)intel.com are
queue-4.4/tracing-allocate-mask_str-buffer-dynamically.patch
This is a note to let you know that I've just added the patch titled
ceph: drop negative child dentries before try pruning inode's alias
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ceph-drop-negative-child-dentries-before-try-pruning-inode-s-alias.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 040d786032bf59002d374b86d75b04d97624005c Mon Sep 17 00:00:00 2001
From: "Yan, Zheng" <zyan(a)redhat.com>
Date: Thu, 30 Nov 2017 11:59:22 +0800
Subject: ceph: drop negative child dentries before try pruning inode's alias
From: Yan, Zheng <zyan(a)redhat.com>
commit 040d786032bf59002d374b86d75b04d97624005c upstream.
Negative child dentry holds reference on inode's alias, it makes
d_prune_aliases() do nothing.
Signed-off-by: "Yan, Zheng" <zyan(a)redhat.com>
Reviewed-by: Jeff Layton <jlayton(a)redhat.com>
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ceph/mds_client.c | 42 ++++++++++++++++++++++++++++++++++++++----
1 file changed, 38 insertions(+), 4 deletions(-)
--- a/fs/ceph/mds_client.c
+++ b/fs/ceph/mds_client.c
@@ -1400,6 +1400,29 @@ static int __close_session(struct ceph_m
return request_close_session(mdsc, session);
}
+static bool drop_negative_children(struct dentry *dentry)
+{
+ struct dentry *child;
+ bool all_negative = true;
+
+ if (!d_is_dir(dentry))
+ goto out;
+
+ spin_lock(&dentry->d_lock);
+ list_for_each_entry(child, &dentry->d_subdirs, d_child) {
+ if (d_really_is_positive(child)) {
+ all_negative = false;
+ break;
+ }
+ }
+ spin_unlock(&dentry->d_lock);
+
+ if (all_negative)
+ shrink_dcache_parent(dentry);
+out:
+ return all_negative;
+}
+
/*
* Trim old(er) caps.
*
@@ -1445,16 +1468,27 @@ static int trim_caps_cb(struct inode *in
if ((used | wanted) & ~oissued & mine)
goto out; /* we need these caps */
- session->s_trim_caps--;
if (oissued) {
/* we aren't the only cap.. just remove us */
__ceph_remove_cap(cap, true);
+ session->s_trim_caps--;
} else {
+ struct dentry *dentry;
/* try dropping referring dentries */
spin_unlock(&ci->i_ceph_lock);
- d_prune_aliases(inode);
- dout("trim_caps_cb %p cap %p pruned, count now %d\n",
- inode, cap, atomic_read(&inode->i_count));
+ dentry = d_find_any_alias(inode);
+ if (dentry && drop_negative_children(dentry)) {
+ int count;
+ dput(dentry);
+ d_prune_aliases(inode);
+ count = atomic_read(&inode->i_count);
+ if (count == 1)
+ session->s_trim_caps--;
+ dout("trim_caps_cb %p cap %p pruned, count now %d\n",
+ inode, cap, count);
+ } else {
+ dput(dentry);
+ }
return 0;
}
Patches currently in stable-queue which might be from zyan(a)redhat.com are
queue-4.4/ceph-drop-negative-child-dentries-before-try-pruning-inode-s-alias.patch
This is a note to let you know that I've just added the patch titled
autofs: fix careless error in recent commit
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
autofs-fix-careless-error-in-recent-commit.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 302ec300ef8a545a7fc7f667e5fd743b091c2eeb Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb(a)suse.com>
Date: Thu, 14 Dec 2017 15:32:38 -0800
Subject: autofs: fix careless error in recent commit
From: NeilBrown <neilb(a)suse.com>
commit 302ec300ef8a545a7fc7f667e5fd743b091c2eeb upstream.
Commit ecc0c469f277 ("autofs: don't fail mount for transient error") was
meant to replace an 'if' with a 'switch', but instead added the 'switch'
leaving the case in place.
Link: http://lkml.kernel.org/r/87zi6wstmw.fsf@notabene.neil.brown.name
Fixes: ecc0c469f277 ("autofs: don't fail mount for transient error")
Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: NeilBrown <neilb(a)suse.com>
Cc: Ian Kent <raven(a)themaw.net>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/autofs4/waitq.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/autofs4/waitq.c
+++ b/fs/autofs4/waitq.c
@@ -174,7 +174,6 @@ static void autofs4_notify_daemon(struct
mutex_unlock(&sbi->wq_mutex);
- if (autofs4_write(sbi, pipe, &pkt, pktsz))
switch (ret = autofs4_write(sbi, pipe, &pkt, pktsz)) {
case 0:
break;
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-4.4/autofs-fix-careless-error-in-recent-commit.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btusb: driver to enable the usb-wakeup feature
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bluetooth-btusb-driver-to-enable-the-usb-wakeup-feature.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a0085f2510e8976614ad8f766b209448b385492f Mon Sep 17 00:00:00 2001
From: Sukumar Ghorai <sukumar.ghorai(a)intel.com>
Date: Wed, 16 Aug 2017 14:46:55 -0700
Subject: Bluetooth: btusb: driver to enable the usb-wakeup feature
From: Sukumar Ghorai <sukumar.ghorai(a)intel.com>
commit a0085f2510e8976614ad8f766b209448b385492f upstream.
BT-Controller connected as platform non-root-hub device and
usb-driver initialize such device with wakeup disabled,
Ref. usb_new_device().
At present wakeup-capability get enabled by hid-input device from usb
function driver(e.g. BT HID device) at runtime. Again some functional
driver does not set usb-wakeup capability(e.g LE HID device implement
as HID-over-GATT), and can't wakeup the host on USB.
Most of the device operation (such as mass storage) initiated from host
(except HID) and USB wakeup aligned with host resume procedure. For BT
device, usb-wakeup capability need to enable form btusc driver as a
generic solution for multiple profile use case and required for USB remote
wakeup (in-bus wakeup) while host is suspended. Also usb-wakeup feature
need to enable/disable with HCI interface up and down.
Signed-off-by: Sukumar Ghorai <sukumar.ghorai(a)intel.com>
Signed-off-by: Amit K Bag <amit.k.bag(a)intel.com>
Acked-by: Oliver Neukum <oneukum(a)suse.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1050,6 +1050,10 @@ static int btusb_open(struct hci_dev *hd
return err;
data->intf->needs_remote_wakeup = 1;
+ /* device specific wakeup source enabled and required for USB
+ * remote wakeup while host is suspended
+ */
+ device_wakeup_enable(&data->udev->dev);
if (test_and_set_bit(BTUSB_INTR_RUNNING, &data->flags))
goto done;
@@ -1113,6 +1117,7 @@ static int btusb_close(struct hci_dev *h
goto failed;
data->intf->needs_remote_wakeup = 0;
+ device_wakeup_disable(&data->udev->dev);
usb_autopm_put_interface(data->intf);
failed:
Patches currently in stable-queue which might be from sukumar.ghorai(a)intel.com are
queue-4.4/bluetooth-btusb-driver-to-enable-the-usb-wakeup-feature.patch
The patch below does not apply to the 3.18-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 bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu(a)ti.com>
Date: Tue, 5 Dec 2017 08:45:30 -0600
Subject: [PATCH] usb: musb: da8xx: fix babble condition handling
When babble condition happens, the musb controller might automatically
turns off VBUS. On DA8xx platform, the controller generates drvvbus
interrupt for turning off VBUS along with the babble interrupt.
In this case, we should handle the babble interrupt first and recover
from the babble condition.
This change ignores the drvvbus interrupt if babble interrupt is also
generated at the same time, so the babble recovery routine works
properly.
Cc: stable(a)vger.kernel.org # v3.16+
Signed-off-by: Bin Liu <b-liu(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 0397606a211b..6c036de63272 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -284,7 +284,15 @@ static irqreturn_t da8xx_musb_interrupt(int irq, void *hci)
musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
portstate(musb->port1_status |= USB_PORT_STAT_POWER);
del_timer(&musb->dev_timer);
- } else {
+ } else if (!(musb->int_usb & MUSB_INTR_BABBLE)) {
+ /*
+ * When babble condition happens, drvvbus interrupt
+ * is also generated. Ignore this drvvbus interrupt
+ * and let babble interrupt handler recovers the
+ * controller; otherwise, the host-mode flag is lost
+ * due to the MUSB_DEV_MODE() call below and babble
+ * recovery logic will not be called.
+ */
musb->is_active = 0;
MUSB_DEV_MODE(musb);
otg->default_a = 0;
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 bd3486ded7a0c313a6575343e6c2b21d14476645 Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu(a)ti.com>
Date: Tue, 5 Dec 2017 08:45:30 -0600
Subject: [PATCH] usb: musb: da8xx: fix babble condition handling
When babble condition happens, the musb controller might automatically
turns off VBUS. On DA8xx platform, the controller generates drvvbus
interrupt for turning off VBUS along with the babble interrupt.
In this case, we should handle the babble interrupt first and recover
from the babble condition.
This change ignores the drvvbus interrupt if babble interrupt is also
generated at the same time, so the babble recovery routine works
properly.
Cc: stable(a)vger.kernel.org # v3.16+
Signed-off-by: Bin Liu <b-liu(a)ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 0397606a211b..6c036de63272 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -284,7 +284,15 @@ static irqreturn_t da8xx_musb_interrupt(int irq, void *hci)
musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
portstate(musb->port1_status |= USB_PORT_STAT_POWER);
del_timer(&musb->dev_timer);
- } else {
+ } else if (!(musb->int_usb & MUSB_INTR_BABBLE)) {
+ /*
+ * When babble condition happens, drvvbus interrupt
+ * is also generated. Ignore this drvvbus interrupt
+ * and let babble interrupt handler recovers the
+ * controller; otherwise, the host-mode flag is lost
+ * due to the MUSB_DEV_MODE() call below and babble
+ * recovery logic will not be called.
+ */
musb->is_active = 0;
MUSB_DEV_MODE(musb);
otg->default_a = 0;
The patch below does not apply to the 4.14-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 e8d4bfe3a71537284a90561f77c85dea6c154369 Mon Sep 17 00:00:00 2001
From: Chengguang Xu <cgxu(a)mykernel.net>
Date: Wed, 29 Nov 2017 10:01:32 +0800
Subject: [PATCH] ovl: Sync upper dirty data when syncing overlayfs
When executing filesystem sync or umount on overlayfs,
dirty data does not get synced as expected on upper filesystem.
This patch fixes sync filesystem method to keep data consistency
for overlayfs.
Signed-off-by: Chengguang Xu <cgxu(a)mykernel.net>
Fixes: e593b2bf513d ("ovl: properly implement sync_filesystem()")
Cc: <stable(a)vger.kernel.org> #4.11
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 13a8a8617e44..76440feb79f6 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -252,6 +252,7 @@ static void ovl_put_super(struct super_block *sb)
ovl_free_fs(ofs);
}
+/* Sync real dirty inodes in upper filesystem (if it exists) */
static int ovl_sync_fs(struct super_block *sb, int wait)
{
struct ovl_fs *ofs = sb->s_fs_info;
@@ -260,14 +261,24 @@ static int ovl_sync_fs(struct super_block *sb, int wait)
if (!ofs->upper_mnt)
return 0;
- upper_sb = ofs->upper_mnt->mnt_sb;
- if (!upper_sb->s_op->sync_fs)
+
+ /*
+ * If this is a sync(2) call or an emergency sync, all the super blocks
+ * will be iterated, including upper_sb, so no need to do anything.
+ *
+ * If this is a syncfs(2) call, then we do need to call
+ * sync_filesystem() on upper_sb, but enough if we do it when being
+ * called with wait == 1.
+ */
+ if (!wait)
return 0;
- /* real inodes have already been synced by sync_filesystem(ovl_sb) */
+ upper_sb = ofs->upper_mnt->mnt_sb;
+
down_read(&upper_sb->s_umount);
- ret = upper_sb->s_op->sync_fs(upper_sb, wait);
+ ret = sync_filesystem(upper_sb);
up_read(&upper_sb->s_umount);
+
return ret;
}
This is a note to let you know that I've just added the patch titled
crypto: salsa20 - fix blkcipher_walk API usage
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-salsa20-fix-blkcipher_walk-api-usage.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ecaaab5649781c5a0effdaf298a925063020500e Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Tue, 28 Nov 2017 20:56:59 -0800
Subject: crypto: salsa20 - fix blkcipher_walk API usage
From: Eric Biggers <ebiggers(a)google.com>
commit ecaaab5649781c5a0effdaf298a925063020500e upstream.
When asked to encrypt or decrypt 0 bytes, both the generic and x86
implementations of Salsa20 crash in blkcipher_walk_done(), either when
doing 'kfree(walk->buffer)' or 'free_page((unsigned long)walk->page)',
because walk->buffer and walk->page have not been initialized.
The bug is that Salsa20 is calling blkcipher_walk_done() even when
nothing is in 'walk.nbytes'. But blkcipher_walk_done() is only meant to
be called when a nonzero number of bytes have been provided.
The broken code is part of an optimization that tries to make only one
call to salsa20_encrypt_bytes() to process inputs that are not evenly
divisible by 64 bytes. To fix the bug, just remove this "optimization"
and use the blkcipher_walk API the same way all the other users do.
Reproducer:
#include <linux/if_alg.h>
#include <sys/socket.h>
#include <unistd.h>
int main()
{
int algfd, reqfd;
struct sockaddr_alg addr = {
.salg_type = "skcipher",
.salg_name = "salsa20",
};
char key[16] = { 0 };
algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(algfd, (void *)&addr, sizeof(addr));
reqfd = accept(algfd, 0, 0);
setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
read(reqfd, key, sizeof(key));
}
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Fixes: eb6f13eb9f81 ("[CRYPTO] salsa20_generic: Fix multi-page processing")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/salsa20_glue.c | 7 -------
crypto/salsa20_generic.c | 7 -------
2 files changed, 14 deletions(-)
--- a/arch/x86/crypto/salsa20_glue.c
+++ b/arch/x86/crypto/salsa20_glue.c
@@ -59,13 +59,6 @@ static int encrypt(struct blkcipher_desc
salsa20_ivsetup(ctx, walk.iv);
- if (likely(walk.nbytes == nbytes))
- {
- salsa20_encrypt_bytes(ctx, walk.src.virt.addr,
- walk.dst.virt.addr, nbytes);
- return blkcipher_walk_done(desc, &walk, 0);
- }
-
while (walk.nbytes >= 64) {
salsa20_encrypt_bytes(ctx, walk.src.virt.addr,
walk.dst.virt.addr,
--- a/crypto/salsa20_generic.c
+++ b/crypto/salsa20_generic.c
@@ -188,13 +188,6 @@ static int encrypt(struct blkcipher_desc
salsa20_ivsetup(ctx, walk.iv);
- if (likely(walk.nbytes == nbytes))
- {
- salsa20_encrypt_bytes(ctx, walk.dst.virt.addr,
- walk.src.virt.addr, nbytes);
- return blkcipher_walk_done(desc, &walk, 0);
- }
-
while (walk.nbytes >= 64) {
salsa20_encrypt_bytes(ctx, walk.dst.virt.addr,
walk.src.virt.addr,
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/crypto-salsa20-fix-blkcipher_walk-api-usage.patch
queue-4.9/crypto-rsa-fix-buffer-overread-when-stripping-leading-zeroes.patch
queue-4.9/crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
This is a note to let you know that I've just added the patch titled
crypto: rsa - fix buffer overread when stripping leading zeroes
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-rsa-fix-buffer-overread-when-stripping-leading-zeroes.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d2890c3778b164fde587bc16583f3a1c87233ec5 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Sun, 26 Nov 2017 23:16:49 -0800
Subject: crypto: rsa - fix buffer overread when stripping leading zeroes
From: Eric Biggers <ebiggers(a)google.com>
commit d2890c3778b164fde587bc16583f3a1c87233ec5 upstream.
In rsa_get_n(), if the buffer contained all 0's and "FIPS mode" is
enabled, we would read one byte past the end of the buffer while
scanning the leading zeroes. Fix it by checking 'n_sz' before '!*ptr'.
This bug was reachable by adding a specially crafted key of type
"asymmetric" (requires CONFIG_RSA and CONFIG_X509_CERTIFICATE_PARSER).
KASAN report:
BUG: KASAN: slab-out-of-bounds in rsa_get_n+0x19e/0x1d0 crypto/rsa_helper.c:33
Read of size 1 at addr ffff88003501a708 by task keyctl/196
CPU: 1 PID: 196 Comm: keyctl Not tainted 4.14.0-09238-g1d3b78bbc6e9 #26
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
Call Trace:
rsa_get_n+0x19e/0x1d0 crypto/rsa_helper.c:33
asn1_ber_decoder+0x82a/0x1fd0 lib/asn1_decoder.c:328
rsa_set_pub_key+0xd3/0x320 crypto/rsa.c:278
crypto_akcipher_set_pub_key ./include/crypto/akcipher.h:364 [inline]
pkcs1pad_set_pub_key+0xae/0x200 crypto/rsa-pkcs1pad.c:117
crypto_akcipher_set_pub_key ./include/crypto/akcipher.h:364 [inline]
public_key_verify_signature+0x270/0x9d0 crypto/asymmetric_keys/public_key.c:106
x509_check_for_self_signed+0x2ea/0x480 crypto/asymmetric_keys/x509_public_key.c:141
x509_cert_parse+0x46a/0x620 crypto/asymmetric_keys/x509_cert_parser.c:129
x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174
asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388
key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0x96
Allocated by task 196:
__do_kmalloc mm/slab.c:3711 [inline]
__kmalloc_track_caller+0x118/0x2e0 mm/slab.c:3726
kmemdup+0x17/0x40 mm/util.c:118
kmemdup ./include/linux/string.h:414 [inline]
x509_cert_parse+0x2cb/0x620 crypto/asymmetric_keys/x509_cert_parser.c:106
x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174
asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388
key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0x96
Fixes: 5a7de97309f5 ("crypto: rsa - return raw integers for the ASN.1 parser")
Cc: Tudor Ambarus <tudor-dan.ambarus(a)nxp.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Reviewed-by: James Morris <james.l.morris(a)oracle.com>
Reviewed-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/rsa_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/crypto/rsa_helper.c
+++ b/crypto/rsa_helper.c
@@ -30,7 +30,7 @@ int rsa_get_n(void *context, size_t hdrl
return -EINVAL;
if (fips_enabled) {
- while (!*ptr && n_sz) {
+ while (n_sz && !*ptr) {
ptr++;
n_sz--;
}
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/crypto-salsa20-fix-blkcipher_walk-api-usage.patch
queue-4.9/crypto-rsa-fix-buffer-overread-when-stripping-leading-zeroes.patch
queue-4.9/crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
This is a note to let you know that I've just added the patch titled
crypto: hmac - require that the underlying hash algorithm is unkeyed
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From af3ff8045bbf3e32f1a448542e73abb4c8ceb6f1 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Tue, 28 Nov 2017 18:01:38 -0800
Subject: crypto: hmac - require that the underlying hash algorithm is unkeyed
From: Eric Biggers <ebiggers(a)google.com>
commit af3ff8045bbf3e32f1a448542e73abb4c8ceb6f1 upstream.
Because the HMAC template didn't check that its underlying hash
algorithm is unkeyed, trying to use "hmac(hmac(sha3-512-generic))"
through AF_ALG or through KEYCTL_DH_COMPUTE resulted in the inner HMAC
being used without having been keyed, resulting in sha3_update() being
called without sha3_init(), causing a stack buffer overflow.
This is a very old bug, but it seems to have only started causing real
problems when SHA-3 support was added (requires CONFIG_CRYPTO_SHA3)
because the innermost hash's state is ->import()ed from a zeroed buffer,
and it just so happens that other hash algorithms are fine with that,
but SHA-3 is not. However, there could be arch or hardware-dependent
hash algorithms also affected; I couldn't test everything.
Fix the bug by introducing a function crypto_shash_alg_has_setkey()
which tests whether a shash algorithm is keyed. Then update the HMAC
template to require that its underlying hash algorithm is unkeyed.
Here is a reproducer:
#include <linux/if_alg.h>
#include <sys/socket.h>
int main()
{
int algfd;
struct sockaddr_alg addr = {
.salg_type = "hash",
.salg_name = "hmac(hmac(sha3-512-generic))",
};
char key[4096] = { 0 };
algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(algfd, (const struct sockaddr *)&addr, sizeof(addr));
setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
}
Here was the KASAN report from syzbot:
BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:341 [inline]
BUG: KASAN: stack-out-of-bounds in sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
Write of size 4096 at addr ffff8801cca07c40 by task syzkaller076574/3044
CPU: 1 PID: 3044 Comm: syzkaller076574 Not tainted 4.14.0-mm1+ #25
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x25b/0x340 mm/kasan/report.c:409
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
memcpy+0x37/0x50 mm/kasan/kasan.c:303
memcpy include/linux/string.h:341 [inline]
sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
crypto_shash_update+0xcb/0x220 crypto/shash.c:109
shash_finup_unaligned+0x2a/0x60 crypto/shash.c:151
crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
hmac_finup+0x182/0x330 crypto/hmac.c:152
crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
shash_digest_unaligned+0x9e/0xd0 crypto/shash.c:172
crypto_shash_digest+0xc4/0x120 crypto/shash.c:186
hmac_setkey+0x36a/0x690 crypto/hmac.c:66
crypto_shash_setkey+0xad/0x190 crypto/shash.c:64
shash_async_setkey+0x47/0x60 crypto/shash.c:207
crypto_ahash_setkey+0xaf/0x180 crypto/ahash.c:200
hash_setkey+0x40/0x90 crypto/algif_hash.c:446
alg_setkey crypto/af_alg.c:221 [inline]
alg_setsockopt+0x2a1/0x350 crypto/af_alg.c:254
SYSC_setsockopt net/socket.c:1851 [inline]
SyS_setsockopt+0x189/0x360 net/socket.c:1830
entry_SYSCALL_64_fastpath+0x1f/0x96
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/hmac.c | 6 +++++-
crypto/shash.c | 5 +++--
include/crypto/internal/hash.h | 8 ++++++++
3 files changed, 16 insertions(+), 3 deletions(-)
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -194,11 +194,15 @@ static int hmac_create(struct crypto_tem
salg = shash_attr_alg(tb[1], 0, 0);
if (IS_ERR(salg))
return PTR_ERR(salg);
+ alg = &salg->base;
+ /* The underlying hash algorithm must be unkeyed */
err = -EINVAL;
+ if (crypto_shash_alg_has_setkey(salg))
+ goto out_put_alg;
+
ds = salg->digestsize;
ss = salg->statesize;
- alg = &salg->base;
if (ds > alg->cra_blocksize ||
ss < alg->cra_blocksize)
goto out_put_alg;
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -24,11 +24,12 @@
static const struct crypto_type crypto_shash_type;
-static int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
- unsigned int keylen)
+int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
+ unsigned int keylen)
{
return -ENOSYS;
}
+EXPORT_SYMBOL_GPL(shash_no_setkey);
static int shash_setkey_unaligned(struct crypto_shash *tfm, const u8 *key,
unsigned int keylen)
--- a/include/crypto/internal/hash.h
+++ b/include/crypto/internal/hash.h
@@ -80,6 +80,14 @@ int ahash_register_instance(struct crypt
struct ahash_instance *inst);
void ahash_free_instance(struct crypto_instance *inst);
+int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
+ unsigned int keylen);
+
+static inline bool crypto_shash_alg_has_setkey(struct shash_alg *alg)
+{
+ return alg->setkey != shash_no_setkey;
+}
+
int crypto_init_ahash_spawn(struct crypto_ahash_spawn *spawn,
struct hash_alg_common *alg,
struct crypto_instance *inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/crypto-salsa20-fix-blkcipher_walk-api-usage.patch
queue-4.9/crypto-rsa-fix-buffer-overread-when-stripping-leading-zeroes.patch
queue-4.9/crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
This is a note to let you know that I've just added the patch titled
crypto: salsa20 - fix blkcipher_walk API usage
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-salsa20-fix-blkcipher_walk-api-usage.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ecaaab5649781c5a0effdaf298a925063020500e Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Tue, 28 Nov 2017 20:56:59 -0800
Subject: crypto: salsa20 - fix blkcipher_walk API usage
From: Eric Biggers <ebiggers(a)google.com>
commit ecaaab5649781c5a0effdaf298a925063020500e upstream.
When asked to encrypt or decrypt 0 bytes, both the generic and x86
implementations of Salsa20 crash in blkcipher_walk_done(), either when
doing 'kfree(walk->buffer)' or 'free_page((unsigned long)walk->page)',
because walk->buffer and walk->page have not been initialized.
The bug is that Salsa20 is calling blkcipher_walk_done() even when
nothing is in 'walk.nbytes'. But blkcipher_walk_done() is only meant to
be called when a nonzero number of bytes have been provided.
The broken code is part of an optimization that tries to make only one
call to salsa20_encrypt_bytes() to process inputs that are not evenly
divisible by 64 bytes. To fix the bug, just remove this "optimization"
and use the blkcipher_walk API the same way all the other users do.
Reproducer:
#include <linux/if_alg.h>
#include <sys/socket.h>
#include <unistd.h>
int main()
{
int algfd, reqfd;
struct sockaddr_alg addr = {
.salg_type = "skcipher",
.salg_name = "salsa20",
};
char key[16] = { 0 };
algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(algfd, (void *)&addr, sizeof(addr));
reqfd = accept(algfd, 0, 0);
setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
read(reqfd, key, sizeof(key));
}
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Fixes: eb6f13eb9f81 ("[CRYPTO] salsa20_generic: Fix multi-page processing")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/salsa20_glue.c | 7 -------
crypto/salsa20_generic.c | 7 -------
2 files changed, 14 deletions(-)
--- a/arch/x86/crypto/salsa20_glue.c
+++ b/arch/x86/crypto/salsa20_glue.c
@@ -59,13 +59,6 @@ static int encrypt(struct blkcipher_desc
salsa20_ivsetup(ctx, walk.iv);
- if (likely(walk.nbytes == nbytes))
- {
- salsa20_encrypt_bytes(ctx, walk.src.virt.addr,
- walk.dst.virt.addr, nbytes);
- return blkcipher_walk_done(desc, &walk, 0);
- }
-
while (walk.nbytes >= 64) {
salsa20_encrypt_bytes(ctx, walk.src.virt.addr,
walk.dst.virt.addr,
--- a/crypto/salsa20_generic.c
+++ b/crypto/salsa20_generic.c
@@ -188,13 +188,6 @@ static int encrypt(struct blkcipher_desc
salsa20_ivsetup(ctx, walk.iv);
- if (likely(walk.nbytes == nbytes))
- {
- salsa20_encrypt_bytes(ctx, walk.dst.virt.addr,
- walk.src.virt.addr, nbytes);
- return blkcipher_walk_done(desc, &walk, 0);
- }
-
while (walk.nbytes >= 64) {
salsa20_encrypt_bytes(ctx, walk.dst.virt.addr,
walk.src.virt.addr,
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.4/crypto-salsa20-fix-blkcipher_walk-api-usage.patch
queue-4.4/crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
This is a note to let you know that I've just added the patch titled
crypto: hmac - require that the underlying hash algorithm is unkeyed
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From af3ff8045bbf3e32f1a448542e73abb4c8ceb6f1 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Tue, 28 Nov 2017 18:01:38 -0800
Subject: crypto: hmac - require that the underlying hash algorithm is unkeyed
From: Eric Biggers <ebiggers(a)google.com>
commit af3ff8045bbf3e32f1a448542e73abb4c8ceb6f1 upstream.
Because the HMAC template didn't check that its underlying hash
algorithm is unkeyed, trying to use "hmac(hmac(sha3-512-generic))"
through AF_ALG or through KEYCTL_DH_COMPUTE resulted in the inner HMAC
being used without having been keyed, resulting in sha3_update() being
called without sha3_init(), causing a stack buffer overflow.
This is a very old bug, but it seems to have only started causing real
problems when SHA-3 support was added (requires CONFIG_CRYPTO_SHA3)
because the innermost hash's state is ->import()ed from a zeroed buffer,
and it just so happens that other hash algorithms are fine with that,
but SHA-3 is not. However, there could be arch or hardware-dependent
hash algorithms also affected; I couldn't test everything.
Fix the bug by introducing a function crypto_shash_alg_has_setkey()
which tests whether a shash algorithm is keyed. Then update the HMAC
template to require that its underlying hash algorithm is unkeyed.
Here is a reproducer:
#include <linux/if_alg.h>
#include <sys/socket.h>
int main()
{
int algfd;
struct sockaddr_alg addr = {
.salg_type = "hash",
.salg_name = "hmac(hmac(sha3-512-generic))",
};
char key[4096] = { 0 };
algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(algfd, (const struct sockaddr *)&addr, sizeof(addr));
setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
}
Here was the KASAN report from syzbot:
BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:341 [inline]
BUG: KASAN: stack-out-of-bounds in sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
Write of size 4096 at addr ffff8801cca07c40 by task syzkaller076574/3044
CPU: 1 PID: 3044 Comm: syzkaller076574 Not tainted 4.14.0-mm1+ #25
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x25b/0x340 mm/kasan/report.c:409
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
memcpy+0x37/0x50 mm/kasan/kasan.c:303
memcpy include/linux/string.h:341 [inline]
sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
crypto_shash_update+0xcb/0x220 crypto/shash.c:109
shash_finup_unaligned+0x2a/0x60 crypto/shash.c:151
crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
hmac_finup+0x182/0x330 crypto/hmac.c:152
crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
shash_digest_unaligned+0x9e/0xd0 crypto/shash.c:172
crypto_shash_digest+0xc4/0x120 crypto/shash.c:186
hmac_setkey+0x36a/0x690 crypto/hmac.c:66
crypto_shash_setkey+0xad/0x190 crypto/shash.c:64
shash_async_setkey+0x47/0x60 crypto/shash.c:207
crypto_ahash_setkey+0xaf/0x180 crypto/ahash.c:200
hash_setkey+0x40/0x90 crypto/algif_hash.c:446
alg_setkey crypto/af_alg.c:221 [inline]
alg_setsockopt+0x2a1/0x350 crypto/af_alg.c:254
SYSC_setsockopt net/socket.c:1851 [inline]
SyS_setsockopt+0x189/0x360 net/socket.c:1830
entry_SYSCALL_64_fastpath+0x1f/0x96
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/hmac.c | 6 +++++-
crypto/shash.c | 5 +++--
include/crypto/internal/hash.h | 8 ++++++++
3 files changed, 16 insertions(+), 3 deletions(-)
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -194,11 +194,15 @@ static int hmac_create(struct crypto_tem
salg = shash_attr_alg(tb[1], 0, 0);
if (IS_ERR(salg))
return PTR_ERR(salg);
+ alg = &salg->base;
+ /* The underlying hash algorithm must be unkeyed */
err = -EINVAL;
+ if (crypto_shash_alg_has_setkey(salg))
+ goto out_put_alg;
+
ds = salg->digestsize;
ss = salg->statesize;
- alg = &salg->base;
if (ds > alg->cra_blocksize ||
ss < alg->cra_blocksize)
goto out_put_alg;
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -24,11 +24,12 @@
static const struct crypto_type crypto_shash_type;
-static int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
- unsigned int keylen)
+int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
+ unsigned int keylen)
{
return -ENOSYS;
}
+EXPORT_SYMBOL_GPL(shash_no_setkey);
static int shash_setkey_unaligned(struct crypto_shash *tfm, const u8 *key,
unsigned int keylen)
--- a/include/crypto/internal/hash.h
+++ b/include/crypto/internal/hash.h
@@ -83,6 +83,14 @@ int ahash_register_instance(struct crypt
struct ahash_instance *inst);
void ahash_free_instance(struct crypto_instance *inst);
+int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
+ unsigned int keylen);
+
+static inline bool crypto_shash_alg_has_setkey(struct shash_alg *alg)
+{
+ return alg->setkey != shash_no_setkey;
+}
+
int crypto_init_ahash_spawn(struct crypto_ahash_spawn *spawn,
struct hash_alg_common *alg,
struct crypto_instance *inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.4/crypto-salsa20-fix-blkcipher_walk-api-usage.patch
queue-4.4/crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
This is a note to let you know that I've just added the patch titled
string.h: workaround for increased stack usage
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
string.h-workaround-for-increased-stack-usage.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 146734b091430c80d80bb96b1139a96fb4bc830e Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 14 Dec 2017 15:32:34 -0800
Subject: string.h: workaround for increased stack usage
From: Arnd Bergmann <arnd(a)arndb.de>
commit 146734b091430c80d80bb96b1139a96fb4bc830e upstream.
The hardened strlen() function causes rather large stack usage in at
least one file in the kernel, in particular when CONFIG_KASAN is
enabled:
drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
drivers/media/usb/em28xx/em28xx-dvb.c:2062:1: error: the frame size of 3256 bytes is larger than 204 bytes [-Werror=frame-larger-than=]
Analyzing this problem led to the discovery that gcc fails to merge the
stack slots for the i2c_board_info[] structures after we strlcpy() into
them, due to the 'noreturn' attribute on the source string length check.
I reported this as a gcc bug, but it is unlikely to get fixed for gcc-8,
since it is relatively easy to work around, and it gets triggered
rarely. An earlier workaround I did added an empty inline assembly
statement before the call to fortify_panic(), which works surprisingly
well, but is really ugly and unintuitive.
This is a new approach to the same problem, this time addressing it by
not calling the 'extern __real_strnlen()' function for string constants
where __builtin_strlen() is a compile-time constant and therefore known
to be safe.
We do this by checking if the last character in the string is a
compile-time constant '\0'. If it is, we can assume that strlen() of
the string is also constant.
As a side-effect, this should also improve the object code output for
any other call of strlen() on a string constant.
[akpm(a)linux-foundation.org: add comment]
Link: http://lkml.kernel.org/r/20171205215143.3085755-1-arnd@arndb.de
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
Link: https://patchwork.kernel.org/patch/9980413/
Link: https://patchwork.kernel.org/patch/9974047/
Fixes: 6974f0c4555 ("include/linux/string.h: add the option of fortified string.h functions")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Daniel Micay <danielmicay(a)gmail.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Martin Wilck <mwilck(a)suse.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/string.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -259,7 +259,10 @@ __FORTIFY_INLINE __kernel_size_t strlen(
{
__kernel_size_t ret;
size_t p_size = __builtin_object_size(p, 0);
- if (p_size == (size_t)-1)
+
+ /* Work around gcc excess stack consumption issue */
+ if (p_size == (size_t)-1 ||
+ (__builtin_constant_p(p[p_size - 1]) && p[p_size - 1] == '\0'))
return __builtin_strlen(p);
ret = strnlen(p, p_size);
if (p_size <= ret)
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/string.h-workaround-for-increased-stack-usage.patch
This is a note to let you know that I've just added the patch titled
crypto: salsa20 - fix blkcipher_walk API usage
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-salsa20-fix-blkcipher_walk-api-usage.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ecaaab5649781c5a0effdaf298a925063020500e Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Tue, 28 Nov 2017 20:56:59 -0800
Subject: crypto: salsa20 - fix blkcipher_walk API usage
From: Eric Biggers <ebiggers(a)google.com>
commit ecaaab5649781c5a0effdaf298a925063020500e upstream.
When asked to encrypt or decrypt 0 bytes, both the generic and x86
implementations of Salsa20 crash in blkcipher_walk_done(), either when
doing 'kfree(walk->buffer)' or 'free_page((unsigned long)walk->page)',
because walk->buffer and walk->page have not been initialized.
The bug is that Salsa20 is calling blkcipher_walk_done() even when
nothing is in 'walk.nbytes'. But blkcipher_walk_done() is only meant to
be called when a nonzero number of bytes have been provided.
The broken code is part of an optimization that tries to make only one
call to salsa20_encrypt_bytes() to process inputs that are not evenly
divisible by 64 bytes. To fix the bug, just remove this "optimization"
and use the blkcipher_walk API the same way all the other users do.
Reproducer:
#include <linux/if_alg.h>
#include <sys/socket.h>
#include <unistd.h>
int main()
{
int algfd, reqfd;
struct sockaddr_alg addr = {
.salg_type = "skcipher",
.salg_name = "salsa20",
};
char key[16] = { 0 };
algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(algfd, (void *)&addr, sizeof(addr));
reqfd = accept(algfd, 0, 0);
setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
read(reqfd, key, sizeof(key));
}
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Fixes: eb6f13eb9f81 ("[CRYPTO] salsa20_generic: Fix multi-page processing")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/salsa20_glue.c | 7 -------
crypto/salsa20_generic.c | 7 -------
2 files changed, 14 deletions(-)
--- a/arch/x86/crypto/salsa20_glue.c
+++ b/arch/x86/crypto/salsa20_glue.c
@@ -59,13 +59,6 @@ static int encrypt(struct blkcipher_desc
salsa20_ivsetup(ctx, walk.iv);
- if (likely(walk.nbytes == nbytes))
- {
- salsa20_encrypt_bytes(ctx, walk.src.virt.addr,
- walk.dst.virt.addr, nbytes);
- return blkcipher_walk_done(desc, &walk, 0);
- }
-
while (walk.nbytes >= 64) {
salsa20_encrypt_bytes(ctx, walk.src.virt.addr,
walk.dst.virt.addr,
--- a/crypto/salsa20_generic.c
+++ b/crypto/salsa20_generic.c
@@ -188,13 +188,6 @@ static int encrypt(struct blkcipher_desc
salsa20_ivsetup(ctx, walk.iv);
- if (likely(walk.nbytes == nbytes))
- {
- salsa20_encrypt_bytes(ctx, walk.dst.virt.addr,
- walk.src.virt.addr, nbytes);
- return blkcipher_walk_done(desc, &walk, 0);
- }
-
while (walk.nbytes >= 64) {
salsa20_encrypt_bytes(ctx, walk.dst.virt.addr,
walk.src.virt.addr,
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/crypto-algif_aead-fix-reference-counting-of-null-skcipher.patch
queue-4.14/crypto-salsa20-fix-blkcipher_walk-api-usage.patch
queue-4.14/crypto-rsa-fix-buffer-overread-when-stripping-leading-zeroes.patch
queue-4.14/crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
queue-4.14/crypto-af_alg-fix-null-pointer-dereference-in.patch
This is a note to let you know that I've just added the patch titled
crypto: rsa - fix buffer overread when stripping leading zeroes
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-rsa-fix-buffer-overread-when-stripping-leading-zeroes.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d2890c3778b164fde587bc16583f3a1c87233ec5 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Sun, 26 Nov 2017 23:16:49 -0800
Subject: crypto: rsa - fix buffer overread when stripping leading zeroes
From: Eric Biggers <ebiggers(a)google.com>
commit d2890c3778b164fde587bc16583f3a1c87233ec5 upstream.
In rsa_get_n(), if the buffer contained all 0's and "FIPS mode" is
enabled, we would read one byte past the end of the buffer while
scanning the leading zeroes. Fix it by checking 'n_sz' before '!*ptr'.
This bug was reachable by adding a specially crafted key of type
"asymmetric" (requires CONFIG_RSA and CONFIG_X509_CERTIFICATE_PARSER).
KASAN report:
BUG: KASAN: slab-out-of-bounds in rsa_get_n+0x19e/0x1d0 crypto/rsa_helper.c:33
Read of size 1 at addr ffff88003501a708 by task keyctl/196
CPU: 1 PID: 196 Comm: keyctl Not tainted 4.14.0-09238-g1d3b78bbc6e9 #26
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
Call Trace:
rsa_get_n+0x19e/0x1d0 crypto/rsa_helper.c:33
asn1_ber_decoder+0x82a/0x1fd0 lib/asn1_decoder.c:328
rsa_set_pub_key+0xd3/0x320 crypto/rsa.c:278
crypto_akcipher_set_pub_key ./include/crypto/akcipher.h:364 [inline]
pkcs1pad_set_pub_key+0xae/0x200 crypto/rsa-pkcs1pad.c:117
crypto_akcipher_set_pub_key ./include/crypto/akcipher.h:364 [inline]
public_key_verify_signature+0x270/0x9d0 crypto/asymmetric_keys/public_key.c:106
x509_check_for_self_signed+0x2ea/0x480 crypto/asymmetric_keys/x509_public_key.c:141
x509_cert_parse+0x46a/0x620 crypto/asymmetric_keys/x509_cert_parser.c:129
x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174
asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388
key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0x96
Allocated by task 196:
__do_kmalloc mm/slab.c:3711 [inline]
__kmalloc_track_caller+0x118/0x2e0 mm/slab.c:3726
kmemdup+0x17/0x40 mm/util.c:118
kmemdup ./include/linux/string.h:414 [inline]
x509_cert_parse+0x2cb/0x620 crypto/asymmetric_keys/x509_cert_parser.c:106
x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174
asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388
key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0x96
Fixes: 5a7de97309f5 ("crypto: rsa - return raw integers for the ASN.1 parser")
Cc: Tudor Ambarus <tudor-dan.ambarus(a)nxp.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Reviewed-by: James Morris <james.l.morris(a)oracle.com>
Reviewed-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/rsa_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/crypto/rsa_helper.c
+++ b/crypto/rsa_helper.c
@@ -30,7 +30,7 @@ int rsa_get_n(void *context, size_t hdrl
return -EINVAL;
if (fips_enabled) {
- while (!*ptr && n_sz) {
+ while (n_sz && !*ptr) {
ptr++;
n_sz--;
}
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/crypto-algif_aead-fix-reference-counting-of-null-skcipher.patch
queue-4.14/crypto-salsa20-fix-blkcipher_walk-api-usage.patch
queue-4.14/crypto-rsa-fix-buffer-overread-when-stripping-leading-zeroes.patch
queue-4.14/crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
queue-4.14/crypto-af_alg-fix-null-pointer-dereference-in.patch
This is a note to let you know that I've just added the patch titled
crypto: hmac - require that the underlying hash algorithm is unkeyed
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From af3ff8045bbf3e32f1a448542e73abb4c8ceb6f1 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Tue, 28 Nov 2017 18:01:38 -0800
Subject: crypto: hmac - require that the underlying hash algorithm is unkeyed
From: Eric Biggers <ebiggers(a)google.com>
commit af3ff8045bbf3e32f1a448542e73abb4c8ceb6f1 upstream.
Because the HMAC template didn't check that its underlying hash
algorithm is unkeyed, trying to use "hmac(hmac(sha3-512-generic))"
through AF_ALG or through KEYCTL_DH_COMPUTE resulted in the inner HMAC
being used without having been keyed, resulting in sha3_update() being
called without sha3_init(), causing a stack buffer overflow.
This is a very old bug, but it seems to have only started causing real
problems when SHA-3 support was added (requires CONFIG_CRYPTO_SHA3)
because the innermost hash's state is ->import()ed from a zeroed buffer,
and it just so happens that other hash algorithms are fine with that,
but SHA-3 is not. However, there could be arch or hardware-dependent
hash algorithms also affected; I couldn't test everything.
Fix the bug by introducing a function crypto_shash_alg_has_setkey()
which tests whether a shash algorithm is keyed. Then update the HMAC
template to require that its underlying hash algorithm is unkeyed.
Here is a reproducer:
#include <linux/if_alg.h>
#include <sys/socket.h>
int main()
{
int algfd;
struct sockaddr_alg addr = {
.salg_type = "hash",
.salg_name = "hmac(hmac(sha3-512-generic))",
};
char key[4096] = { 0 };
algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(algfd, (const struct sockaddr *)&addr, sizeof(addr));
setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
}
Here was the KASAN report from syzbot:
BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:341 [inline]
BUG: KASAN: stack-out-of-bounds in sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
Write of size 4096 at addr ffff8801cca07c40 by task syzkaller076574/3044
CPU: 1 PID: 3044 Comm: syzkaller076574 Not tainted 4.14.0-mm1+ #25
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x25b/0x340 mm/kasan/report.c:409
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
memcpy+0x37/0x50 mm/kasan/kasan.c:303
memcpy include/linux/string.h:341 [inline]
sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
crypto_shash_update+0xcb/0x220 crypto/shash.c:109
shash_finup_unaligned+0x2a/0x60 crypto/shash.c:151
crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
hmac_finup+0x182/0x330 crypto/hmac.c:152
crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
shash_digest_unaligned+0x9e/0xd0 crypto/shash.c:172
crypto_shash_digest+0xc4/0x120 crypto/shash.c:186
hmac_setkey+0x36a/0x690 crypto/hmac.c:66
crypto_shash_setkey+0xad/0x190 crypto/shash.c:64
shash_async_setkey+0x47/0x60 crypto/shash.c:207
crypto_ahash_setkey+0xaf/0x180 crypto/ahash.c:200
hash_setkey+0x40/0x90 crypto/algif_hash.c:446
alg_setkey crypto/af_alg.c:221 [inline]
alg_setsockopt+0x2a1/0x350 crypto/af_alg.c:254
SYSC_setsockopt net/socket.c:1851 [inline]
SyS_setsockopt+0x189/0x360 net/socket.c:1830
entry_SYSCALL_64_fastpath+0x1f/0x96
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/hmac.c | 6 +++++-
crypto/shash.c | 5 +++--
include/crypto/internal/hash.h | 8 ++++++++
3 files changed, 16 insertions(+), 3 deletions(-)
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -195,11 +195,15 @@ static int hmac_create(struct crypto_tem
salg = shash_attr_alg(tb[1], 0, 0);
if (IS_ERR(salg))
return PTR_ERR(salg);
+ alg = &salg->base;
+ /* The underlying hash algorithm must be unkeyed */
err = -EINVAL;
+ if (crypto_shash_alg_has_setkey(salg))
+ goto out_put_alg;
+
ds = salg->digestsize;
ss = salg->statesize;
- alg = &salg->base;
if (ds > alg->cra_blocksize ||
ss < alg->cra_blocksize)
goto out_put_alg;
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -25,11 +25,12 @@
static const struct crypto_type crypto_shash_type;
-static int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
- unsigned int keylen)
+int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
+ unsigned int keylen)
{
return -ENOSYS;
}
+EXPORT_SYMBOL_GPL(shash_no_setkey);
static int shash_setkey_unaligned(struct crypto_shash *tfm, const u8 *key,
unsigned int keylen)
--- a/include/crypto/internal/hash.h
+++ b/include/crypto/internal/hash.h
@@ -82,6 +82,14 @@ int ahash_register_instance(struct crypt
struct ahash_instance *inst);
void ahash_free_instance(struct crypto_instance *inst);
+int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
+ unsigned int keylen);
+
+static inline bool crypto_shash_alg_has_setkey(struct shash_alg *alg)
+{
+ return alg->setkey != shash_no_setkey;
+}
+
int crypto_init_ahash_spawn(struct crypto_ahash_spawn *spawn,
struct hash_alg_common *alg,
struct crypto_instance *inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/crypto-algif_aead-fix-reference-counting-of-null-skcipher.patch
queue-4.14/crypto-salsa20-fix-blkcipher_walk-api-usage.patch
queue-4.14/crypto-rsa-fix-buffer-overread-when-stripping-leading-zeroes.patch
queue-4.14/crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
queue-4.14/crypto-af_alg-fix-null-pointer-dereference-in.patch
This is a note to let you know that I've just added the patch titled
crypto: algif_aead - fix reference counting of null skcipher
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-algif_aead-fix-reference-counting-of-null-skcipher.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b32a7dc8aef1882fbf983eb354837488cc9d54dc Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Mon, 27 Nov 2017 23:23:05 -0800
Subject: crypto: algif_aead - fix reference counting of null skcipher
From: Eric Biggers <ebiggers(a)google.com>
commit b32a7dc8aef1882fbf983eb354837488cc9d54dc upstream.
In the AEAD interface for AF_ALG, the reference to the "null skcipher"
held by each tfm was being dropped in the wrong place -- when each
af_alg_ctx was freed instead of when the aead_tfm was freed. As
discovered by syzkaller, a specially crafted program could use this to
cause the null skcipher to be freed while it is still in use.
Fix it by dropping the reference in the right place.
Fixes: 72548b093ee3 ("crypto: algif_aead - copy AAD from src to dst")
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Reviewed-by: Stephan Mueller <smueller(a)chronox.de>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/algif_aead.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -503,6 +503,7 @@ static void aead_release(void *private)
struct aead_tfm *tfm = private;
crypto_free_aead(tfm->aead);
+ crypto_put_default_null_skcipher2();
kfree(tfm);
}
@@ -535,7 +536,6 @@ static void aead_sock_destruct(struct so
unsigned int ivlen = crypto_aead_ivsize(tfm);
af_alg_pull_tsgl(sk, ctx->used, NULL, 0);
- crypto_put_default_null_skcipher2();
sock_kzfree_s(sk, ctx->iv, ivlen);
sock_kfree_s(sk, ctx, ctx->len);
af_alg_release_parent(sk);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/crypto-algif_aead-fix-reference-counting-of-null-skcipher.patch
queue-4.14/crypto-salsa20-fix-blkcipher_walk-api-usage.patch
queue-4.14/crypto-rsa-fix-buffer-overread-when-stripping-leading-zeroes.patch
queue-4.14/crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
queue-4.14/crypto-af_alg-fix-null-pointer-dereference-in.patch
This is a note to let you know that I've just added the patch titled
crypto: af_alg - fix NULL pointer dereference in
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-af_alg-fix-null-pointer-dereference-in.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 887207ed9e5812ed9239b6d07185a2d35dda91db Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Tue, 28 Nov 2017 00:46:24 -0800
Subject: crypto: af_alg - fix NULL pointer dereference in
From: Eric Biggers <ebiggers(a)google.com>
commit 887207ed9e5812ed9239b6d07185a2d35dda91db upstream.
af_alg_free_areq_sgls()
If allocating the ->tsgl member of 'struct af_alg_async_req' failed,
during cleanup we dereferenced the NULL ->tsgl pointer in
af_alg_free_areq_sgls(), because ->tsgl_entries was nonzero.
Fix it by only freeing the ->tsgl list if it is non-NULL.
This affected both algif_skcipher and algif_aead.
Fixes: e870456d8e7c ("crypto: algif_skcipher - overhaul memory management")
Fixes: d887c52d6ae4 ("crypto: algif_aead - overhaul memory management")
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Reviewed-by: Stephan Mueller <smueller(a)chronox.de>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/af_alg.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -699,14 +699,15 @@ void af_alg_free_areq_sgls(struct af_alg
}
tsgl = areq->tsgl;
- for_each_sg(tsgl, sg, areq->tsgl_entries, i) {
- if (!sg_page(sg))
- continue;
- put_page(sg_page(sg));
- }
+ if (tsgl) {
+ for_each_sg(tsgl, sg, areq->tsgl_entries, i) {
+ if (!sg_page(sg))
+ continue;
+ put_page(sg_page(sg));
+ }
- if (areq->tsgl && areq->tsgl_entries)
sock_kfree_s(sk, tsgl, areq->tsgl_entries * sizeof(*tsgl));
+ }
}
EXPORT_SYMBOL_GPL(af_alg_free_areq_sgls);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/crypto-algif_aead-fix-reference-counting-of-null-skcipher.patch
queue-4.14/crypto-salsa20-fix-blkcipher_walk-api-usage.patch
queue-4.14/crypto-rsa-fix-buffer-overread-when-stripping-leading-zeroes.patch
queue-4.14/crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
queue-4.14/crypto-af_alg-fix-null-pointer-dereference-in.patch
This is a note to let you know that I've just added the patch titled
cifs: fix NULL deref in SMB2_read
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
cifs-fix-null-deref-in-smb2_read.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a821df3f1af72aa6a0d573eea94a7dd2613e9f4e Mon Sep 17 00:00:00 2001
From: Ronnie Sahlberg <lsahlber(a)redhat.com>
Date: Tue, 21 Nov 2017 09:36:33 +1100
Subject: cifs: fix NULL deref in SMB2_read
From: Ronnie Sahlberg <lsahlber(a)redhat.com>
commit a821df3f1af72aa6a0d573eea94a7dd2613e9f4e upstream.
Signed-off-by: Ronnie Sahlberg <lsahlber(a)redhat.com>
Reviewed-by: Pavel Shilovsky <pshilov(a)microsoft.com>
Signed-off-by: Steve French <smfrench(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/cifs/smb2pdu.c | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -2678,27 +2678,27 @@ SMB2_read(const unsigned int xid, struct
cifs_small_buf_release(req);
rsp = (struct smb2_read_rsp *)rsp_iov.iov_base;
- shdr = get_sync_hdr(rsp);
- if (shdr->Status == STATUS_END_OF_FILE) {
+ if (rc) {
+ if (rc != -ENODATA) {
+ cifs_stats_fail_inc(io_parms->tcon, SMB2_READ_HE);
+ cifs_dbg(VFS, "Send error in read = %d\n", rc);
+ }
free_rsp_buf(resp_buftype, rsp_iov.iov_base);
- return 0;
+ return rc == -ENODATA ? 0 : rc;
}
- if (rc) {
- cifs_stats_fail_inc(io_parms->tcon, SMB2_READ_HE);
- cifs_dbg(VFS, "Send error in read = %d\n", rc);
- } else {
- *nbytes = le32_to_cpu(rsp->DataLength);
- if ((*nbytes > CIFS_MAX_MSGSIZE) ||
- (*nbytes > io_parms->length)) {
- cifs_dbg(FYI, "bad length %d for count %d\n",
- *nbytes, io_parms->length);
- rc = -EIO;
- *nbytes = 0;
- }
+ *nbytes = le32_to_cpu(rsp->DataLength);
+ if ((*nbytes > CIFS_MAX_MSGSIZE) ||
+ (*nbytes > io_parms->length)) {
+ cifs_dbg(FYI, "bad length %d for count %d\n",
+ *nbytes, io_parms->length);
+ rc = -EIO;
+ *nbytes = 0;
}
+ shdr = get_sync_hdr(rsp);
+
if (*buf) {
memcpy(*buf, (char *)shdr + rsp->DataOffset, *nbytes);
free_rsp_buf(resp_buftype, rsp_iov.iov_base);
Patches currently in stable-queue which might be from lsahlber(a)redhat.com are
queue-4.14/cifs-fix-null-deref-in-smb2_read.patch
This is a note to let you know that I've just added the patch titled
crypto: salsa20 - fix blkcipher_walk API usage
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-salsa20-fix-blkcipher_walk-api-usage.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ecaaab5649781c5a0effdaf298a925063020500e Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Tue, 28 Nov 2017 20:56:59 -0800
Subject: crypto: salsa20 - fix blkcipher_walk API usage
From: Eric Biggers <ebiggers(a)google.com>
commit ecaaab5649781c5a0effdaf298a925063020500e upstream.
When asked to encrypt or decrypt 0 bytes, both the generic and x86
implementations of Salsa20 crash in blkcipher_walk_done(), either when
doing 'kfree(walk->buffer)' or 'free_page((unsigned long)walk->page)',
because walk->buffer and walk->page have not been initialized.
The bug is that Salsa20 is calling blkcipher_walk_done() even when
nothing is in 'walk.nbytes'. But blkcipher_walk_done() is only meant to
be called when a nonzero number of bytes have been provided.
The broken code is part of an optimization that tries to make only one
call to salsa20_encrypt_bytes() to process inputs that are not evenly
divisible by 64 bytes. To fix the bug, just remove this "optimization"
and use the blkcipher_walk API the same way all the other users do.
Reproducer:
#include <linux/if_alg.h>
#include <sys/socket.h>
#include <unistd.h>
int main()
{
int algfd, reqfd;
struct sockaddr_alg addr = {
.salg_type = "skcipher",
.salg_name = "salsa20",
};
char key[16] = { 0 };
algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(algfd, (void *)&addr, sizeof(addr));
reqfd = accept(algfd, 0, 0);
setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
read(reqfd, key, sizeof(key));
}
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Fixes: eb6f13eb9f81 ("[CRYPTO] salsa20_generic: Fix multi-page processing")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/salsa20_glue.c | 7 -------
crypto/salsa20_generic.c | 7 -------
2 files changed, 14 deletions(-)
--- a/arch/x86/crypto/salsa20_glue.c
+++ b/arch/x86/crypto/salsa20_glue.c
@@ -59,13 +59,6 @@ static int encrypt(struct blkcipher_desc
salsa20_ivsetup(ctx, walk.iv);
- if (likely(walk.nbytes == nbytes))
- {
- salsa20_encrypt_bytes(ctx, walk.src.virt.addr,
- walk.dst.virt.addr, nbytes);
- return blkcipher_walk_done(desc, &walk, 0);
- }
-
while (walk.nbytes >= 64) {
salsa20_encrypt_bytes(ctx, walk.src.virt.addr,
walk.dst.virt.addr,
--- a/crypto/salsa20_generic.c
+++ b/crypto/salsa20_generic.c
@@ -188,13 +188,6 @@ static int encrypt(struct blkcipher_desc
salsa20_ivsetup(ctx, walk.iv);
- if (likely(walk.nbytes == nbytes))
- {
- salsa20_encrypt_bytes(ctx, walk.dst.virt.addr,
- walk.src.virt.addr, nbytes);
- return blkcipher_walk_done(desc, &walk, 0);
- }
-
while (walk.nbytes >= 64) {
salsa20_encrypt_bytes(ctx, walk.dst.virt.addr,
walk.src.virt.addr,
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-3.18/crypto-salsa20-fix-blkcipher_walk-api-usage.patch
queue-3.18/crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
This is a note to let you know that I've just added the patch titled
crypto: hmac - require that the underlying hash algorithm is unkeyed
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From af3ff8045bbf3e32f1a448542e73abb4c8ceb6f1 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Tue, 28 Nov 2017 18:01:38 -0800
Subject: crypto: hmac - require that the underlying hash algorithm is unkeyed
From: Eric Biggers <ebiggers(a)google.com>
commit af3ff8045bbf3e32f1a448542e73abb4c8ceb6f1 upstream.
Because the HMAC template didn't check that its underlying hash
algorithm is unkeyed, trying to use "hmac(hmac(sha3-512-generic))"
through AF_ALG or through KEYCTL_DH_COMPUTE resulted in the inner HMAC
being used without having been keyed, resulting in sha3_update() being
called without sha3_init(), causing a stack buffer overflow.
This is a very old bug, but it seems to have only started causing real
problems when SHA-3 support was added (requires CONFIG_CRYPTO_SHA3)
because the innermost hash's state is ->import()ed from a zeroed buffer,
and it just so happens that other hash algorithms are fine with that,
but SHA-3 is not. However, there could be arch or hardware-dependent
hash algorithms also affected; I couldn't test everything.
Fix the bug by introducing a function crypto_shash_alg_has_setkey()
which tests whether a shash algorithm is keyed. Then update the HMAC
template to require that its underlying hash algorithm is unkeyed.
Here is a reproducer:
#include <linux/if_alg.h>
#include <sys/socket.h>
int main()
{
int algfd;
struct sockaddr_alg addr = {
.salg_type = "hash",
.salg_name = "hmac(hmac(sha3-512-generic))",
};
char key[4096] = { 0 };
algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(algfd, (const struct sockaddr *)&addr, sizeof(addr));
setsockopt(algfd, SOL_ALG, ALG_SET_KEY, key, sizeof(key));
}
Here was the KASAN report from syzbot:
BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:341 [inline]
BUG: KASAN: stack-out-of-bounds in sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
Write of size 4096 at addr ffff8801cca07c40 by task syzkaller076574/3044
CPU: 1 PID: 3044 Comm: syzkaller076574 Not tainted 4.14.0-mm1+ #25
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x25b/0x340 mm/kasan/report.c:409
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
memcpy+0x37/0x50 mm/kasan/kasan.c:303
memcpy include/linux/string.h:341 [inline]
sha3_update+0xdf/0x2e0 crypto/sha3_generic.c:161
crypto_shash_update+0xcb/0x220 crypto/shash.c:109
shash_finup_unaligned+0x2a/0x60 crypto/shash.c:151
crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
hmac_finup+0x182/0x330 crypto/hmac.c:152
crypto_shash_finup+0xc4/0x120 crypto/shash.c:165
shash_digest_unaligned+0x9e/0xd0 crypto/shash.c:172
crypto_shash_digest+0xc4/0x120 crypto/shash.c:186
hmac_setkey+0x36a/0x690 crypto/hmac.c:66
crypto_shash_setkey+0xad/0x190 crypto/shash.c:64
shash_async_setkey+0x47/0x60 crypto/shash.c:207
crypto_ahash_setkey+0xaf/0x180 crypto/ahash.c:200
hash_setkey+0x40/0x90 crypto/algif_hash.c:446
alg_setkey crypto/af_alg.c:221 [inline]
alg_setsockopt+0x2a1/0x350 crypto/af_alg.c:254
SYSC_setsockopt net/socket.c:1851 [inline]
SyS_setsockopt+0x189/0x360 net/socket.c:1830
entry_SYSCALL_64_fastpath+0x1f/0x96
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/hmac.c | 6 +++++-
crypto/shash.c | 5 +++--
include/crypto/internal/hash.h | 8 ++++++++
3 files changed, 16 insertions(+), 3 deletions(-)
--- a/crypto/hmac.c
+++ b/crypto/hmac.c
@@ -194,11 +194,15 @@ static int hmac_create(struct crypto_tem
salg = shash_attr_alg(tb[1], 0, 0);
if (IS_ERR(salg))
return PTR_ERR(salg);
+ alg = &salg->base;
+ /* The underlying hash algorithm must be unkeyed */
err = -EINVAL;
+ if (crypto_shash_alg_has_setkey(salg))
+ goto out_put_alg;
+
ds = salg->digestsize;
ss = salg->statesize;
- alg = &salg->base;
if (ds > alg->cra_blocksize ||
ss < alg->cra_blocksize)
goto out_put_alg;
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -24,11 +24,12 @@
static const struct crypto_type crypto_shash_type;
-static int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
- unsigned int keylen)
+int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
+ unsigned int keylen)
{
return -ENOSYS;
}
+EXPORT_SYMBOL_GPL(shash_no_setkey);
static int shash_setkey_unaligned(struct crypto_shash *tfm, const u8 *key,
unsigned int keylen)
--- a/include/crypto/internal/hash.h
+++ b/include/crypto/internal/hash.h
@@ -83,6 +83,14 @@ int ahash_register_instance(struct crypt
struct ahash_instance *inst);
void ahash_free_instance(struct crypto_instance *inst);
+int shash_no_setkey(struct crypto_shash *tfm, const u8 *key,
+ unsigned int keylen);
+
+static inline bool crypto_shash_alg_has_setkey(struct shash_alg *alg)
+{
+ return alg->setkey != shash_no_setkey;
+}
+
int crypto_init_ahash_spawn(struct crypto_ahash_spawn *spawn,
struct hash_alg_common *alg,
struct crypto_instance *inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-3.18/crypto-salsa20-fix-blkcipher_walk-api-usage.patch
queue-3.18/crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch
From: Marc Zyngier <marc.zyngier(a)arm.com>
When we unmap the HYP memory, we try to be clever and unmap one
PGD at a time. If we start with a non-PGD aligned address and try
to unmap a whole PGD, things go horribly wrong in unmap_hyp_range
(addr and end can never match, and it all goes really badly as we
keep incrementing pgd and parse random memory as page tables...).
The obvious fix is to let unmap_hyp_range do what it does best,
which is to iterate over a range.
The size of the linear mapping, which begins at PAGE_OFFSET, can be
easily calculated by subtracting PAGE_OFFSET form high_memory, because
high_memory is defined as the linear map address of the last byte of
DRAM, plus one.
The size of the vmalloc region is given trivially by VMALLOC_END -
VMALLOC_START.
Cc: stable(a)vger.kernel.org
Reported-by: Andre Przywara <andre.przywara(a)arm.com>
Tested-by: Andre Przywara <andre.przywara(a)arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
---
virt/kvm/arm/mmu.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index b36945d49986..b4b69c2d1012 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -509,8 +509,6 @@ static void unmap_hyp_range(pgd_t *pgdp, phys_addr_t start, u64 size)
*/
void free_hyp_pgds(void)
{
- unsigned long addr;
-
mutex_lock(&kvm_hyp_pgd_mutex);
if (boot_hyp_pgd) {
@@ -521,10 +519,10 @@ void free_hyp_pgds(void)
if (hyp_pgd) {
unmap_hyp_range(hyp_pgd, hyp_idmap_start, PAGE_SIZE);
- for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
- unmap_hyp_range(hyp_pgd, kern_hyp_va(addr), PGDIR_SIZE);
- for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
- unmap_hyp_range(hyp_pgd, kern_hyp_va(addr), PGDIR_SIZE);
+ unmap_hyp_range(hyp_pgd, kern_hyp_va(PAGE_OFFSET),
+ (uintptr_t)high_memory - PAGE_OFFSET);
+ unmap_hyp_range(hyp_pgd, kern_hyp_va(VMALLOC_START),
+ VMALLOC_END - VMALLOC_START);
free_pages((unsigned long)hyp_pgd, hyp_pgd_order);
hyp_pgd = NULL;
--
2.14.2
From: Julien Thierry <julien.thierry(a)arm.com>
When VHE is not present, KVM needs to save and restores PMSCR_EL1 when
possible. If SPE is used by the host, value of PMSCR_EL1 cannot be saved
for the guest.
If the host starts using SPE between two save+restore on the same vcpu,
restore will write the value of PMSCR_EL1 read during the first save.
Make sure __debug_save_spe_nvhe clears the value of the saved PMSCR_EL1
when the guest cannot use SPE.
Signed-off-by: Julien Thierry <julien.thierry(a)arm.com>
Cc: Christoffer Dall <christoffer.dall(a)linaro.org>
Cc: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: <stable(a)vger.kernel.org>
Reviewed-by: Will Deacon <will.deacon(a)arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
---
arch/arm64/kvm/hyp/debug-sr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/kvm/hyp/debug-sr.c b/arch/arm64/kvm/hyp/debug-sr.c
index 321c9c05dd9e..f4363d40e2cd 100644
--- a/arch/arm64/kvm/hyp/debug-sr.c
+++ b/arch/arm64/kvm/hyp/debug-sr.c
@@ -74,6 +74,9 @@ static void __hyp_text __debug_save_spe_nvhe(u64 *pmscr_el1)
{
u64 reg;
+ /* Clear pmscr in case of early return */
+ *pmscr_el1 = 0;
+
/* SPE present on this CPU? */
if (!cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),
ID_AA64DFR0_PMSVER_SHIFT))
--
2.14.2
This is a note to let you know that I've just added the patch titled
mfd: fsl-imx25: Clean up irq settings during removal
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mfd-fsl-imx25-clean-up-irq-settings-during-removal.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 18f77393796848e68909e65d692c1d1436f06e06 Mon Sep 17 00:00:00 2001
From: Martin Kaiser <martin(a)kaiser.cx>
Date: Tue, 17 Oct 2017 22:53:08 +0200
Subject: mfd: fsl-imx25: Clean up irq settings during removal
From: Martin Kaiser <martin(a)kaiser.cx>
commit 18f77393796848e68909e65d692c1d1436f06e06 upstream.
When fsl-imx25-tsadc is compiled as a module, loading, unloading and
reloading the module will lead to a crash.
Unable to handle kernel paging request at virtual address bf005430
[<c004df6c>] (irq_find_matching_fwspec)
from [<c028d5ec>] (of_irq_get+0x58/0x74)
[<c028d594>] (of_irq_get)
from [<c01ff970>] (platform_get_irq+0x48/0xc8)
[<c01ff928>] (platform_get_irq)
from [<bf00e33c>] (mx25_tsadc_probe+0x220/0x2f4 [fsl_imx25_tsadc])
irq_find_matching_fwspec() loops over all registered irq domains. The
irq domain is still registered from last time the module was loaded but
the pointer to its operations is invalid after the module was unloaded.
Add a removal function which clears the irq handler and removes the irq
domain. With this cleanup in place, it's possible to unload and reload
the module.
Signed-off-by: Martin Kaiser <martin(a)kaiser.cx>
Reviewed-by: Lucas Stach <l.stach(a)pengutronix.de>
Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mfd/fsl-imx25-tsadc.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/drivers/mfd/fsl-imx25-tsadc.c
+++ b/drivers/mfd/fsl-imx25-tsadc.c
@@ -183,6 +183,19 @@ static int mx25_tsadc_probe(struct platf
return 0;
}
+static int mx25_tsadc_remove(struct platform_device *pdev)
+{
+ struct mx25_tsadc *tsadc = platform_get_drvdata(pdev);
+ int irq = platform_get_irq(pdev, 0);
+
+ if (irq) {
+ irq_set_chained_handler_and_data(irq, NULL, NULL);
+ irq_domain_remove(tsadc->domain);
+ }
+
+ return 0;
+}
+
static const struct of_device_id mx25_tsadc_ids[] = {
{ .compatible = "fsl,imx25-tsadc" },
{ /* Sentinel */ }
@@ -194,6 +207,7 @@ static struct platform_driver mx25_tsadc
.of_match_table = of_match_ptr(mx25_tsadc_ids),
},
.probe = mx25_tsadc_probe,
+ .remove = mx25_tsadc_remove,
};
module_platform_driver(mx25_tsadc_driver);
Patches currently in stable-queue which might be from martin(a)kaiser.cx are
queue-4.9/mfd-fsl-imx25-clean-up-irq-settings-during-removal.patch
This is a note to let you know that I've just added the patch titled
mfd: fsl-imx25: Clean up irq settings during removal
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mfd-fsl-imx25-clean-up-irq-settings-during-removal.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 18f77393796848e68909e65d692c1d1436f06e06 Mon Sep 17 00:00:00 2001
From: Martin Kaiser <martin(a)kaiser.cx>
Date: Tue, 17 Oct 2017 22:53:08 +0200
Subject: mfd: fsl-imx25: Clean up irq settings during removal
From: Martin Kaiser <martin(a)kaiser.cx>
commit 18f77393796848e68909e65d692c1d1436f06e06 upstream.
When fsl-imx25-tsadc is compiled as a module, loading, unloading and
reloading the module will lead to a crash.
Unable to handle kernel paging request at virtual address bf005430
[<c004df6c>] (irq_find_matching_fwspec)
from [<c028d5ec>] (of_irq_get+0x58/0x74)
[<c028d594>] (of_irq_get)
from [<c01ff970>] (platform_get_irq+0x48/0xc8)
[<c01ff928>] (platform_get_irq)
from [<bf00e33c>] (mx25_tsadc_probe+0x220/0x2f4 [fsl_imx25_tsadc])
irq_find_matching_fwspec() loops over all registered irq domains. The
irq domain is still registered from last time the module was loaded but
the pointer to its operations is invalid after the module was unloaded.
Add a removal function which clears the irq handler and removes the irq
domain. With this cleanup in place, it's possible to unload and reload
the module.
Signed-off-by: Martin Kaiser <martin(a)kaiser.cx>
Reviewed-by: Lucas Stach <l.stach(a)pengutronix.de>
Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mfd/fsl-imx25-tsadc.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/drivers/mfd/fsl-imx25-tsadc.c
+++ b/drivers/mfd/fsl-imx25-tsadc.c
@@ -180,6 +180,19 @@ static int mx25_tsadc_probe(struct platf
return devm_of_platform_populate(dev);
}
+static int mx25_tsadc_remove(struct platform_device *pdev)
+{
+ struct mx25_tsadc *tsadc = platform_get_drvdata(pdev);
+ int irq = platform_get_irq(pdev, 0);
+
+ if (irq) {
+ irq_set_chained_handler_and_data(irq, NULL, NULL);
+ irq_domain_remove(tsadc->domain);
+ }
+
+ return 0;
+}
+
static const struct of_device_id mx25_tsadc_ids[] = {
{ .compatible = "fsl,imx25-tsadc" },
{ /* Sentinel */ }
@@ -192,6 +205,7 @@ static struct platform_driver mx25_tsadc
.of_match_table = of_match_ptr(mx25_tsadc_ids),
},
.probe = mx25_tsadc_probe,
+ .remove = mx25_tsadc_remove,
};
module_platform_driver(mx25_tsadc_driver);
Patches currently in stable-queue which might be from martin(a)kaiser.cx are
queue-4.14/mfd-fsl-imx25-clean-up-irq-settings-during-removal.patch
Hi Marek,
On Wed, 11 Oct 2017 23:34:33 +0200
Marek Vasut <marek.vasut(a)gmail.com> wrote:
> On 10/11/2017 03:54 PM, Arnd Bergmann wrote:
> > The map_word_() functions, dating back to linux-2.6.8, try to perform
> > bitwise operations on a 'map_word' structure. This may have worked
> > with compilers that were current then (gcc-3.4 or earlier), but end
> > up being rather inefficient on any version I could try now (gcc-4.4 or
> > higher). Specifically we hit a problem analyzed in gcc PR81715 where we
> > fail to reuse the stack space for local variables.
> >
> > This can be seen immediately in the stack consumption for
> > cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN)
> > can be up to 2200 bytes. Changing the inline functions into macros brings
> > this down to 1280 bytes. Without KASAN, the same problem exists, but
> > the stack consumption is lower to start with, my patch shrinks it from
> > 920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around
> > 1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word
> > structures for each call to one of these helpers.
> >
> > With the latest gcc-8 snapshot, the problem is fixed in upstream gcc,
> > but nobody uses that yet, so we should still work around it in mainline
> > kernels and probably backport the workaround to stable kernels as well.
> > We had a couple of other functions that suffered from the same gcc bug,
> > and all of those had a simpler workaround involving dummy variables
> > in the inline function. Unfortunately that did not work here, the
> > macro hack was the best I could come up with.
> >
> > It would also be helpful to have someone to a little performance testing
> > on the patch, to see how much it helps in terms of CPU utilitzation.
> >
> > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
> > Cc: stable(a)vger.kernel.org
> > Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
>
> Don't you lose type-checking with this conversion to macros ?
>
Yes, we loose strict type checking, but if you look at the code, you'll
see that the macros do (valN).x[i], so, if valN is not a struct or
a union containing a field named x, the compiler will complain. That
should save us from devs passing random arguments to those macros.
Anyway, this code is not seeing a lot of changes lately, so I wouldn't
be so worried by the lack of strict type-checking implied by this
transition to macros.
Regards,
Boris
On Sat, Dec 16, 2017 at 2:51 AM, Brian King <brking(a)linux.vnet.ibm.com> wrote:
> This fixes a hang issue seen when changing the MTU size from 1500 MTU
> to 9000 MTU on both 5717 and 5719 chips. In discussion with Broadcom,
> they've indicated that these chipsets have the same phy as the 57766
> chipset, so the same workarounds apply. This has been tested by IBM
> on both Power 8 and Power 9 systems as well as by Broadcom on x86
> hardware and has been confirmed to resolve the hang issue.
Thanks for the patch. We need more time to review.
>
> Cc: stable <stable(a)vger.kernel.org>
> Signed-off-by: Brian King <brking(a)linux.vnet.ibm.com>
> ---
> drivers/net/ethernet/broadcom/tg3.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index de51c21..d09c5a9 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -14225,7 +14225,9 @@ static int tg3_change_mtu(struct net_device *dev, int new_mtu)
> /* Reset PHY, otherwise the read DMA engine will be in a mode that
> * breaks all requests to 256 bytes.
> */
> - if (tg3_asic_rev(tp) == ASIC_REV_57766)
> + if (tg3_asic_rev(tp) == ASIC_REV_57766 ||
> + tg3_asic_rev(tp) == ASIC_REV_5717 ||
> + tg3_asic_rev(tp) == ASIC_REV_5719)
> reset_phy = true;
>
> err = tg3_restart_hw(tp, reset_phy);
> --
> 1.8.3.1
>
syzbot reported we have a use-after-free when mqueue_evict_inode()
is called on __cleanup_mnt() path, where the ipc ns is already
freed by the previous exit_task_namespaces(). We can just move
it after after exit_task_work() to avoid this use-after-free.
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Cc: Ingo Molnar <mingo(a)kernel.org>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: stable(a)vger.kernel.org
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
---
kernel/exit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/exit.c b/kernel/exit.c
index 6b4298a41167..909e43c45158 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -861,8 +861,8 @@ void __noreturn do_exit(long code)
exit_fs(tsk);
if (group_dead)
disassociate_ctty(1);
- exit_task_namespaces(tsk);
exit_task_work(tsk);
+ exit_task_namespaces(tsk);
exit_thread(tsk);
/*
--
2.13.0
Tree/Branch: v4.1.48
Git describe: v4.1.48
Commit: 0199619b21 Linux 4.1.48
Build Time: 73 min 45 sec
Passed: 9 / 9 (100.00 %)
Failed: 0 / 9 ( 0.00 %)
Errors: 0
Warnings: 35
Section Mismatches: 1
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
24 warnings 3 mismatches : arm64-allmodconfig
2 warnings 0 mismatches : arm-multi_v7_defconfig
23 warnings 0 mismatches : arm-allmodconfig
2 warnings 0 mismatches : arm-multi_v5_defconfig
6 warnings 0 mismatches : x86_64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 35
8 ../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
5 ../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
2 ../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../include/linux/ftrace.h:671:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
2 ../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
2 ../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
2 ../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
2 ../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
2 ../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
2 ../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
1 ../include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined
1 ../drivers/xen/swiotlb-xen.c:704:27: warning: passing argument 6 of '__generic_dma_ops(dev)->mmap' makes pointer from integer without a cast [-Wint-conversion]
1 ../drivers/usb/renesas_usbhs/common.c:492:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1 ../drivers/rtc/rtc-pcf8563.c:444:5: warning: 'alm_pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/rtc/rtc-armada38x.c:91:22: warning: unused variable 'flags' [-Wunused-variable]
1 ../drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/net/ethernet/dec/tulip/winbond-840.c:910:2: warning: #warning Processor architecture undefined [-Wcpp]
1 ../drivers/net/ethernet/dec/tulip/tulip_core.c:101:2: warning: #warning Processor architecture undefined! [-Wcpp]
1 ../drivers/mmc/host/sh_mmcif.c:402:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1 ../drivers/mmc/host/sh_mmcif.c:401:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1 ../drivers/media/platform/coda/./trace.h:12:0: warning: "TRACE_SYSTEM_STRING" redefined
1 ../drivers/iommu/intel-iommu.c:3798:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
1 ../drivers/iommu/dmar.c:1849:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
1 ../drivers/infiniband/hw/qib/qib_qp.c:44:0: warning: "BITS_PER_PAGE" redefined
1 ../drivers/infiniband/hw/cxgb4/mem.c:147:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1 ../drivers/hid/hid-input.c:1163:67: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
1 ../drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c:975:1: warning: the frame size of 1192 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 ../drivers/gpio/gpio-74xx-mmio.c:132:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1 ../arch/x86/include/asm/msr.h:209:23: warning: right shift count >= width of type [-Wshift-count-overflow]
1 ../arch/arm64/xen/../../arm/xen/mm.c:183:10: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
1 ../arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 ../arch/arm/include/asm/cmpxchg.h:205:3: warning: value computed is not used [-Wunused-value]
Section Mismatch Summary: 1
3 WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x168): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 24 warnings, 3 section mismatches
Warnings:
../arch/arm64/xen/../../arm/xen/mm.c:183:10: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/gpio/gpio-74xx-mmio.c:132:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
../drivers/infiniband/hw/qib/qib_qp.c:44:0: warning: "BITS_PER_PAGE" redefined
../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/mmc/host/sh_mmcif.c:401:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
../drivers/mmc/host/sh_mmcif.c:402:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/net/ethernet/dec/tulip/winbond-840.c:910:2: warning: #warning Processor architecture undefined [-Wcpp]
../drivers/net/ethernet/dec/tulip/tulip_core.c:101:2: warning: #warning Processor architecture undefined! [-Wcpp]
../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../drivers/usb/renesas_usbhs/common.c:492:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
../drivers/xen/swiotlb-xen.c:704:27: warning: passing argument 6 of '__generic_dma_ops(dev)->mmap' makes pointer from integer without a cast [-Wint-conversion]
Section Mismatches:
WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x168): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x168): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x168): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm-allmodconfig : PASS, 0 errors, 23 warnings, 0 section mismatches
Warnings:
../arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=]
../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../arch/arm/include/asm/cmpxchg.h:205:3: warning: value computed is not used [-Wunused-value]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c:975:1: warning: the frame size of 1192 bytes is larger than 1024 bytes [-Wframe-larger-than=]
../drivers/infiniband/hw/cxgb4/mem.c:147:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined
../drivers/media/platform/coda/./trace.h:12:0: warning: "TRACE_SYSTEM_STRING" redefined
../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/rtc/rtc-armada38x.c:91:22: warning: unused variable 'flags' [-Wunused-variable]
../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
-------------------------------------------------------------------------------
arm-multi_v5_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/rtc/rtc-pcf8563.c:444:5: warning: 'alm_pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-defconfig : PASS, 0 errors, 6 warnings, 0 section mismatches
Warnings:
../include/linux/ftrace.h:671:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
../include/linux/ftrace.h:671:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
../arch/x86/include/asm/msr.h:209:23: warning: right shift count >= width of type [-Wshift-count-overflow]
../drivers/hid/hid-input.c:1163:67: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/iommu/dmar.c:1849:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
../drivers/iommu/intel-iommu.c:3798:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
x86_64-allnoconfig
arm64-allnoconfig
arm-allnoconfig
arm64-defconfig
This is the start of the stable review cycle for the 4.14.7 release.
There are 52 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 Sun Dec 17 09:22:47 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.14.7-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.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.14.7-rc1
Mauro Carvalho Chehab <mchehab(a)kernel.org>
dvb_frontend: don't use-after-free the frontend struct
Daniel Scheller <d.scheller(a)gmx.net>
media: dvb-core: always call invoke_release() in fe_free()
Reinette Chatre <reinette.chatre(a)intel.com>
x86/intel_rdt: Fix potential deadlock during resctrl unmount
Leon Romanovsky <leon(a)kernel.org>
RDMA/cxgb4: Annotate r2 and stag as __be32
Zdenek Kabelac <zkabelac(a)redhat.com>
md: free unused memory after bitmap resize
Heinz Mauelshagen <heinzm(a)redhat.com>
dm raid: fix panic when attempting to force a raid to sync
Paul Moore <paul(a)paul-moore.com>
audit: ensure that 'audit=1' actually enables audit for PID 1
Steve Grubb <sgrubb(a)redhat.com>
audit: Allow auditd to set pid to 0 to end auditing
Israel Rukshin <israelr(a)mellanox.com>
nvmet-rdma: update queue list during ib_device removal
Bart Van Assche <bart.vanassche(a)wdc.com>
blk-mq: Avoid that request queue removal can trigger list corruption
Hongxu Jia <hongxu.jia(a)windriver.com>
ide: ide-atapi: fix compile error with defining macro DEBUG
Keefe Liu <liuqifa(a)huawei.com>
ipvlan: fix ipv6 outbound device
Vaidyanathan Srinivasan <svaidy(a)linux.vnet.ibm.com>
powerpc/powernv/idle: Round up latency and residency values
Masahiro Yamada <yamada.masahiro(a)socionext.com>
kbuild: do not call cc-option before KBUILD_CFLAGS initialization
Marc Zyngier <marc.zyngier(a)arm.com>
KVM: arm/arm64: vgic-its: Preserve the revious read from the pending table
Al Viro <viro(a)ZenIV.linux.org.uk>
fix kcm_clone()
Jeff Layton <jlayton(a)redhat.com>
fcntl: don't cap l_start and l_end values for F_GETLK64 in compat syscall
Vincent Pelletier <plr.vincent(a)gmail.com>
usb: gadget: ffs: Forbid usb_ep_alloc_request from sleeping
Masamitsu Yamazaki <m-yamazaki(a)ah.jp.nec.com>
ipmi: Stop timers before cleaning up the module
Xin Long <lucien.xin(a)gmail.com>
sctp: use right member as the param of list_for_each_entry
Jakub Kicinski <jakub.kicinski(a)netronome.com>
cls_bpf: don't decrement net's refcount when offload fails
Gustavo A. R. Silva <garsilva(a)embeddedor.com>
net: openvswitch: datapath: fix data type in queue_gso_packets
Willem de Bruijn <willemb(a)google.com>
net: accept UFO datagrams from tuntap and packet
Xin Long <lucien.xin(a)gmail.com>
tun: fix rcu_read_lock imbalance in tun_build_skb
David Ahern <dsahern(a)gmail.com>
net: ipv6: Fixup device for anycast routes during copy
Wei Xu <wexu(a)redhat.com>
tun: free skb in early errors
Neal Cardwell <ncardwell(a)google.com>
tcp: when scheduling TLP, time of RTO should account for current ACK
Wei Xu <wexu(a)redhat.com>
tap: free skb if flags error
Jiri Pirko <jiri(a)mellanox.com>
net: sched: cbq: create block for q->link.block
Eric Dumazet <edumazet(a)google.com>
tcp: use current time in tcp_rcv_space_adjust()
Tommi Rantala <tommi.t.rantala(a)nokia.com>
tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()
David Ahern <dsahern(a)gmail.com>
tcp: use IPCB instead of TCP_SKB_CB in inet_exact_dif_match()
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: fix GSO throughput regression
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: fix thinko in IPv4 multicast address tracking
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: build max size GSO skbs on L2 devices
Eric Dumazet <edumazet(a)google.com>
tcp/dccp: block bh before arming time_wait timer
Lars Persson <lars.persson(a)axis.com>
stmmac: reset last TSO segment size after device open
Eric Dumazet <edumazet(a)google.com>
net: remove hlist_nulls_add_tail_rcu()
Bjørn Mork <bjorn(a)mork.no>
usbnet: fix alignment for frames with no ethernet header
Eric Dumazet <edumazet(a)google.com>
tcp: remove buggy call to tcp_v6_restore_cb()
Eric Dumazet <edumazet(a)google.com>
net/packet: fix a race in packet_bind() and packet_notifier()
Mike Maloney <maloney(a)google.com>
packet: fix crash in fanout_demux_rollover()
Eric Dumazet <edumazet(a)google.com>
tcp: add tcp_v4_fill_cb()/tcp_v4_restore_cb()
Hangbin Liu <liuhangbin(a)gmail.com>
sit: update frag_off info
Håkon Bugge <Haakon.Bugge(a)oracle.com>
rds: Fix NULL pointer dereference in __rds_rdma_map
Wei Xu <wexu(a)redhat.com>
vhost: fix skb leak in handle_rx()
Jon Maloy <jon.maloy(a)ericsson.com>
tipc: fix memory leak in tipc_accept_from_sock()
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: fix early exit from error path
Tobias Jakobi <tjakobi(a)math.uni-bielefeld.de>
net: realtek: r8169: implement set_link_ksettings()
Florian Westphal <fw(a)strlen.de>
net: thunderx: Fix TCP/UDP checksum offload for IPv4 pkts
Sunil Goutham <sgoutham(a)cavium.com>
net: thunderx: Fix TCP/UDP checksum offload for IPv6 pkts
Sebastian Sjoholm <ssjoholm(a)mac.com>
net: qmi_wwan: add Quectel BG96 2c7c:0296
-------------
Diffstat:
Makefile | 25 ++++---
arch/arm64/include/asm/compat.h | 1 -
arch/mips/include/asm/compat.h | 1 -
arch/parisc/include/asm/compat.h | 1 -
arch/powerpc/include/asm/compat.h | 1 -
arch/s390/include/asm/compat.h | 1 -
arch/sparc/include/asm/compat.h | 1 -
arch/tile/include/asm/compat.h | 1 -
arch/x86/include/asm/compat.h | 1 -
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 10 +--
block/blk-core.c | 1 +
drivers/char/ipmi/ipmi_si_intf.c | 44 +++++------
drivers/cpuidle/cpuidle-powernv.c | 4 +-
drivers/ide/ide-atapi.c | 6 +-
drivers/infiniband/hw/cxgb4/t4fw_ri_api.h | 4 +-
drivers/md/bitmap.c | 9 +++
drivers/md/dm-raid.c | 21 +++---
drivers/media/dvb-core/dvb_frontend.c | 10 +--
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 3 +-
drivers/net/ethernet/realtek/r8169.c | 38 ++++++----
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 +
drivers/net/ipvlan/ipvlan_core.c | 2 +-
drivers/net/tap.c | 16 ++--
drivers/net/tun.c | 29 ++++++--
drivers/net/usb/qmi_wwan.c | 3 +
drivers/net/usb/usbnet.c | 5 +-
drivers/nvme/target/rdma.c | 6 +-
drivers/s390/net/qeth_core.h | 3 +
drivers/s390/net/qeth_core_main.c | 31 ++++++++
drivers/s390/net/qeth_l2_main.c | 4 +-
drivers/s390/net/qeth_l3_main.c | 13 +++-
drivers/usb/gadget/function/f_fs.c | 2 +-
drivers/vhost/net.c | 20 ++---
fs/fcntl.c | 11 ++-
include/linux/netdev_features.h | 4 +-
include/linux/netdevice.h | 1 +
include/linux/rculist_nulls.h | 38 ----------
include/linux/skbuff.h | 2 +
include/linux/usb/usbnet.h | 1 +
include/linux/virtio_net.h | 5 +-
include/net/ipv6.h | 2 +-
include/net/sock.h | 6 +-
include/net/tcp.h | 5 +-
kernel/audit.c | 39 +++++-----
net/core/dev.c | 3 +-
net/dccp/minisocks.c | 6 ++
net/ipv4/af_inet.c | 12 ++-
net/ipv4/tcp_input.c | 3 +-
net/ipv4/tcp_ipv4.c | 59 ++++++++++-----
net/ipv4/tcp_minisocks.c | 6 ++
net/ipv4/tcp_output.c | 8 +-
net/ipv4/udp_offload.c | 49 ++++++++++++-
net/ipv6/output_core.c | 6 +-
net/ipv6/route.c | 2 +-
net/ipv6/sit.c | 1 +
net/ipv6/tcp_ipv6.c | 11 +--
net/ipv6/udp_offload.c | 85 +++++++++++++++++++++-
net/kcm/kcmsock.c | 71 +++++++-----------
net/openvswitch/datapath.c | 14 ++++
net/openvswitch/flow.c | 6 +-
net/packet/af_packet.c | 37 ++++------
net/packet/internal.h | 1 -
net/rds/rdma.c | 2 +-
net/sched/act_csum.c | 6 ++
net/sched/cls_bpf.c | 21 ++++--
net/sched/sch_cbq.c | 9 ++-
net/sctp/socket.c | 6 +-
net/tipc/server.c | 1 +
net/tipc/udp_media.c | 4 -
virt/kvm/arm/vgic/vgic-its.c | 2 +-
70 files changed, 543 insertions(+), 320 deletions(-)
This is the start of the stable review cycle for the 4.9.70 release.
There are 27 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 Sun Dec 17 09:22:42 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.9.70-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.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.9.70-rc1
Leon Romanovsky <leon(a)kernel.org>
RDMA/cxgb4: Annotate r2 and stag as __be32
Zdenek Kabelac <zkabelac(a)redhat.com>
md: free unused memory after bitmap resize
Paul Moore <paul(a)paul-moore.com>
audit: ensure that 'audit=1' actually enables audit for PID 1
Keefe Liu <liuqifa(a)huawei.com>
ipvlan: fix ipv6 outbound device
Masahiro Yamada <yamada.masahiro(a)socionext.com>
kbuild: do not call cc-option before KBUILD_CFLAGS initialization
Paul Mackerras <paulus(a)ozlabs.org>
powerpc/64: Fix checksum folding in csum_tcpudp_nofold and ip_fast_csum_nofold
Marc Zyngier <marc.zyngier(a)arm.com>
KVM: arm/arm64: vgic-its: Preserve the revious read from the pending table
Al Viro <viro(a)ZenIV.linux.org.uk>
fix kcm_clone()
Vincent Pelletier <plr.vincent(a)gmail.com>
usb: gadget: ffs: Forbid usb_ep_alloc_request from sleeping
Heiko Carstens <heiko.carstens(a)de.ibm.com>
s390: always save and restore all registers on context switch
Masamitsu Yamazaki <m-yamazaki(a)ah.jp.nec.com>
ipmi: Stop timers before cleaning up the module
Debabrata Banerjee <dbanerje(a)akamai.com>
Fix handling of verdicts after NF_QUEUE
Tommi Rantala <tommi.t.rantala(a)nokia.com>
tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv()
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: fix thinko in IPv4 multicast address tracking
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: fix GSO throughput regression
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: build max size GSO skbs on L2 devices
Eric Dumazet <edumazet(a)google.com>
tcp/dccp: block bh before arming time_wait timer
Lars Persson <lars.persson(a)axis.com>
stmmac: reset last TSO segment size after device open
Eric Dumazet <edumazet(a)google.com>
net: remove hlist_nulls_add_tail_rcu()
Bjørn Mork <bjorn(a)mork.no>
usbnet: fix alignment for frames with no ethernet header
Eric Dumazet <edumazet(a)google.com>
net/packet: fix a race in packet_bind() and packet_notifier()
Mike Maloney <maloney(a)google.com>
packet: fix crash in fanout_demux_rollover()
Hangbin Liu <liuhangbin(a)gmail.com>
sit: update frag_off info
Håkon Bugge <Haakon.Bugge(a)oracle.com>
rds: Fix NULL pointer dereference in __rds_rdma_map
Jon Maloy <jon.maloy(a)ericsson.com>
tipc: fix memory leak in tipc_accept_from_sock()
Julian Wiedmann <jwi(a)linux.vnet.ibm.com>
s390/qeth: fix early exit from error path
Sebastian Sjoholm <ssjoholm(a)mac.com>
net: qmi_wwan: add Quectel BG96 2c7c:0296
-------------
Diffstat:
Makefile | 25 ++++----
arch/powerpc/include/asm/checksum.h | 17 ++++--
arch/s390/include/asm/switch_to.h | 19 +++---
drivers/char/ipmi/ipmi_si_intf.c | 44 +++++++-------
drivers/infiniband/hw/cxgb4/t4fw_ri_api.h | 4 +-
drivers/md/bitmap.c | 9 +++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 +
drivers/net/ipvlan/ipvlan_core.c | 2 +-
drivers/net/usb/qmi_wwan.c | 3 +
drivers/net/usb/usbnet.c | 5 +-
drivers/s390/net/qeth_core.h | 3 +
drivers/s390/net/qeth_core_main.c | 31 ++++++++++
drivers/s390/net/qeth_l2_main.c | 4 +-
drivers/s390/net/qeth_l3_main.c | 13 +++--
drivers/usb/gadget/function/f_fs.c | 2 +-
include/linux/rculist_nulls.h | 38 ------------
include/linux/usb/usbnet.h | 1 +
include/net/sock.h | 6 +-
kernel/audit.c | 10 ++--
net/dccp/minisocks.c | 6 ++
net/ipv4/tcp_minisocks.c | 6 ++
net/ipv6/sit.c | 1 +
net/kcm/kcmsock.c | 71 ++++++++---------------
net/netfilter/core.c | 5 ++
net/packet/af_packet.c | 37 +++++-------
net/packet/internal.h | 1 -
net/rds/rdma.c | 2 +-
net/tipc/server.c | 1 +
net/tipc/udp_media.c | 4 --
virt/kvm/arm/vgic/vgic-its.c | 2 +-
30 files changed, 191 insertions(+), 182 deletions(-)
This is the start of the stable review cycle for the 3.18.88 release.
There are 64 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 Sun Dec 17 09:21:53 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/v3.x/stable-review/patch-3.18.88-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-3.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 3.18.88-rc1
Vincent Pelletier <plr.vincent(a)gmail.com>
usb: gadget: ffs: Forbid usb_ep_alloc_request from sleeping
Marc Zyngier <marc.zyngier(a)arm.com>
arm: KVM: Fix VTTBR_BADDR_MASK BUG_ON off-by-one
Paul Moore <paul(a)paul-moore.com>
audit: ensure that 'audit=1' actually enables audit for PID 1
David Howells <dhowells(a)redhat.com>
afs: Connect up the CB.ProbeUuid
Majd Dibbiny <majd(a)mellanox.com>
IB/mlx5: Assign send CQ and recv CQ of UMR QP
Mark Bloch <markb(a)mellanox.com>
IB/mlx4: Increase maximal message size under UD QP
Herbert Xu <herbert(a)gondor.apana.org.au>
xfrm: Copy policy family in clone_policy
Arvind Yadav <arvind.yadav.cs(a)gmail.com>
atm: horizon: Fix irq release error
Xin Long <lucien.xin(a)gmail.com>
sctp: use the right sk after waking up from wait_buf sleep
Xin Long <lucien.xin(a)gmail.com>
sctp: do not free asoc when it is already dead in sctp_sendmsg
Pavel Tatashin <pasha.tatashin(a)oracle.com>
sparc64/mm: set fields in deferred pages
Chuck Lever <chuck.lever(a)oracle.com>
sunrpc: Fix rpc_task_begin trace point
Trond Myklebust <trond.myklebust(a)primarydata.com>
NFS: Fix a typo in nfs_rename()
Randy Dunlap <rdunlap(a)infradead.org>
dynamic-debug-howto: fix optional/omitted ending line number to be LARGE instead of 0
Stephen Bates <sbates(a)raithlin.com>
lib/genalloc.c: make the avail variable an atomic_long_t
Xin Long <lucien.xin(a)gmail.com>
route: update fnhe_expires for redirect when the fnhe exists
Xin Long <lucien.xin(a)gmail.com>
route: also update fnhe_genid when updating a route cache
Jérémy Lefaure <jeremy.lefaure(a)lse.epita.fr>
EDAC, i5000, i5400: Fix definition of NRECMEMB register
Jérémy Lefaure <jeremy.lefaure(a)lse.epita.fr>
EDAC, i5000, i5400: Fix use of MTR_DRAM_WIDTH macro
Jan Kara <jack(a)suse.cz>
axonram: Fix gendisk handling
Chris Brandt <chris.brandt(a)renesas.com>
i2c: riic: fix restart condition
Krzysztof Kozlowski <krzk(a)kernel.org>
crypto: s5p-sss - Fix completing crypto request in IRQ handler
WANG Cong <xiyou.wangcong(a)gmail.com>
ipv6: reorder icmpv6_init() and ip6_mr_init()
Michal Schmidt <mschmidt(a)redhat.com>
bnx2x: fix possible overrun of VFPF multicast addresses array
Blomme, Maarten <Maarten.Blomme(a)flir.com>
spi_ks8995: fix "BUG: key accdaa28 not in .data!"
Mark Rutland <mark.rutland(a)arm.com>
arm: KVM: Survive unknown traps from guests
Wanpeng Li <wanpeng.li(a)hotmail.com>
KVM: nVMX: reset nested_run_pending if the vCPU is going to be reset
Franck Demathieu <fdemathieu(a)gmail.com>
irqchip/crossbar: Fix incorrect type of register size
James Smart <jsmart2021(a)gmail.com>
scsi: lpfc: Fix crash during Hardware error recovery on SLI3 adapters
Tejun Heo <tj(a)kernel.org>
workqueue: trigger WARN if queue_delayed_work() is called with NULL @wq
Tejun Heo <tj(a)kernel.org>
libata: drop WARN from protocol error in ata_sff_qc_issue()
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
USB: gadgetfs: Fix a potential memory leak in 'dev_config()'
John Keeping <john(a)metanate.com>
usb: gadget: configs: plug memory leak
Sachin Sant <sachinp(a)linux.vnet.ibm.com>
selftest/powerpc: Fix false failures for skipped tests
Sasha Levin <alexander.levin(a)verizon.com>
Revert "s390/kbuild: enable modversions for symbols exported from asm"
Sasha Levin <alexander.levin(a)verizon.com>
Revert "drm/armada: Fix compile fail"
Eric Dumazet <edumazet(a)google.com>
net/packet: fix a race in packet_bind() and packet_notifier()
Hangbin Liu <liuhangbin(a)gmail.com>
sit: update frag_off info
Håkon Bugge <Haakon.Bugge(a)oracle.com>
rds: Fix NULL pointer dereference in __rds_rdma_map
Dave Martin <Dave.Martin(a)arm.com>
arm64: fpsimd: Prevent registers leaking from dead tasks
Andrew Honig <ahonig(a)google.com>
KVM: VMX: remove I/O port 0x80 bypass on Intel hosts
Kristina Martsenko <kristina.martsenko(a)arm.com>
arm64: KVM: fix VTTBR_BADDR_MASK BUG_ON off-by-one
Laurent Caumont <lcaumont2(a)gmail.com>
media: dvb: i2c transfers over usb cannot be done from stack
Daniel Thompson <daniel.thompson(a)linaro.org>
kdb: Fix handling of kallsyms_symbol_next() return value
Robin Murphy <robin.murphy(a)arm.com>
iommu/vt-d: Fix scatterlist offset handling
Jaejoong Kim <climbbb.kim(a)gmail.com>
ALSA: usb-audio: Add check return value for usb_string()
Jaejoong Kim <climbbb.kim(a)gmail.com>
ALSA: usb-audio: Fix out-of-bound error
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Remove spurious WARN_ON() at timer check
Robb Glasser <rglasser(a)google.com>
ALSA: pcm: prevent UAF in snd_pcm_info
Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
x86/PCI: Make broadcom_postcore_init() check acpi_disabled
Eric Biggers <ebiggers(a)google.com>
X.509: reject invalid BIT STRING for subjectPublicKey
Eric Biggers <ebiggers(a)google.com>
KEYS: add missing permission check for request_key() destination
Eric Biggers <ebiggers(a)google.com>
ASN.1: check for error from ASN1_OP_END__ACT actions
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
efi: Move some sysfs files to be read-only by root
William Breathitt Gray <vilhelm.gray(a)gmail.com>
isa: Prevent NULL dereference in isa_bus driver callbacks
Paul Meyer <Paul.Meyer(a)microsoft.com>
hv: kvp: Avoid reading past allocated blocks from KVP file
weiping zhang <zwp10758(a)gmail.com>
virtio: release virtio index when fail to device_register
Martin Kelly <mkelly(a)xevo.com>
can: usb_8dev: cancel urb on -EPIPE and -EPROTO
Martin Kelly <mkelly(a)xevo.com>
can: esd_usb2: cancel urb on -EPIPE and -EPROTO
Martin Kelly <mkelly(a)xevo.com>
can: ems_usb: cancel urb on -EPIPE and -EPROTO
Martin Kelly <mkelly(a)xevo.com>
can: kvaser_usb: cancel urb on -EPIPE and -EPROTO
Jimmy Assarsson <jimmyassarsson(a)gmail.com>
can: kvaser_usb: ratelimit errors if incomplete messages are received
Jimmy Assarsson <jimmyassarsson(a)gmail.com>
can: kvaser_usb: Fix comparison bug in kvaser_usb_read_bulk_callback()
Jimmy Assarsson <jimmyassarsson(a)gmail.com>
can: kvaser_usb: free buf in error paths
-------------
Diffstat:
Makefile | 4 +-
arch/arm/include/asm/kvm_arm.h | 4 +-
arch/arm/kvm/handle_exit.c | 19 ++++---
arch/arm64/include/asm/kvm_arm.h | 3 +-
arch/arm64/kernel/process.c | 9 +++
arch/powerpc/sysdev/axonram.c | 5 +-
arch/s390/include/asm/asm-prototypes.h | 8 ---
arch/sparc/mm/init_64.c | 9 ++-
arch/x86/kvm/vmx.c | 9 +--
arch/x86/pci/broadcom_bus.c | 2 +-
crypto/asymmetric_keys/x509_cert_parser.c | 2 +
drivers/ata/libata-sff.c | 1 -
drivers/atm/horizon.c | 2 +-
drivers/base/isa.c | 10 ++--
drivers/crypto/s5p-sss.c | 5 +-
drivers/edac/i5000_edac.c | 8 +--
drivers/edac/i5400_edac.c | 9 +--
drivers/firmware/efi/efi.c | 3 +-
drivers/firmware/efi/runtime-map.c | 10 ++--
drivers/gpu/drm/armada/Makefile | 2 -
drivers/i2c/busses/i2c-riic.c | 6 +-
drivers/infiniband/hw/mlx4/qp.c | 2 +-
drivers/infiniband/hw/mlx5/main.c | 2 +
drivers/iommu/intel-iommu.c | 8 ++-
drivers/irqchip/irq-crossbar.c | 8 +--
drivers/media/usb/dvb-usb/dibusb-common.c | 16 +++++-
drivers/net/can/usb/ems_usb.c | 2 +
drivers/net/can/usb/esd_usb2.c | 2 +
drivers/net/can/usb/kvaser_usb.c | 13 +++--
drivers/net/can/usb/usb_8dev.c | 2 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_vfpf.c | 23 ++++----
drivers/net/phy/spi_ks8995.c | 1 +
drivers/scsi/lpfc/lpfc_els.c | 14 +++--
drivers/usb/gadget/configfs.c | 1 +
drivers/usb/gadget/function/f_fs.c | 2 +-
drivers/usb/gadget/legacy/inode.c | 4 +-
drivers/virtio/virtio.c | 2 +
fs/afs/cmservice.c | 3 +
fs/nfs/dir.c | 2 +-
include/linux/genalloc.h | 3 +-
include/linux/sysfs.h | 6 ++
kernel/audit.c | 10 ++--
kernel/debug/kdb/kdb_io.c | 2 +-
kernel/workqueue.c | 1 +
lib/asn1_decoder.c | 2 +
lib/dynamic_debug.c | 4 ++
lib/genalloc.c | 10 ++--
net/ipv4/route.c | 14 +++--
net/ipv6/af_inet6.c | 10 ++--
net/ipv6/sit.c | 1 +
net/packet/af_packet.c | 5 ++
net/rds/rdma.c | 2 +-
net/sctp/socket.c | 38 ++++++++-----
net/sunrpc/sched.c | 3 +-
net/xfrm/xfrm_policy.c | 1 +
security/keys/request_key.c | 46 +++++++++++++---
sound/core/pcm.c | 2 +
sound/core/seq/seq_timer.c | 2 +-
sound/usb/mixer.c | 13 +++--
tools/hv/hv_kvp_daemon.c | 70 +++++-------------------
tools/testing/selftests/powerpc/harness.c | 6 +-
61 files changed, 288 insertions(+), 200 deletions(-)
This is a note to let you know that I've just added the patch titled
drivers: base: cacheinfo: fix cache type for non-architected system
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From f57ab9a01a36ef3454333251cc57e3a9948b17bf Mon Sep 17 00:00:00 2001
From: Sudeep Holla <sudeep.holla(a)arm.com>
Date: Fri, 17 Nov 2017 11:56:41 +0000
Subject: drivers: base: cacheinfo: fix cache type for non-architected system
cache
Commit dfea747d2aba ("drivers: base: cacheinfo: support DT overrides for
cache properties") doesn't initialise the cache type if it's present
only in DT and the architecture is not aware of it. They are unified
system level cache which are generally transparent.
This patch check if the cache type is set to NOCACHE but the DT node
indicates that it's unified cache and sets the cache type accordingly.
Fixes: dfea747d2aba ("drivers: base: cacheinfo: support DT overrides for cache properties")
Reported-and-tested-by: Tan Xiaojun <tanxiaojun(a)huawei.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/cacheinfo.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index eb3af2739537..07532d83be0b 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -186,6 +186,11 @@ static void cache_associativity(struct cacheinfo *this_leaf)
this_leaf->ways_of_associativity = (size / nr_sets) / line_size;
}
+static bool cache_node_is_unified(struct cacheinfo *this_leaf)
+{
+ return of_property_read_bool(this_leaf->of_node, "cache-unified");
+}
+
static void cache_of_override_properties(unsigned int cpu)
{
int index;
@@ -194,6 +199,14 @@ static void cache_of_override_properties(unsigned int cpu)
for (index = 0; index < cache_leaves(cpu); index++) {
this_leaf = this_cpu_ci->info_list + index;
+ /*
+ * init_cache_level must setup the cache level correctly
+ * overriding the architecturally specified levels, so
+ * if type is NONE at this stage, it should be unified
+ */
+ if (this_leaf->type == CACHE_TYPE_NOCACHE &&
+ cache_node_is_unified(this_leaf))
+ this_leaf->type = CACHE_TYPE_UNIFIED;
cache_size(this_leaf);
cache_get_line_size(this_leaf);
cache_nr_sets(this_leaf);
--
2.15.1
This is a note to let you know that I've just added the patch titled
Revert "staging: ion: Fix ion_cma_heap allocations"
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 3d2a0c5ff02d57ab7b4f16a6782a66765d930b7d Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Fri, 15 Dec 2017 19:36:24 +0100
Subject: Revert "staging: ion: Fix ion_cma_heap allocations"
This reverts commit d98e6dbf42f73101128885a1e0ae672cd92b2e1a as it broke
the build on some configurations. It's not really obvious why those
configurataions/platforms do not have all of the cma #defines availble,
which means something larger is going wrong here.
Reported-by: kbuild test robot <fengguang.wu(a)intel.com>
Cc: Laura Abbott <labbott(a)redhat.com>
Cc: Sumit Semwal <sumit.semwal(a)linaro.org>
Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
Cc: Archit Taneja <architt(a)codeaurora.org>
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Cc: Dmitry Shmidt <dimitrysh(a)google.com>
Cc: Todd Kjos <tkjos(a)google.com>
Cc: Amit Pundir <amit.pundir(a)linaro.org>
Cc: stable <stable(a)vger.kernel.org>
Cc: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ion/ion_cma_heap.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/android/ion/ion_cma_heap.c b/drivers/staging/android/ion/ion_cma_heap.c
index 86196ffd2faf..dd5545d9990a 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -39,15 +39,9 @@ static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
struct ion_cma_heap *cma_heap = to_cma_heap(heap);
struct sg_table *table;
struct page *pages;
- unsigned long size = PAGE_ALIGN(len);
- unsigned long nr_pages = size >> PAGE_SHIFT;
- unsigned long align = get_order(size);
int ret;
- if (align > CONFIG_CMA_ALIGNMENT)
- align = CONFIG_CMA_ALIGNMENT;
-
- pages = cma_alloc(cma_heap->cma, nr_pages, align, GFP_KERNEL);
+ pages = cma_alloc(cma_heap->cma, len, 0, GFP_KERNEL);
if (!pages)
return -ENOMEM;
@@ -59,7 +53,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
if (ret)
goto free_mem;
- sg_set_page(table->sgl, pages, size, 0);
+ sg_set_page(table->sgl, pages, len, 0);
buffer->priv_virt = pages;
buffer->sg_table = table;
@@ -68,7 +62,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
free_mem:
kfree(table);
err:
- cma_release(cma_heap->cma, pages, nr_pages);
+ cma_release(cma_heap->cma, pages, buffer->size);
return -ENOMEM;
}
@@ -76,10 +70,9 @@ static void ion_cma_free(struct ion_buffer *buffer)
{
struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
struct page *pages = buffer->priv_virt;
- unsigned long nr_pages = PAGE_ALIGN(buffer->size) >> PAGE_SHIFT;
/* release memory */
- cma_release(cma_heap->cma, pages, nr_pages);
+ cma_release(cma_heap->cma, pages, buffer->size);
/* release sg table */
sg_free_table(buffer->sg_table);
kfree(buffer->sg_table);
--
2.15.1
This is the start of the stable review cycle for the 4.14.6 release.
There are 164 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 Dec 14 12:34:08 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.14.6-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.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.14.6-rc1
Reinette Chatre <reinette.chatre(a)intel.com>
x86/intel_rdt: Fix potential deadlock during resctrl unmount
Leon Romanovsky <leon(a)kernel.org>
RDMA/cxgb4: Annotate r2 and stag as __be32
Zdenek Kabelac <zkabelac(a)redhat.com>
md: free unused memory after bitmap resize
Heinz Mauelshagen <heinzm(a)redhat.com>
dm raid: fix panic when attempting to force a raid to sync
Paul Moore <paul(a)paul-moore.com>
audit: ensure that 'audit=1' actually enables audit for PID 1
Steve Grubb <sgrubb(a)redhat.com>
audit: Allow auditd to set pid to 0 to end auditing
Israel Rukshin <israelr(a)mellanox.com>
nvmet-rdma: update queue list during ib_device removal
Bart Van Assche <bart.vanassche(a)wdc.com>
blk-mq: Avoid that request queue removal can trigger list corruption
Hongxu Jia <hongxu.jia(a)windriver.com>
ide: ide-atapi: fix compile error with defining macro DEBUG
Keefe Liu <liuqifa(a)huawei.com>
ipvlan: fix ipv6 outbound device
Vaidyanathan Srinivasan <svaidy(a)linux.vnet.ibm.com>
powerpc/powernv/idle: Round up latency and residency values
Masahiro Yamada <yamada.masahiro(a)socionext.com>
kbuild: do not call cc-option before KBUILD_CFLAGS initialization
David Howells <dhowells(a)redhat.com>
afs: Connect up the CB.ProbeUuid
David Howells <dhowells(a)redhat.com>
afs: Fix total-length calculation for multiple-page send
Majd Dibbiny <majd(a)mellanox.com>
IB/mlx5: Assign send CQ and recv CQ of UMR QP
Mark Bloch <markb(a)mellanox.com>
IB/mlx4: Increase maximal message size under UD QP
Sriharsha Basavapatna <sriharsha.basavapatna(a)broadcom.com>
bnxt_re: changing the ip address shouldn't affect new connections
Chao Yu <yuchao0(a)huawei.com>
f2fs: fix to clear FI_NO_PREALLOC
Herbert Xu <herbert(a)gondor.apana.org.au>
xfrm: Copy policy family in clone_policy
Ilya Lesokhin <ilyal(a)mellanox.com>
tls: Use kzalloc for aead_request allocation
Jason Baron <jbaron(a)akamai.com>
jump_label: Invoke jump_label_test() via early_initcall()
Arvind Yadav <arvind.yadav.cs(a)gmail.com>
atm: horizon: Fix irq release error
Masahiro Yamada <yamada.masahiro(a)socionext.com>
kbuild: rpm-pkg: fix jobserver unavailable warning
Sudeep Holla <sudeep.holla(a)arm.com>
mailbox: mailbox-test: don't rely on rx_buffer content to signal data ready
Zhong Kaihua <zhongkaihua(a)huawei.com>
clk: hi3660: fix incorrect uart3 clock freqency
Masahiro Yamada <yamada.masahiro(a)socionext.com>
clk: uniphier: fix DAPLL2 clock rate of Pro5
Johan Hovold <johan(a)kernel.org>
clk: qcom: common: fix legacy board-clock registration
Mylene JOSSERAND <mylene.josserand(a)free-electrons.com>
clk: sunxi-ng: a83t: Fix i2c buses bits
Gabriel Fernandez <gabriel.fernandez(a)st.com>
clk: stm32h7: fix test of clock config
Eric Dumazet <edumazet(a)google.com>
bpf: fix lockdep splat
Hangbin Liu <liuhangbin(a)gmail.com>
geneve: fix fill_info when link down
Jeff Layton <jlayton(a)redhat.com>
fcntl: don't leak fd reference when fixup_compat_flock fails
Xin Long <lucien.xin(a)gmail.com>
sctp: use the right sk after waking up from wait_buf sleep
Xin Long <lucien.xin(a)gmail.com>
sctp: do not free asoc when it is already dead in sctp_sendmsg
Miles Chen <miles.chen(a)mediatek.com>
slub: fix sysfs duplicate filename creation when slub_debug=O
Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com>
zsmalloc: calling zs_map_object() from irq is a bug
Pavel Tatashin <pasha.tatashin(a)oracle.com>
sparc64/mm: set fields in deferred pages
Ming Lei <ming.lei(a)redhat.com>
block: wake up all tasks blocked in get_request()
Johan Hovold <johan(a)kernel.org>
dt-bindings: usb: fix reg-property port-number range
Darrick J. Wong <darrick.wong(a)oracle.com>
xfs: fix forgotten rcu read unlock when skipping inode reclaim
Pieter Jansen van Vuuren <pieter.jansenvanvuuren(a)netronome.com>
nfp: fix flower offload metadata flag usage
Dirk van der Merwe <dirk.vandermerwe(a)netronome.com>
nfp: inherit the max_mtu from the PF netdev
Chuck Lever <chuck.lever(a)oracle.com>
sunrpc: Fix rpc_task_begin trace point
Trond Myklebust <trond.myklebust(a)primarydata.com>
NFS: Fix a typo in nfs_rename()
Randy Dunlap <rdunlap(a)infradead.org>
dynamic-debug-howto: fix optional/omitted ending line number to be LARGE instead of 0
Stephen Bates <sbates(a)raithlin.com>
lib/genalloc.c: make the avail variable an atomic_long_t
Joe Lawrence <joe.lawrence(a)redhat.com>
pipe: match pipe_max_size data type with procfs
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
drivers/rapidio/devices/rio_mport_cdev.c: fix resource leak in error handling path in 'rio_dma_transfer()'
Colin Ian King <colin.king(a)canonical.com>
rsi: fix memory leak on buf and usb_reg_buf
Xin Long <lucien.xin(a)gmail.com>
route: update fnhe_expires for redirect when the fnhe exists
Xin Long <lucien.xin(a)gmail.com>
route: also update fnhe_genid when updating a route cache
Alexey Kodanev <alexey.kodanev(a)oracle.com>
gre6: use log_ecn_error module parameter in ip6_tnl_rcv()
Ben Hutchings <ben.hutchings(a)codethink.co.uk>
mac80211_hwsim: Fix memory leak in hwsim_new_radio_nl()
Dave Hansen <dave.hansen(a)linux.intel.com>
x86/mpx/selftests: Fix up weird arrays
John Johansen <john.johansen(a)canonical.com>
apparmor: fix leak of null profile name if profile allocation fails
Madhavan Srinivasan <maddy(a)linux.vnet.ibm.com>
powerpc/perf: Fix pmu_count to count only nest imc pmus
Masahiro Yamada <yamada.masahiro(a)socionext.com>
coccinelle: fix parallel build with CHECK=scripts/coccicheck
Masahiro Yamada <yamada.masahiro(a)socionext.com>
kbuild: pkg: use --transform option to prefix paths in tar
Ursula Braun <ursula.braun(a)de.ibm.com>
net/smc: use sk_rcvbuf as start for rmb creation
Colin Ian King <colin.king(a)canonical.com>
irqchip/qcom: Fix u32 comparison with value less than zero
Russell King <rmk+kernel(a)armlinux.org.uk>
ARM: avoid faulting on qemu
Russell King <rmk+kernel(a)armlinux.org.uk>
ARM: BUG if jumping to usermode address in kernel mode
LEROY Christophe <christophe.leroy(a)c-s.fr>
crypto: talitos - fix ctr-aes-talitos
LEROY Christophe <christophe.leroy(a)c-s.fr>
crypto: talitos - fix use of sg_link_tbl_len
LEROY Christophe <christophe.leroy(a)c-s.fr>
crypto: talitos - fix AEAD for sha224 on non sha224 capable chips
LEROY Christophe <christophe.leroy(a)c-s.fr>
crypto: talitos - fix setkey to check key weakness
LEROY Christophe <christophe.leroy(a)c-s.fr>
crypto: talitos - fix memory corruption on SEC2
LEROY Christophe <christophe.leroy(a)c-s.fr>
crypto: talitos - fix AEAD test failures
Daniel Jurgens <danielj(a)mellanox.com>
IB/core: Only enforce security for InfiniBand
Parav Pandit <parav(a)mellanox.com>
IB/core: Avoid unnecessary return value check
Kim Phillips <kim.phillips(a)arm.com>
bus: arm-ccn: fix module unloading Error: Removing state 147 which has instances left.
Marc Zyngier <marc.zyngier(a)arm.com>
bus: arm-ccn: Fix use of smp_processor_id() in preemptible context
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
bus: arm-ccn: Check memory allocation failure
Marc Zyngier <marc.zyngier(a)arm.com>
bus: arm-cci: Fix use of smp_processor_id() in preemptible context
Fabio Estevam <fabio.estevam(a)nxp.com>
Revert "ARM: dts: imx53: add srtc node"
Will Deacon <will.deacon(a)arm.com>
arm64: SW PAN: Update saved ttbr0 value on enter_lazy_tlb
Will Deacon <will.deacon(a)arm.com>
arm64: SW PAN: Point saved ttbr0 at the zero page when switching to init_mm
Dave Martin <Dave.Martin(a)arm.com>
arm64: fpsimd: Prevent registers leaking from dead tasks
Marc Zyngier <marc.zyngier(a)arm.com>
KVM: arm/arm64: vgic-its: Check result of allocation before use
Marc Zyngier <marc.zyngier(a)arm.com>
KVM: arm/arm64: vgic: Preserve the revious read from the pending table
Marc Zyngier <marc.zyngier(a)arm.com>
KVM: arm/arm64: vgic-irqfd: Fix MSI entry allocation
Christoffer Dall <christoffer.dall(a)linaro.org>
KVM: arm/arm64: Fix broken GICH_ELRSR big endian conversion
Andrew Honig <ahonig(a)google.com>
KVM: VMX: remove I/O port 0x80 bypass on Intel hosts
Marc Zyngier <marc.zyngier(a)arm.com>
arm: KVM: Fix VTTBR_BADDR_MASK BUG_ON off-by-one
Kristina Martsenko <kristina.martsenko(a)arm.com>
arm64: KVM: fix VTTBR_BADDR_MASK BUG_ON off-by-one
Sean Young <sean(a)mess.org>
media: rc: partial revert of "media: rc: per-protocol repeat period"
Sean Young <sean(a)mess.org>
media: rc: sir_ir: detect presence of port
Laurent Caumont <lcaumont2(a)gmail.com>
media: dvb: i2c transfers over usb cannot be done from stack
Daniel Vetter <daniel.vetter(a)ffwll.ch>
drm: safely free connectors from connector_iter
Ville Syrjälä <ville.syrjala(a)linux.intel.com>
drm/i915: Fix vblank timestamp/frame counter jumps on gen2
Marek Szyprowski <m.szyprowski(a)samsung.com>
drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU
Marek Szyprowski <m.szyprowski(a)samsung.com>
drm/bridge: analogix dp: Fix runtime PM state in get_modes() callback
Song Liu <songliubraving(a)fb.com>
md/r5cache: move mddev_lock() out of r5c_journal_mode_set()
Daniel Thompson <daniel.thompson(a)linaro.org>
kdb: Fix handling of kallsyms_symbol_next() return value
Arend Van Spriel <arend.vanspriel(a)broadcom.com>
brcmfmac: change driver unbind order of the sdio function devices
David Spinadel <david.spinadel(a)intel.com>
iwlwifi: mvm: enable RX offloading with TKIP and WEP
Emmanuel Grumbach <emmanuel.grumbach(a)intel.com>
iwlwifi: mvm: fix packet injection
Ihab Zhaika <ihab.zhaika(a)intel.com>
iwlwifi: add new cards for 9260 and 22000 series
Johannes Berg <johannes.berg(a)intel.com>
iwlwifi: mvm: flush queue before deleting ROC
Emmanuel Grumbach <emmanuel.grumbach(a)intel.com>
iwlwifi: mvm: don't use transmit queue hang detection when it is not possible
Sara Sharon <sara.sharon(a)intel.com>
iwlwifi: mvm: mark MIC stripped MPDUs
Nicholas Piggin <npiggin(a)gmail.com>
powerpc/64s: Initialize ISAv3 MMU registers before setting partition table
David Gibson <david(a)gibson.dropbear.id.au>
Revert "powerpc: Do not call ppc_md.panic in fadump panic notifier"
Janosch Frank <frankja(a)linux.vnet.ibm.com>
KVM: s390: Fix skey emulation permission check
Heiko Carstens <heiko.carstens(a)de.ibm.com>
s390: fix compat system call table
Heiko Carstens <heiko.carstens(a)de.ibm.com>
s390/mm: fix off-by-one bug in 5-level page table handling
Heiko Carstens <heiko.carstens(a)de.ibm.com>
s390: always save and restore all registers on context switch
Lai Jiangshan <jiangshanlai(a)gmail.com>
smp/hotplug: Move step CPUHP_AP_SMPCFD_DYING to the correct place
Robin Murphy <robin.murphy(a)arm.com>
iommu/vt-d: Fix scatterlist offset handling
Jaejoong Kim <climbbb.kim(a)gmail.com>
ALSA: usb-audio: Add check return value for usb_string()
Jaejoong Kim <climbbb.kim(a)gmail.com>
ALSA: usb-audio: Fix out-of-bound error
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Remove spurious WARN_ON() at timer check
Robb Glasser <rglasser(a)google.com>
ALSA: pcm: prevent UAF in snd_pcm_info
Kailang Yang <kailang(a)realtek.com>
ALSA: hda/realtek - New codec support for ALC257
Jeff Mahoney <jeffm(a)suse.com>
btrfs: handle errors while updating refcounts in update_ref_for_cow
Jeff Mahoney <jeffm(a)suse.com>
btrfs: fix missing error return in btrfs_drop_snapshot
Radim Krčmář <rkrcmar(a)redhat.com>
KVM: x86: fix APIC page invalidation
Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
x86/PCI: Make broadcom_postcore_init() check acpi_disabled
Chunyu Hu <chuhu(a)redhat.com>
x86/idt: Load idt early in start_secondary
Eric Biggers <ebiggers(a)google.com>
X.509: fix comparisons of ->pkey_algo
Eric Biggers <ebiggers(a)google.com>
X.509: reject invalid BIT STRING for subjectPublicKey
Eric Biggers <ebiggers(a)google.com>
KEYS: reject NULL restriction string when type is specified
Eric Biggers <ebiggers(a)google.com>
KEYS: add missing permission check for request_key() destination
Eric Biggers <ebiggers(a)google.com>
ASN.1: check for error from ASN1_OP_END__ACT actions
Eric Biggers <ebiggers(a)google.com>
ASN.1: fix out-of-bounds read when parsing indefinite length item
Pan Bian <bianpan2016(a)163.com>
efi/esrt: Use memunmap() instead of kfree() to free the remapping
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
efi: Move some sysfs files to be read-only by root
Huacai Chen <chenhc(a)lemote.com>
scsi: libsas: align sata_device's rps_resp on a cacheline
Huacai Chen <chenhc(a)lemote.com>
scsi: use dma_get_cache_alignment() as minimum DMA alignment
Christoph Hellwig <hch(a)lst.de>
scsi: dma-mapping: always provide dma_get_cache_alignment
William Breathitt Gray <vilhelm.gray(a)gmail.com>
isa: Prevent NULL dereference in isa_bus driver callbacks
Guenter Roeck <linux(a)roeck-us.net>
firmware: vpd: Fix platform driver and device registration/unregistration
Guenter Roeck <linux(a)roeck-us.net>
firmware: vpd: Tie firmware kobject to device lifetime
Guenter Roeck <linux(a)roeck-us.net>
firmware: vpd: Destroy vpd sections in remove function
Robin H. Johnson <robbat2(a)gentoo.org>
firmware: cleanup FIRMWARE_IN_KERNEL message
Paul Meyer <Paul.Meyer(a)microsoft.com>
hv: kvp: Avoid reading past allocated blocks from KVP file
K. Y. Srinivasan <kys(a)microsoft.com>
Drivers: hv: vmbus: Fix a rescind issue
Gregory CLEMENT <gregory.clement(a)free-electrons.com>
pinctrl: armada-37xx: Fix direction_output() callback behavior
Martin Blumenstingl <martin.blumenstingl(a)googlemail.com>
iio: adc: meson-saradc: Meson8 and Meson8b do not have REG11 and REG13
Martin Blumenstingl <martin.blumenstingl(a)googlemail.com>
iio: adc: meson-saradc: initialize the bandgap correctly on older SoCs
Martin Blumenstingl <martin.blumenstingl(a)googlemail.com>
iio: adc: meson-saradc: fix the bit_idx of the adc_en clock
Pan Bian <bianpan2016(a)163.com>
iio: adc: cpcap: fix incorrect validation
Peter Meerwald-Stadler <pmeerw(a)pmeerw.net>
iio: health: max30102: Temperature should be in milli Celsius
Arnd Bergmann <arnd(a)arndb.de>
iio: stm32: fix adc/trigger link error
weiping zhang <zwp10758(a)gmail.com>
virtio: release virtio index when fail to device_register
Stephane Grosjean <s.grosjean(a)peak-system.com>
can: peak/pcie_fd: fix potential bug in restarting tx queue
Martin Kelly <mkelly(a)xevo.com>
can: usb_8dev: cancel urb on -EPIPE and -EPROTO
Martin Kelly <mkelly(a)xevo.com>
can: esd_usb2: cancel urb on -EPIPE and -EPROTO
Martin Kelly <mkelly(a)xevo.com>
can: ems_usb: cancel urb on -EPIPE and -EPROTO
Martin Kelly <mkelly(a)xevo.com>
can: mcba_usb: cancel urb on -EPROTO
Martin Kelly <mkelly(a)xevo.com>
can: kvaser_usb: cancel urb on -EPIPE and -EPROTO
Jimmy Assarsson <jimmyassarsson(a)gmail.com>
can: kvaser_usb: ratelimit errors if incomplete messages are received
Jimmy Assarsson <jimmyassarsson(a)gmail.com>
can: kvaser_usb: Fix comparison bug in kvaser_usb_read_bulk_callback()
Jimmy Assarsson <jimmyassarsson(a)gmail.com>
can: kvaser_usb: free buf in error paths
Oliver Stäbler <oliver.staebler(a)bytesatwork.ch>
can: ti_hecc: Fix napi poll return value for repoll
Marc Kleine-Budde <mkl(a)pengutronix.de>
can: flexcan: fix VF610 state transition issue
Stephane Grosjean <s.grosjean(a)peak-system.com>
can: peak/pci: fix potential bug when probe() fails
Martin Kelly <mkelly(a)xevo.com>
can: mcba_usb: fix device disconnect bug
John Keeping <john(a)metanate.com>
usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT
Johan Hovold <johan(a)kernel.org>
serdev: ttyport: fix tty locking in close
Johan Hovold <johan(a)kernel.org>
serdev: ttyport: fix NULL-deref on hangup
Johan Hovold <johan(a)kernel.org>
serdev: ttyport: add missing receive_buf sanity checks
Roger Quadros <rogerq(a)ti.com>
usb: gadget: core: Fix ->udc_set_speed() speed handling
Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
usb: gadget: udc: renesas_usb3: fix number of the pipes
-------------
Diffstat:
.../devicetree/bindings/usb/usb-device.txt | 2 +-
Makefile | 25 ++++----
arch/arm/boot/dts/imx53.dtsi | 9 ---
arch/arm/include/asm/assembler.h | 18 ++++++
arch/arm/include/asm/kvm_arm.h | 3 +-
arch/arm/kernel/entry-header.S | 6 ++
arch/arm64/include/asm/efi.h | 4 +-
arch/arm64/include/asm/kvm_arm.h | 3 +-
arch/arm64/include/asm/mmu_context.h | 46 +++++++-------
arch/arm64/kernel/process.c | 9 +++
arch/powerpc/include/asm/machdep.h | 1 +
arch/powerpc/include/asm/setup.h | 1 +
arch/powerpc/kernel/cpu_setup_power.S | 2 +
arch/powerpc/kernel/fadump.c | 22 -------
arch/powerpc/kernel/setup-common.c | 27 +++++++++
arch/powerpc/platforms/powernv/opal-imc.c | 6 +-
arch/powerpc/platforms/ps3/setup.c | 15 +++++
arch/powerpc/platforms/pseries/setup.c | 1 +
arch/s390/include/asm/switch_to.h | 27 ++++-----
arch/s390/kernel/syscalls.S | 6 +-
arch/s390/kvm/priv.c | 11 +++-
arch/s390/mm/pgalloc.c | 2 -
arch/sparc/mm/init_64.c | 9 ++-
arch/x86/include/asm/kvm_host.h | 3 +
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 10 ++--
arch/x86/kernel/smpboot.c | 2 +-
arch/x86/kvm/vmx.c | 5 --
arch/x86/kvm/x86.c | 14 +++++
arch/x86/pci/broadcom_bus.c | 2 +-
block/blk-core.c | 5 +-
crypto/asymmetric_keys/pkcs7_verify.c | 2 +-
crypto/asymmetric_keys/x509_cert_parser.c | 2 +
crypto/asymmetric_keys/x509_public_key.c | 2 +-
drivers/atm/horizon.c | 2 +-
drivers/base/Kconfig | 25 ++++----
drivers/base/isa.c | 10 ++--
drivers/bus/arm-cci.c | 7 ++-
drivers/bus/arm-ccn.c | 11 +++-
drivers/clk/clk-stm32h7.c | 4 +-
drivers/clk/hisilicon/clk-hi3660.c | 2 +-
drivers/clk/qcom/common.c | 6 +-
drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 4 +-
drivers/clk/uniphier/clk-uniphier-sys.c | 2 +-
drivers/cpuidle/cpuidle-powernv.c | 4 +-
drivers/crypto/talitos.c | 66 +++++++++++++-------
drivers/firmware/efi/efi.c | 3 +-
drivers/firmware/efi/esrt.c | 17 +++---
drivers/firmware/efi/runtime-map.c | 10 ++--
drivers/firmware/google/vpd.c | 48 +++++++++++----
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +
drivers/gpu/drm/drm_connector.c | 28 ++++++++-
drivers/gpu/drm/drm_mode_config.c | 2 +
drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +++
drivers/gpu/drm/i915/intel_display.c | 51 +++++++++++-----
drivers/hv/channel.c | 10 +++-
drivers/hv/channel_mgmt.c | 7 ++-
drivers/ide/ide-atapi.c | 6 +-
drivers/iio/adc/cpcap-adc.c | 2 +-
drivers/iio/adc/meson_saradc.c | 52 ++++++++++++----
drivers/iio/health/max30102.c | 2 +-
drivers/infiniband/core/security.c | 63 ++++++++++++++-----
drivers/infiniband/hw/bnxt_re/ib_verbs.c | 1 +
drivers/infiniband/hw/cxgb4/t4fw_ri_api.h | 4 +-
drivers/infiniband/hw/mlx4/qp.c | 2 +-
drivers/infiniband/hw/mlx5/main.c | 2 +
drivers/iommu/intel-iommu.c | 8 ++-
drivers/irqchip/qcom-irq-combiner.c | 2 +-
drivers/mailbox/mailbox-test.c | 11 ++--
drivers/md/bitmap.c | 9 +++
drivers/md/dm-raid.c | 21 +++----
drivers/md/raid5-cache.c | 22 +++----
drivers/media/rc/rc-main.c | 32 +++++-----
drivers/media/rc/sir_ir.c | 40 +++++++++++--
drivers/media/usb/dvb-usb/dibusb-common.c | 16 ++++-
drivers/net/can/flexcan.c | 5 +-
drivers/net/can/peak_canfd/peak_canfd.c | 9 +--
drivers/net/can/peak_canfd/peak_pciefd_main.c | 5 +-
drivers/net/can/sja1000/peak_pci.c | 5 +-
drivers/net/can/ti_hecc.c | 3 +
drivers/net/can/usb/ems_usb.c | 2 +
drivers/net/can/usb/esd_usb2.c | 2 +
drivers/net/can/usb/kvaser_usb.c | 13 ++--
drivers/net/can/usb/mcba_usb.c | 2 +
drivers/net/can/usb/usb_8dev.c | 2 +
drivers/net/ethernet/netronome/nfp/flower/main.h | 3 +-
.../net/ethernet/netronome/nfp/flower/metadata.c | 7 ++-
drivers/net/ethernet/netronome/nfp/nfp_net_repr.c | 2 +
drivers/net/geneve.c | 24 ++++----
drivers/net/ipvlan/ipvlan_core.c | 2 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
drivers/net/wireless/intel/iwlwifi/fw/api/txq.h | 4 ++
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 3 +
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 14 ++++-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 53 ++++++++++++----
.../net/wireless/intel/iwlwifi/mvm/time-event.c | 24 +++++++-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 11 +++-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 2 +
drivers/net/wireless/mac80211_hwsim.c | 5 +-
drivers/net/wireless/rsi/rsi_91x_usb.c | 12 ++--
drivers/nvme/target/rdma.c | 6 +-
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 13 +++-
drivers/rapidio/devices/rio_mport_cdev.c | 3 +-
drivers/scsi/scsi_lib.c | 10 ++--
drivers/tty/serdev/serdev-ttyport.c | 26 +++++++-
drivers/usb/gadget/function/f_fs.c | 13 +++-
drivers/usb/gadget/udc/core.c | 8 ++-
drivers/usb/gadget/udc/renesas_usb3.c | 2 +-
drivers/virtio/virtio.c | 2 +
fs/afs/cmservice.c | 3 +
fs/afs/rxrpc.c | 13 +++-
fs/btrfs/ctree.c | 18 ++++--
fs/btrfs/extent-tree.c | 1 +
fs/f2fs/file.c | 1 +
fs/fcntl.c | 5 +-
fs/nfs/dir.c | 2 +-
fs/pipe.c | 2 +-
fs/xfs/xfs_inode.c | 1 +
include/drm/drm_connector.h | 8 +++
include/linux/dma-mapping.h | 2 -
include/linux/genalloc.h | 3 +-
include/linux/hyperv.h | 1 +
include/linux/iio/timer/stm32-lptim-trigger.h | 5 +-
include/linux/sysfs.h | 6 ++
include/scsi/libsas.h | 2 +-
kernel/audit.c | 39 ++++++------
kernel/bpf/percpu_freelist.c | 8 ++-
kernel/cpu.c | 10 ++--
kernel/debug/kdb/kdb_io.c | 2 +-
kernel/jump_label.c | 2 +-
kernel/sysctl.c | 2 +-
lib/asn1_decoder.c | 49 ++++++++-------
lib/dynamic_debug.c | 4 ++
lib/genalloc.c | 10 ++--
mm/slub.c | 4 ++
mm/zsmalloc.c | 2 +-
net/ipv4/route.c | 14 +++--
net/ipv6/ip6_gre.c | 2 +-
net/sctp/socket.c | 38 ++++++++----
net/smc/smc_core.c | 2 +-
net/sunrpc/sched.c | 3 +-
net/tls/tls_sw.c | 2 +-
net/xfrm/xfrm_policy.c | 1 +
scripts/coccicheck | 15 +++--
scripts/package/Makefile | 9 ++-
security/apparmor/policy.c | 3 +-
security/keys/keyctl.c | 24 ++++----
security/keys/request_key.c | 46 +++++++++++---
sound/core/pcm.c | 2 +
sound/core/seq/seq_timer.c | 2 +-
sound/pci/hda/patch_realtek.c | 8 +++
sound/usb/mixer.c | 13 ++--
tools/hv/hv_kvp_daemon.c | 70 +++++-----------------
tools/testing/selftests/x86/mpx-hw.h | 4 +-
virt/kvm/arm/hyp/vgic-v2-sr.c | 4 --
virt/kvm/arm/vgic/vgic-irqfd.c | 3 +-
virt/kvm/arm/vgic/vgic-its.c | 2 +
virt/kvm/arm/vgic/vgic-v3.c | 2 +-
virt/kvm/kvm_main.c | 8 +++
162 files changed, 1132 insertions(+), 586 deletions(-)
Following commit 9427ecbed46cc ("gpio: Rework of_gpiochip_set_names()
to use device property accessors"), "gpio-line-names" DT property is
not retrieved anymore when chip->parent is not set by the driver.
This is due to OF based property reads having been replaced by device
based property reads.
This patch fixes that by making use of
fwnode_property_read_string_array() instead of
device_property_read_string_array() and handing over either
of_fwnode_handle(chip->of_node) or dev_fwnode(chip->parent)
to that function.
Fixes: 9427ecbed46cc ("gpio: Rework of_gpiochip_set_names() to use device property accessors")
Cc: stable(a)vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr>
---
drivers/gpio/gpiolib-acpi.c | 2 +-
drivers/gpio/gpiolib-devprop.c | 17 +++++++----------
drivers/gpio/gpiolib-of.c | 3 ++-
drivers/gpio/gpiolib.h | 3 ++-
4 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index eb4528c87c0b..d6f3d9ee1350 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -1074,7 +1074,7 @@ void acpi_gpiochip_add(struct gpio_chip *chip)
}
if (!chip->names)
- devprop_gpiochip_set_names(chip);
+ devprop_gpiochip_set_names(chip, dev_fwnode(chip->parent));
acpi_gpiochip_request_regions(acpi_gpio);
acpi_gpiochip_scan_gpios(acpi_gpio);
diff --git a/drivers/gpio/gpiolib-devprop.c b/drivers/gpio/gpiolib-devprop.c
index 27f383bda7d9..f748aa3e77f7 100644
--- a/drivers/gpio/gpiolib-devprop.c
+++ b/drivers/gpio/gpiolib-devprop.c
@@ -19,30 +19,27 @@
/**
* devprop_gpiochip_set_names - Set GPIO line names using device properties
* @chip: GPIO chip whose lines should be named, if possible
+ * @fwnode: Property Node containing the gpio-line-names property
*
* Looks for device property "gpio-line-names" and if it exists assigns
* GPIO line names for the chip. The memory allocated for the assigned
* names belong to the underlying firmware node and should not be released
* by the caller.
*/
-void devprop_gpiochip_set_names(struct gpio_chip *chip)
+void devprop_gpiochip_set_names(struct gpio_chip *chip,
+ const struct fwnode_handle *fwnode)
{
struct gpio_device *gdev = chip->gpiodev;
const char **names;
int ret, i;
- if (!chip->parent) {
- dev_warn(&gdev->dev, "GPIO chip parent is NULL\n");
- return;
- }
-
- ret = device_property_read_string_array(chip->parent, "gpio-line-names",
+ ret = fwnode_property_read_string_array(fwnode, "gpio-line-names",
NULL, 0);
if (ret < 0)
return;
if (ret != gdev->ngpio) {
- dev_warn(chip->parent,
+ dev_warn(&gdev->dev,
"names %d do not match number of GPIOs %d\n", ret,
gdev->ngpio);
return;
@@ -52,10 +49,10 @@ void devprop_gpiochip_set_names(struct gpio_chip *chip)
if (!names)
return;
- ret = device_property_read_string_array(chip->parent, "gpio-line-names",
+ ret = fwnode_property_read_string_array(fwnode, "gpio-line-names",
names, gdev->ngpio);
if (ret < 0) {
- dev_warn(chip->parent, "failed to read GPIO line names\n");
+ dev_warn(&gdev->dev, "failed to read GPIO line names\n");
kfree(names);
return;
}
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index e0d59e61b52f..72a0695d2ac3 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -493,7 +493,8 @@ int of_gpiochip_add(struct gpio_chip *chip)
/* If the chip defines names itself, these take precedence */
if (!chip->names)
- devprop_gpiochip_set_names(chip);
+ devprop_gpiochip_set_names(chip,
+ of_fwnode_handle(chip->of_node));
of_node_get(chip->of_node);
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index af48322839c3..6c44d1652139 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -228,7 +228,8 @@ static inline int gpio_chip_hwgpio(const struct gpio_desc *desc)
return desc - &desc->gdev->descs[0];
}
-void devprop_gpiochip_set_names(struct gpio_chip *chip);
+void devprop_gpiochip_set_names(struct gpio_chip *chip,
+ const struct fwnode_handle *fwnode);
/* With descriptor prefix */
--
2.13.3
Fix child-node lookup during initialisation which was using the wrong
OF-helper and ended up searching the whole device tree depth-first
starting at the parent rather than just matching on its children.
To make things worse, the parent pci node could end up being prematurely
freed as of_find_node_by_name() drops a reference to its first argument.
Any matching child interrupt-controller node was also leaked.
Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
Cc: stable <stable(a)vger.kernel.org> # 3.18
Acked-by: Murali Karicheri <m-karicheri2(a)ti.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
v2
- amend commit message and mention explicitly that of_find_node_by_name()
drops a reference to the start node
- add Murali's and Lorenzo's acks
drivers/pci/dwc/pci-keystone.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/dwc/pci-keystone.c b/drivers/pci/dwc/pci-keystone.c
index 5bee3af47588..39405598b22d 100644
--- a/drivers/pci/dwc/pci-keystone.c
+++ b/drivers/pci/dwc/pci-keystone.c
@@ -178,7 +178,7 @@ static int ks_pcie_get_irq_controller_info(struct keystone_pcie *ks_pcie,
}
/* interrupt controller is in a child node */
- *np_temp = of_find_node_by_name(np_pcie, controller);
+ *np_temp = of_get_child_by_name(np_pcie, controller);
if (!(*np_temp)) {
dev_err(dev, "Node for %s is absent\n", controller);
return -EINVAL;
@@ -187,6 +187,7 @@ static int ks_pcie_get_irq_controller_info(struct keystone_pcie *ks_pcie,
temp = of_irq_count(*np_temp);
if (!temp) {
dev_err(dev, "No IRQ entries in %s\n", controller);
+ of_node_put(*np_temp);
return -EINVAL;
}
@@ -204,6 +205,8 @@ static int ks_pcie_get_irq_controller_info(struct keystone_pcie *ks_pcie,
break;
}
+ of_node_put(*np_temp);
+
if (temp) {
*num_irqs = temp;
return 0;
--
2.15.0
We recently got an Oops report:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: jbd2__journal_start+0x38/0x1a2
[...]
Call Trace:
ext4_page_mkwrite+0x307/0x52b
_ext4_get_block+0xd8/0xd8
do_page_mkwrite+0x6e/0xd8
handle_mm_fault+0x686/0xf9b
mntput_no_expire+0x1f/0x21e
__do_page_fault+0x21d/0x465
dput+0x4a/0x2f7
page_fault+0x22/0x30
copy_user_generic_string+0x2c/0x40
copy_page_to_iter+0x8c/0x2b8
generic_file_read_iter+0x26e/0x845
timerqueue_del+0x31/0x90
ceph_read_iter+0x697/0xa33 [ceph]
hrtimer_cancel+0x23/0x41
futex_wait+0x1c8/0x24d
get_futex_key+0x32c/0x39a
__vfs_read+0xe0/0x130
vfs_read.part.1+0x6c/0x123
handle_mm_fault+0x831/0xf9b
__fget+0x7e/0xbf
SyS_read+0x4d/0xb5
ceph_read_iter() uses current->journal_info to pass context info to
ceph_readpages(). Because ceph_readpages() needs to know if its caller
has already gotten capability of using page cache (distinguish read
from readahead/fadvise). ceph_read_iter() set current->journal_info,
then calls generic_file_read_iter().
In above Oops, page fault happened when copying data to userspace.
Page fault handler called ext4_page_mkwrite(). Ext4 code read
current->journal_info and assumed it is journal handle.
I checked other filesystems, btrfs probably suffers similar problem
for its readpage. (page fault happens when write() copies data from
userspace memory and the memory is mapped to a file in btrfs.
verify_parent_transid() can be called during readpage)
Cc: stable(a)vger.kernel.org
Signed-off-by: "Yan, Zheng" <zyan(a)redhat.com>
---
mm/memory.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index a728bed16c20..db2a50233c49 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4044,6 +4044,7 @@ int handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
unsigned int flags)
{
int ret;
+ void *old_journal_info;
__set_current_state(TASK_RUNNING);
@@ -4065,11 +4066,24 @@ int handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
if (flags & FAULT_FLAG_USER)
mem_cgroup_oom_enable();
+ /*
+ * Fault can happen when filesystem A's read_iter()/write_iter()
+ * copies data to/from userspace. Filesystem A may have set
+ * current->journal_info. If the userspace memory is MAP_SHARED
+ * mapped to a file in filesystem B, we later may call filesystem
+ * B's vm operation. Filesystem B may also want to read/set
+ * current->journal_info.
+ */
+ old_journal_info = current->journal_info;
+ current->journal_info = NULL;
+
if (unlikely(is_vm_hugetlb_page(vma)))
ret = hugetlb_fault(vma->vm_mm, vma, address, flags);
else
ret = __handle_mm_fault(vma, address, flags);
+ current->journal_info = old_journal_info;
+
if (flags & FAULT_FLAG_USER) {
mem_cgroup_oom_disable();
/*
--
2.13.6
From: Ilan peer <ilan.peer(a)intel.com>
commit 57629915d568c522ac1422df7bba4bee5b5c7a7c upstream.
The code was setting the capabilities byte to zero,
after it was already properly set previously. Fix it.
The bug was found while debugging hwsim mesh tests failures
that happened since the commit mentioned below.
Fixes: 76f43b4c0a93 ("mac80211: Remove invalid flag operations in mesh TSF synchronization")
Signed-off-by: Ilan Peer <ilan.peer(a)intel.com>
Reviewed-by: Masashi Honma <masashi.honma(a)gmail.com>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Richard Schütz <rschuetz(a)uni-koblenz.de>
---
net/mac80211/mesh.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index cc2a63bd233f..9c23172feba0 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -279,8 +279,6 @@ int mesh_add_meshconf_ie(struct ieee80211_sub_if_data *sdata,
/* Mesh PS mode. See IEEE802.11-2012 8.4.2.100.8 */
*pos |= ifmsh->ps_peers_deep_sleep ?
IEEE80211_MESHCONF_CAPAB_POWER_SAVE_LEVEL : 0x00;
- *pos++ = 0x00;
-
return 0;
}
--
2.15.1
This is a note to let you know that I've just added the patch titled
media: dvb-core: always call invoke_release() in fe_free()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-dvb-core-always-call-invoke_release-in-fe_free.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 62229de19ff2b7f3e0ebf4d48ad99061127d0281 Mon Sep 17 00:00:00 2001
From: Daniel Scheller <d.scheller(a)gmx.net>
Date: Sun, 29 Oct 2017 11:43:22 -0400
Subject: media: dvb-core: always call invoke_release() in fe_free()
From: Daniel Scheller <d.scheller(a)gmx.net>
commit 62229de19ff2b7f3e0ebf4d48ad99061127d0281 upstream.
Follow-up to: ead666000a5f ("media: dvb_frontend: only use kref after initialized")
The aforementioned commit fixed refcount OOPSes when demod driver attaching
succeeded but tuner driver didn't. However, the use count of the attached
demod drivers don't go back to zero and thus couldn't be cleanly unloaded.
Improve on this by calling dvb_frontend_invoke_release() in
__dvb_frontend_free() regardless of fepriv being NULL, instead of returning
when fepriv is NULL. This is safe to do since _invoke_release() will check
for passed pointers being valid before calling the .release() function.
[mchehab(a)s-opensource.com: changed the logic a little bit to reduce
conflicts with another bug fix patch under review]
Fixes: ead666000a5f ("media: dvb_frontend: only use kref after initialized")
Signed-off-by: Daniel Scheller <d.scheller(a)gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/dvb-core/dvb_frontend.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -145,13 +145,14 @@ static void __dvb_frontend_free(struct d
{
struct dvb_frontend_private *fepriv = fe->frontend_priv;
- if (!fepriv)
- return;
-
- dvb_free_device(fepriv->dvbdev);
+ if (fepriv)
+ dvb_free_device(fepriv->dvbdev);
dvb_frontend_invoke_release(fe, fe->ops.release);
+ if (!fepriv)
+ return;
+
kfree(fepriv);
fe->frontend_priv = NULL;
}
Patches currently in stable-queue which might be from d.scheller(a)gmx.net are
queue-4.14/media-dvb-core-always-call-invoke_release-in-fe_free.patch
Hi Greg,
please apply the following two patches to v4.14-stable.
62229de19ff2 media: dvb-core: always call invoke_release() in fe_free()
b1cb7372fa82 dvb_frontend: don't use-after-free the frontend struct
The first patch fixes a bug and avoids a conflict when applying
the second patch, and the second patch fixes CVE-2017-16648.
My apologies for the noise if the patches are already queued.
Thanks,
Guenter
This is a note to let you know that I've just added the patch titled
RDMA/cxgb4: Annotate r2 and stag as __be32
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-cxgb4-annotate-r2-and-stag-as-__be32.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Leon Romanovsky <leon(a)kernel.org>
Date: Wed, 25 Oct 2017 23:10:19 +0300
Subject: RDMA/cxgb4: Annotate r2 and stag as __be32
From: Leon Romanovsky <leon(a)kernel.org>
[ Upstream commit 7d7d065a5eec7e218174d5c64a9f53f99ffdb119 ]
Chelsio cxgb4 HW is big-endian, hence there is need to properly
annotate r2 and stag fields as __be32 and not __u32 to fix the
following sparse warnings.
drivers/infiniband/hw/cxgb4/qp.c:614:16:
warning: incorrect type in assignment (different base types)
expected unsigned int [unsigned] [usertype] r2
got restricted __be32 [usertype] <noident>
drivers/infiniband/hw/cxgb4/qp.c:615:18:
warning: incorrect type in assignment (different base types)
expected unsigned int [unsigned] [usertype] stag
got restricted __be32 [usertype] <noident>
Cc: Steve Wise <swise(a)opengridcomputing.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Reviewed-by: Steve Wise <swise(a)opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/cxgb4/t4fw_ri_api.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/hw/cxgb4/t4fw_ri_api.h
+++ b/drivers/infiniband/hw/cxgb4/t4fw_ri_api.h
@@ -675,8 +675,8 @@ struct fw_ri_fr_nsmr_tpte_wr {
__u16 wrid;
__u8 r1[3];
__u8 len16;
- __u32 r2;
- __u32 stag;
+ __be32 r2;
+ __be32 stag;
struct fw_ri_tpte tpte;
__u64 pbl[2];
};
Patches currently in stable-queue which might be from leon(a)kernel.org are
queue-4.14/rdma-cxgb4-annotate-r2-and-stag-as-__be32.patch
This is a note to let you know that I've just added the patch titled
nvmet-rdma: update queue list during ib_device removal
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nvmet-rdma-update-queue-list-during-ib_device-removal.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Israel Rukshin <israelr(a)mellanox.com>
Date: Sun, 5 Nov 2017 08:43:01 +0000
Subject: nvmet-rdma: update queue list during ib_device removal
From: Israel Rukshin <israelr(a)mellanox.com>
[ Upstream commit 43b92fd27aaef0f529c9321cfebbaec1d7b8f503 ]
A NULL deref happens when nvmet_rdma_remove_one() is called more than once
(e.g. while connected via 2 ports).
The first call frees the queues related to the first ib_device but
doesn't remove them from the queue list.
While calling nvmet_rdma_remove_one() for the second ib_device it goes over
the full queue list again and we get the NULL deref.
Fixes: f1d4ef7d ("nvmet-rdma: register ib_client to not deadlock in device removal")
Signed-off-by: Israel Rukshin <israelr(a)mellanox.com>
Reviewed-by: Max Gurtovoy <maxg(a)mellanox.com>
Reviewed-by: Sagi Grimberg <sagi(a)grmberg.me>
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nvme/target/rdma.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/nvme/target/rdma.c
+++ b/drivers/nvme/target/rdma.c
@@ -1512,15 +1512,17 @@ static struct nvmet_fabrics_ops nvmet_rd
static void nvmet_rdma_remove_one(struct ib_device *ib_device, void *client_data)
{
- struct nvmet_rdma_queue *queue;
+ struct nvmet_rdma_queue *queue, *tmp;
/* Device is being removed, delete all queues using this device */
mutex_lock(&nvmet_rdma_queue_mutex);
- list_for_each_entry(queue, &nvmet_rdma_queue_list, queue_list) {
+ list_for_each_entry_safe(queue, tmp, &nvmet_rdma_queue_list,
+ queue_list) {
if (queue->dev->device != ib_device)
continue;
pr_info("Removing queue %d\n", queue->idx);
+ list_del_init(&queue->queue_list);
__nvmet_rdma_queue_disconnect(queue);
}
mutex_unlock(&nvmet_rdma_queue_mutex);
Patches currently in stable-queue which might be from israelr(a)mellanox.com are
queue-4.14/nvmet-rdma-update-queue-list-during-ib_device-removal.patch
This is a note to let you know that I've just added the patch titled
powerpc/powernv/idle: Round up latency and residency values
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-powernv-idle-round-up-latency-and-residency-values.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Vaidyanathan Srinivasan <svaidy(a)linux.vnet.ibm.com>
Date: Thu, 24 Aug 2017 00:28:41 +0530
Subject: powerpc/powernv/idle: Round up latency and residency values
From: Vaidyanathan Srinivasan <svaidy(a)linux.vnet.ibm.com>
[ Upstream commit 8d4e10e9ed9450e18fbbf6a8872be0eac9fd4999 ]
On PowerNV platforms, firmware provides exit latency and
target residency for each of the idle states in nano
seconds. Cpuidle framework expects the values in micro
seconds. Round up to nearest micro seconds to avoid errors
in cases where the values are defined as fractional micro
seconds.
Default idle state of 'snooze' has exit latency of zero. If
other states have fractional micro second exit latency, they
would get rounded down to zero micro second and make cpuidle
framework choose deeper idle state when snooze loop is the
right choice.
Reported-by: Anton Blanchard <anton(a)samba.org>
Signed-off-by: Vaidyanathan Srinivasan <svaidy(a)linux.vnet.ibm.com>
Reviewed-by: Gautham R. Shenoy <ego(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/cpuidle/cpuidle-powernv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -384,9 +384,9 @@ static int powernv_add_idle_states(void)
* Firmware passes residency and latency values in ns.
* cpuidle expects it in us.
*/
- exit_latency = latency_ns[i] / 1000;
+ exit_latency = DIV_ROUND_UP(latency_ns[i], 1000);
if (!rc)
- target_residency = residency_ns[i] / 1000;
+ target_residency = DIV_ROUND_UP(residency_ns[i], 1000);
else
target_residency = 0;
Patches currently in stable-queue which might be from svaidy(a)linux.vnet.ibm.com are
queue-4.14/powerpc-powernv-idle-round-up-latency-and-residency-values.patch
This is a note to let you know that I've just added the patch titled
kbuild: do not call cc-option before KBUILD_CFLAGS initialization
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kbuild-do-not-call-cc-option-before-kbuild_cflags-initialization.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Date: Thu, 12 Oct 2017 18:22:25 +0900
Subject: kbuild: do not call cc-option before KBUILD_CFLAGS initialization
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
[ Upstream commit 433dc2ebe7d17dd21cba7ad5c362d37323592236 ]
Some $(call cc-option,...) are invoked very early, even before
KBUILD_CFLAGS, etc. are initialized.
The returned string from $(call cc-option,...) depends on
KBUILD_CPPFLAGS, KBUILD_CFLAGS, and GCC_PLUGINS_CFLAGS.
Since they are exported, they are not empty when the top Makefile
is recursively invoked.
The recursion occurs in several places. For example, the top
Makefile invokes itself for silentoldconfig. "make tinyconfig",
"make rpm-pkg" are the cases, too.
In those cases, the second call of cc-option from the same line
runs a different shell command due to non-pristine KBUILD_CFLAGS.
To get the same result all the time, KBUILD_* and GCC_PLUGINS_CFLAGS
must be initialized before any call of cc-option. This avoids
garbage data in the .cache.mk file.
Move all calls of cc-option below the config targets because target
compiler flags are unnecessary for Kconfig.
Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Reviewed-by: Douglas Anderson <dianders(a)chromium.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Makefile | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
--- a/Makefile
+++ b/Makefile
@@ -373,9 +373,6 @@ LDFLAGS_MODULE =
CFLAGS_KERNEL =
AFLAGS_KERNEL =
LDFLAGS_vmlinux =
-CFLAGS_GCOV := -fprofile-arcs -ftest-coverage -fno-tree-loop-im $(call cc-disable-warning,maybe-uninitialized,)
-CFLAGS_KCOV := $(call cc-option,-fsanitize-coverage=trace-pc,)
-
# Use USERINCLUDE when you must reference the UAPI directories only.
USERINCLUDE := \
@@ -394,21 +391,19 @@ LINUXINCLUDE := \
-I$(objtree)/include \
$(USERINCLUDE)
-KBUILD_CPPFLAGS := -D__KERNEL__
-
+KBUILD_AFLAGS := -D__ASSEMBLY__
KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common -fshort-wchar \
-Werror-implicit-function-declaration \
-Wno-format-security \
- -std=gnu89 $(call cc-option,-fno-PIE)
-
-
+ -std=gnu89
+KBUILD_CPPFLAGS := -D__KERNEL__
KBUILD_AFLAGS_KERNEL :=
KBUILD_CFLAGS_KERNEL :=
-KBUILD_AFLAGS := -D__ASSEMBLY__ $(call cc-option,-fno-PIE)
KBUILD_AFLAGS_MODULE := -DMODULE
KBUILD_CFLAGS_MODULE := -DMODULE
KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds
+GCC_PLUGINS_CFLAGS :=
# Read KERNELRELEASE from include/config/kernel.release (if it exists)
KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
@@ -421,7 +416,7 @@ export MAKE AWK GENKSYMS INSTALLKERNEL P
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
-export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV CFLAGS_KCOV CFLAGS_KASAN CFLAGS_UBSAN
+export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_KASAN CFLAGS_UBSAN
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
@@ -622,6 +617,12 @@ endif
# Defaults to vmlinux, but the arch makefile usually adds further targets
all: vmlinux
+KBUILD_CFLAGS += $(call cc-option,-fno-PIE)
+KBUILD_AFLAGS += $(call cc-option,-fno-PIE)
+CFLAGS_GCOV := -fprofile-arcs -ftest-coverage -fno-tree-loop-im $(call cc-disable-warning,maybe-uninitialized,)
+CFLAGS_KCOV := $(call cc-option,-fsanitize-coverage=trace-pc,)
+export CFLAGS_GCOV CFLAGS_KCOV
+
# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
# values of the respective KBUILD_* variables
ARCH_CPPFLAGS :=
Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are
queue-4.14/kbuild-do-not-call-cc-option-before-kbuild_cflags-initialization.patch
This is a note to let you know that I've just added the patch titled
md: free unused memory after bitmap resize
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
md-free-unused-memory-after-bitmap-resize.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Zdenek Kabelac <zkabelac(a)redhat.com>
Date: Wed, 8 Nov 2017 13:44:56 +0100
Subject: md: free unused memory after bitmap resize
From: Zdenek Kabelac <zkabelac(a)redhat.com>
[ Upstream commit 0868b99c214a3d55486c700de7c3f770b7243e7c ]
When bitmap is resized, the old kalloced chunks just are not released
once the resized bitmap starts to use new space.
This fixes in particular kmemleak reports like this one:
unreferenced object 0xffff8f4311e9c000 (size 4096):
comm "lvm", pid 19333, jiffies 4295263268 (age 528.265s)
hex dump (first 32 bytes):
02 80 02 80 02 80 02 80 02 80 02 80 02 80 02 80 ................
02 80 02 80 02 80 02 80 02 80 02 80 02 80 02 80 ................
backtrace:
[<ffffffffa69471ca>] kmemleak_alloc+0x4a/0xa0
[<ffffffffa628c10e>] kmem_cache_alloc_trace+0x14e/0x2e0
[<ffffffffa676cfec>] bitmap_checkpage+0x7c/0x110
[<ffffffffa676d0c5>] bitmap_get_counter+0x45/0xd0
[<ffffffffa676d6b3>] bitmap_set_memory_bits+0x43/0xe0
[<ffffffffa676e41c>] bitmap_init_from_disk+0x23c/0x530
[<ffffffffa676f1ae>] bitmap_load+0xbe/0x160
[<ffffffffc04c47d3>] raid_preresume+0x203/0x2f0 [dm_raid]
[<ffffffffa677762f>] dm_table_resume_targets+0x4f/0xe0
[<ffffffffa6774b52>] dm_resume+0x122/0x140
[<ffffffffa6779b9f>] dev_suspend+0x18f/0x290
[<ffffffffa677a3a7>] ctl_ioctl+0x287/0x560
[<ffffffffa677a693>] dm_ctl_ioctl+0x13/0x20
[<ffffffffa62d6b46>] do_vfs_ioctl+0xa6/0x750
[<ffffffffa62d7269>] SyS_ioctl+0x79/0x90
[<ffffffffa6956d41>] entry_SYSCALL_64_fastpath+0x1f/0xc2
Signed-off-by: Zdenek Kabelac <zkabelac(a)redhat.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bitmap.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -2158,6 +2158,7 @@ int bitmap_resize(struct bitmap *bitmap,
for (k = 0; k < page; k++) {
kfree(new_bp[k].map);
}
+ kfree(new_bp);
/* restore some fields from old_counts */
bitmap->counts.bp = old_counts.bp;
@@ -2208,6 +2209,14 @@ int bitmap_resize(struct bitmap *bitmap,
block += old_blocks;
}
+ if (bitmap->counts.bp != old_counts.bp) {
+ unsigned long k;
+ for (k = 0; k < old_counts.pages; k++)
+ if (!old_counts.bp[k].hijacked)
+ kfree(old_counts.bp[k].map);
+ kfree(old_counts.bp);
+ }
+
if (!init) {
int i;
while (block < (chunks << chunkshift)) {
Patches currently in stable-queue which might be from zkabelac(a)redhat.com are
queue-4.14/md-free-unused-memory-after-bitmap-resize.patch
This is a note to let you know that I've just added the patch titled
ipvlan: fix ipv6 outbound device
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipvlan-fix-ipv6-outbound-device.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Keefe Liu <liuqifa(a)huawei.com>
Date: Thu, 9 Nov 2017 20:09:31 +0800
Subject: ipvlan: fix ipv6 outbound device
From: Keefe Liu <liuqifa(a)huawei.com>
[ Upstream commit ca29fd7cce5a6444d57fb86517589a1a31c759e1 ]
When process the outbound packet of ipv6, we should assign the master
device to output device other than input device.
Signed-off-by: Keefe Liu <liuqifa(a)huawei.com>
Acked-by: Mahesh Bandewar <maheshb(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ipvlan/ipvlan_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -409,7 +409,7 @@ static int ipvlan_process_v6_outbound(st
struct dst_entry *dst;
int err, ret = NET_XMIT_DROP;
struct flowi6 fl6 = {
- .flowi6_iif = dev->ifindex,
+ .flowi6_oif = dev->ifindex,
.daddr = ip6h->daddr,
.saddr = ip6h->saddr,
.flowi6_flags = FLOWI_FLAG_ANYSRC,
Patches currently in stable-queue which might be from liuqifa(a)huawei.com are
queue-4.14/ipvlan-fix-ipv6-outbound-device.patch
This is a note to let you know that I've just added the patch titled
dm raid: fix panic when attempting to force a raid to sync
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dm-raid-fix-panic-when-attempting-to-force-a-raid-to-sync.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Heinz Mauelshagen <heinzm(a)redhat.com>
Date: Thu, 2 Nov 2017 19:58:28 +0100
Subject: dm raid: fix panic when attempting to force a raid to sync
From: Heinz Mauelshagen <heinzm(a)redhat.com>
[ Upstream commit 233978449074ca7e45d9c959f9ec612d1b852893 ]
Requesting a sync on an active raid device via a table reload
(see 'sync' parameter in Documentation/device-mapper/dm-raid.txt)
skips the super_load() call that defines the superblock size
(rdev->sb_size) -- resulting in an oops if/when super_sync()->memset()
is called.
Fix by moving the initialization of the superblock start and size
out of super_load() to the caller (analyse_superblocks).
Signed-off-by: Heinz Mauelshagen <heinzm(a)redhat.com>
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/dm-raid.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -2143,13 +2143,6 @@ static int super_load(struct md_rdev *rd
struct dm_raid_superblock *refsb;
uint64_t events_sb, events_refsb;
- rdev->sb_start = 0;
- rdev->sb_size = bdev_logical_block_size(rdev->meta_bdev);
- if (rdev->sb_size < sizeof(*sb) || rdev->sb_size > PAGE_SIZE) {
- DMERR("superblock size of a logical block is no longer valid");
- return -EINVAL;
- }
-
r = read_disk_sb(rdev, rdev->sb_size, false);
if (r)
return r;
@@ -2494,6 +2487,17 @@ static int analyse_superblocks(struct dm
if (test_bit(Journal, &rdev->flags))
continue;
+ if (!rdev->meta_bdev)
+ continue;
+
+ /* Set superblock offset/size for metadata device. */
+ rdev->sb_start = 0;
+ rdev->sb_size = bdev_logical_block_size(rdev->meta_bdev);
+ if (rdev->sb_size < sizeof(struct dm_raid_superblock) || rdev->sb_size > PAGE_SIZE) {
+ DMERR("superblock size of a logical block is no longer valid");
+ return -EINVAL;
+ }
+
/*
* Skipping super_load due to CTR_FLAG_SYNC will cause
* the array to undergo initialization again as
@@ -2506,9 +2510,6 @@ static int analyse_superblocks(struct dm
if (test_bit(__CTR_FLAG_SYNC, &rs->ctr_flags))
continue;
- if (!rdev->meta_bdev)
- continue;
-
r = super_load(rdev, freshest);
switch (r) {
Patches currently in stable-queue which might be from heinzm(a)redhat.com are
queue-4.14/dm-raid-fix-panic-when-attempting-to-force-a-raid-to-sync.patch
This is a note to let you know that I've just added the patch titled
ide: ide-atapi: fix compile error with defining macro DEBUG
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ide-ide-atapi-fix-compile-error-with-defining-macro-debug.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Hongxu Jia <hongxu.jia(a)windriver.com>
Date: Fri, 10 Nov 2017 15:59:17 +0800
Subject: ide: ide-atapi: fix compile error with defining macro DEBUG
From: Hongxu Jia <hongxu.jia(a)windriver.com>
[ Upstream commit 8dc7a31fbce5e2dbbacd83d910da37105181b054 ]
Compile ide-atapi failed with defining macro "DEBUG"
...
|drivers/ide/ide-atapi.c:285:52: error: 'struct request' has
no member named 'cmd'; did you mean 'csd'?
| debug_log("%s: rq->cmd[0]: 0x%x\n", __func__, rq->cmd[0]);
...
Since we split the scsi_request out of struct request, it missed
do the same thing on debug_log
Fixes: 82ed4db499b8 ("block: split scsi_request out of struct request")
Signed-off-by: Hongxu Jia <hongxu.jia(a)windriver.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ide/ide-atapi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/ide/ide-atapi.c
+++ b/drivers/ide/ide-atapi.c
@@ -282,7 +282,7 @@ int ide_cd_expiry(ide_drive_t *drive)
struct request *rq = drive->hwif->rq;
unsigned long wait = 0;
- debug_log("%s: rq->cmd[0]: 0x%x\n", __func__, rq->cmd[0]);
+ debug_log("%s: scsi_req(rq)->cmd[0]: 0x%x\n", __func__, scsi_req(rq)->cmd[0]);
/*
* Some commands are *slow* and normally take a long time to complete.
@@ -463,7 +463,7 @@ static ide_startstop_t ide_pc_intr(ide_d
return ide_do_reset(drive);
}
- debug_log("[cmd %x]: check condition\n", rq->cmd[0]);
+ debug_log("[cmd %x]: check condition\n", scsi_req(rq)->cmd[0]);
/* Retry operation */
ide_retry_pc(drive);
@@ -531,7 +531,7 @@ static ide_startstop_t ide_pc_intr(ide_d
ide_pad_transfer(drive, write, bcount);
debug_log("[cmd %x] transferred %d bytes, padded %d bytes, resid: %u\n",
- rq->cmd[0], done, bcount, scsi_req(rq)->resid_len);
+ scsi_req(rq)->cmd[0], done, bcount, scsi_req(rq)->resid_len);
/* And set the interrupt handler again */
ide_set_handler(drive, ide_pc_intr, timeout);
Patches currently in stable-queue which might be from hongxu.jia(a)windriver.com are
queue-4.14/ide-ide-atapi-fix-compile-error-with-defining-macro-debug.patch
This is a note to let you know that I've just added the patch titled
audit: ensure that 'audit=1' actually enables audit for PID 1
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
audit-ensure-that-audit-1-actually-enables-audit-for-pid-1.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Paul Moore <paul(a)paul-moore.com>
Date: Fri, 1 Sep 2017 09:44:34 -0400
Subject: audit: ensure that 'audit=1' actually enables audit for PID 1
From: Paul Moore <paul(a)paul-moore.com>
[ Upstream commit 173743dd99a49c956b124a74c8aacb0384739a4c ]
Prior to this patch we enabled audit in audit_init(), which is too
late for PID 1 as the standard initcalls are run after the PID 1 task
is forked. This means that we never allocate an audit_context (see
audit_alloc()) for PID 1 and therefore miss a lot of audit events
generated by PID 1.
This patch enables audit as early as possible to help ensure that when
PID 1 is forked it can allocate an audit_context if required.
Reviewed-by: Richard Guy Briggs <rgb(a)redhat.com>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/audit.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -85,13 +85,13 @@ static int audit_initialized;
#define AUDIT_OFF 0
#define AUDIT_ON 1
#define AUDIT_LOCKED 2
-u32 audit_enabled;
-u32 audit_ever_enabled;
+u32 audit_enabled = AUDIT_OFF;
+u32 audit_ever_enabled = !!AUDIT_OFF;
EXPORT_SYMBOL_GPL(audit_enabled);
/* Default state when kernel boots without any parameters. */
-static u32 audit_default;
+static u32 audit_default = AUDIT_OFF;
/* If auditing cannot proceed, audit_failure selects what happens. */
static u32 audit_failure = AUDIT_FAIL_PRINTK;
@@ -1552,8 +1552,6 @@ static int __init audit_init(void)
register_pernet_subsys(&audit_net_ops);
audit_initialized = AUDIT_INITIALIZED;
- audit_enabled = audit_default;
- audit_ever_enabled |= !!audit_default;
kauditd_task = kthread_run(kauditd_thread, NULL, "kauditd");
if (IS_ERR(kauditd_task)) {
@@ -1575,6 +1573,8 @@ static int __init audit_enable(char *str
audit_default = !!simple_strtol(str, NULL, 0);
if (!audit_default)
audit_initialized = AUDIT_DISABLED;
+ audit_enabled = audit_default;
+ audit_ever_enabled = !!audit_enabled;
pr_info("%s\n", audit_default ?
"enabled (after initialization)" : "disabled (until reboot)");
Patches currently in stable-queue which might be from paul(a)paul-moore.com are
queue-4.14/audit-allow-auditd-to-set-pid-to-0-to-end-auditing.patch
queue-4.14/audit-ensure-that-audit-1-actually-enables-audit-for-pid-1.patch
This is a note to let you know that I've just added the patch titled
blk-mq: Avoid that request queue removal can trigger list corruption
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
blk-mq-avoid-that-request-queue-removal-can-trigger-list-corruption.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Wed, 8 Nov 2017 10:23:45 -0800
Subject: blk-mq: Avoid that request queue removal can trigger list corruption
From: Bart Van Assche <bart.vanassche(a)wdc.com>
[ Upstream commit aba7afc5671c23beade64d10caf86e24a9105dab ]
Avoid that removal of a request queue sporadically triggers the
following warning:
list_del corruption. next->prev should be ffff8807d649b970, but was 6b6b6b6b6b6b6b6b
WARNING: CPU: 3 PID: 342 at lib/list_debug.c:56 __list_del_entry_valid+0x92/0xa0
Call Trace:
process_one_work+0x11b/0x660
worker_thread+0x3d/0x3b0
kthread+0x129/0x140
ret_from_fork+0x27/0x40
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Johannes Thumshirn <jthumshirn(a)suse.de>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-core.c | 1 +
1 file changed, 1 insertion(+)
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -339,6 +339,7 @@ void blk_sync_queue(struct request_queue
struct blk_mq_hw_ctx *hctx;
int i;
+ cancel_delayed_work_sync(&q->requeue_work);
queue_for_each_hw_ctx(q, hctx, i)
cancel_delayed_work_sync(&hctx->run_work);
} else {
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-4.14/blk-mq-avoid-that-request-queue-removal-can-trigger-list-corruption.patch
This is a note to let you know that I've just added the patch titled
audit: Allow auditd to set pid to 0 to end auditing
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
audit-allow-auditd-to-set-pid-to-0-to-end-auditing.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 10:32:42 CET 2017
From: Steve Grubb <sgrubb(a)redhat.com>
Date: Tue, 17 Oct 2017 18:29:22 -0400
Subject: audit: Allow auditd to set pid to 0 to end auditing
From: Steve Grubb <sgrubb(a)redhat.com>
[ Upstream commit 33e8a907804428109ce1d12301c3365d619cc4df ]
The API to end auditing has historically been for auditd to set the
pid to 0. This patch restores that functionality.
See: https://github.com/linux-audit/audit-kernel/issues/69
Reviewed-by: Richard Guy Briggs <rgb(a)redhat.com>
Signed-off-by: Steve Grubb <sgrubb(a)redhat.com>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/audit.c | 29 ++++++++++++++++-------------
1 file changed, 16 insertions(+), 13 deletions(-)
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1197,25 +1197,28 @@ static int audit_receive_msg(struct sk_b
pid_t auditd_pid;
struct pid *req_pid = task_tgid(current);
- /* sanity check - PID values must match */
- if (new_pid != pid_vnr(req_pid))
+ /* Sanity check - PID values must match. Setting
+ * pid to 0 is how auditd ends auditing. */
+ if (new_pid && (new_pid != pid_vnr(req_pid)))
return -EINVAL;
/* test the auditd connection */
audit_replace(req_pid);
auditd_pid = auditd_pid_vnr();
- /* only the current auditd can unregister itself */
- if ((!new_pid) && (new_pid != auditd_pid)) {
- audit_log_config_change("audit_pid", new_pid,
- auditd_pid, 0);
- return -EACCES;
- }
- /* replacing a healthy auditd is not allowed */
- if (auditd_pid && new_pid) {
- audit_log_config_change("audit_pid", new_pid,
- auditd_pid, 0);
- return -EEXIST;
+ if (auditd_pid) {
+ /* replacing a healthy auditd is not allowed */
+ if (new_pid) {
+ audit_log_config_change("audit_pid",
+ new_pid, auditd_pid, 0);
+ return -EEXIST;
+ }
+ /* only current auditd can unregister itself */
+ if (pid_vnr(req_pid) != auditd_pid) {
+ audit_log_config_change("audit_pid",
+ new_pid, auditd_pid, 0);
+ return -EACCES;
+ }
}
if (new_pid) {
Patches currently in stable-queue which might be from sgrubb(a)redhat.com are
queue-4.14/audit-allow-auditd-to-set-pid-to-0-to-end-auditing.patch
Hi,
I thought the problem was fixed, but I still see:
arch/powerpc/include/asm/checksum.h:103:2: error:
implicit declaration of function 'from64to32'
when building powerpc images (eg powerpc:defconfig).
This is with v4.9.69-20-g78542f2. v4.9.69 fails as well.
Guenter
This is a note to let you know that I've just added the patch titled
RDMA/cxgb4: Annotate r2 and stag as __be32
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rdma-cxgb4-annotate-r2-and-stag-as-__be32.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 13:26:17 CET 2017
From: Leon Romanovsky <leon(a)kernel.org>
Date: Wed, 25 Oct 2017 23:10:19 +0300
Subject: RDMA/cxgb4: Annotate r2 and stag as __be32
From: Leon Romanovsky <leon(a)kernel.org>
[ Upstream commit 7d7d065a5eec7e218174d5c64a9f53f99ffdb119 ]
Chelsio cxgb4 HW is big-endian, hence there is need to properly
annotate r2 and stag fields as __be32 and not __u32 to fix the
following sparse warnings.
drivers/infiniband/hw/cxgb4/qp.c:614:16:
warning: incorrect type in assignment (different base types)
expected unsigned int [unsigned] [usertype] r2
got restricted __be32 [usertype] <noident>
drivers/infiniband/hw/cxgb4/qp.c:615:18:
warning: incorrect type in assignment (different base types)
expected unsigned int [unsigned] [usertype] stag
got restricted __be32 [usertype] <noident>
Cc: Steve Wise <swise(a)opengridcomputing.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Reviewed-by: Steve Wise <swise(a)opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/cxgb4/t4fw_ri_api.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/hw/cxgb4/t4fw_ri_api.h
+++ b/drivers/infiniband/hw/cxgb4/t4fw_ri_api.h
@@ -675,8 +675,8 @@ struct fw_ri_fr_nsmr_tpte_wr {
__u16 wrid;
__u8 r1[3];
__u8 len16;
- __u32 r2;
- __u32 stag;
+ __be32 r2;
+ __be32 stag;
struct fw_ri_tpte tpte;
__u64 pbl[2];
};
Patches currently in stable-queue which might be from leon(a)kernel.org are
queue-4.9/rdma-cxgb4-annotate-r2-and-stag-as-__be32.patch
This is a note to let you know that I've just added the patch titled
powerpc/64: Fix checksum folding in csum_tcpudp_nofold and ip_fast_csum_nofold
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-64-fix-checksum-folding-in-csum_tcpudp_nofold-and-ip_fast_csum_nofold.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b492f7e4e07a28e706db26cf4943bb0911435426 Mon Sep 17 00:00:00 2001
From: Paul Mackerras <paulus(a)ozlabs.org>
Date: Thu, 3 Nov 2016 16:10:55 +1100
Subject: powerpc/64: Fix checksum folding in csum_tcpudp_nofold and ip_fast_csum_nofold
From: Paul Mackerras <paulus(a)ozlabs.org>
commit b492f7e4e07a28e706db26cf4943bb0911435426 upstream.
These functions compute an IP checksum by computing a 64-bit sum and
folding it to 32 bits (the "nofold" in their names refers to folding
down to 16 bits). However, doing (u32) (s + (s >> 32)) is not
sufficient to fold a 64-bit sum to 32 bits correctly. The addition
can produce a carry out from bit 31, which needs to be added in to
the sum to produce the correct result.
To fix this, we copy the from64to32() function from lib/checksum.c
and use that.
Signed-off-by: Paul Mackerras <paulus(a)ozlabs.org>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/include/asm/checksum.h | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/arch/powerpc/include/asm/checksum.h
+++ b/arch/powerpc/include/asm/checksum.h
@@ -53,17 +53,25 @@ static inline __sum16 csum_fold(__wsum s
return (__force __sum16)(~((__force u32)sum + tmp) >> 16);
}
+static inline u32 from64to32(u64 x)
+{
+ /* add up 32-bit and 32-bit for 32+c bit */
+ x = (x & 0xffffffff) + (x >> 32);
+ /* add up carry.. */
+ x = (x & 0xffffffff) + (x >> 32);
+ return (u32)x;
+}
+
static inline __wsum csum_tcpudp_nofold(__be32 saddr, __be32 daddr, __u32 len,
__u8 proto, __wsum sum)
{
#ifdef __powerpc64__
- unsigned long s = (__force u32)sum;
+ u64 s = (__force u32)sum;
s += (__force u32)saddr;
s += (__force u32)daddr;
s += proto + len;
- s += (s >> 32);
- return (__force __wsum) s;
+ return (__force __wsum) from64to32(s);
#else
__asm__("\n\
addc %0,%0,%1 \n\
@@ -123,8 +131,7 @@ static inline __wsum ip_fast_csum_nofold
for (i = 0; i < ihl - 1; i++, ptr++)
s += *ptr;
- s += (s >> 32);
- return (__force __wsum)s;
+ return (__force __wsum)from64to32(s);
#else
__wsum sum, tmp;
Patches currently in stable-queue which might be from paulus(a)ozlabs.org are
queue-4.9/powerpc-64-fix-checksum-folding-in-csum_tcpudp_nofold-and-ip_fast_csum_nofold.patch
This is a note to let you know that I've just added the patch titled
md: free unused memory after bitmap resize
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
md-free-unused-memory-after-bitmap-resize.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 13:26:17 CET 2017
From: Zdenek Kabelac <zkabelac(a)redhat.com>
Date: Wed, 8 Nov 2017 13:44:56 +0100
Subject: md: free unused memory after bitmap resize
From: Zdenek Kabelac <zkabelac(a)redhat.com>
[ Upstream commit 0868b99c214a3d55486c700de7c3f770b7243e7c ]
When bitmap is resized, the old kalloced chunks just are not released
once the resized bitmap starts to use new space.
This fixes in particular kmemleak reports like this one:
unreferenced object 0xffff8f4311e9c000 (size 4096):
comm "lvm", pid 19333, jiffies 4295263268 (age 528.265s)
hex dump (first 32 bytes):
02 80 02 80 02 80 02 80 02 80 02 80 02 80 02 80 ................
02 80 02 80 02 80 02 80 02 80 02 80 02 80 02 80 ................
backtrace:
[<ffffffffa69471ca>] kmemleak_alloc+0x4a/0xa0
[<ffffffffa628c10e>] kmem_cache_alloc_trace+0x14e/0x2e0
[<ffffffffa676cfec>] bitmap_checkpage+0x7c/0x110
[<ffffffffa676d0c5>] bitmap_get_counter+0x45/0xd0
[<ffffffffa676d6b3>] bitmap_set_memory_bits+0x43/0xe0
[<ffffffffa676e41c>] bitmap_init_from_disk+0x23c/0x530
[<ffffffffa676f1ae>] bitmap_load+0xbe/0x160
[<ffffffffc04c47d3>] raid_preresume+0x203/0x2f0 [dm_raid]
[<ffffffffa677762f>] dm_table_resume_targets+0x4f/0xe0
[<ffffffffa6774b52>] dm_resume+0x122/0x140
[<ffffffffa6779b9f>] dev_suspend+0x18f/0x290
[<ffffffffa677a3a7>] ctl_ioctl+0x287/0x560
[<ffffffffa677a693>] dm_ctl_ioctl+0x13/0x20
[<ffffffffa62d6b46>] do_vfs_ioctl+0xa6/0x750
[<ffffffffa62d7269>] SyS_ioctl+0x79/0x90
[<ffffffffa6956d41>] entry_SYSCALL_64_fastpath+0x1f/0xc2
Signed-off-by: Zdenek Kabelac <zkabelac(a)redhat.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bitmap.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -2084,6 +2084,7 @@ int bitmap_resize(struct bitmap *bitmap,
for (k = 0; k < page; k++) {
kfree(new_bp[k].map);
}
+ kfree(new_bp);
/* restore some fields from old_counts */
bitmap->counts.bp = old_counts.bp;
@@ -2134,6 +2135,14 @@ int bitmap_resize(struct bitmap *bitmap,
block += old_blocks;
}
+ if (bitmap->counts.bp != old_counts.bp) {
+ unsigned long k;
+ for (k = 0; k < old_counts.pages; k++)
+ if (!old_counts.bp[k].hijacked)
+ kfree(old_counts.bp[k].map);
+ kfree(old_counts.bp);
+ }
+
if (!init) {
int i;
while (block < (chunks << chunkshift)) {
Patches currently in stable-queue which might be from zkabelac(a)redhat.com are
queue-4.9/md-free-unused-memory-after-bitmap-resize.patch
This is a note to let you know that I've just added the patch titled
kbuild: do not call cc-option before KBUILD_CFLAGS initialization
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kbuild-do-not-call-cc-option-before-kbuild_cflags-initialization.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 13:26:17 CET 2017
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Date: Thu, 12 Oct 2017 18:22:25 +0900
Subject: kbuild: do not call cc-option before KBUILD_CFLAGS initialization
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
[ Upstream commit 433dc2ebe7d17dd21cba7ad5c362d37323592236 ]
Some $(call cc-option,...) are invoked very early, even before
KBUILD_CFLAGS, etc. are initialized.
The returned string from $(call cc-option,...) depends on
KBUILD_CPPFLAGS, KBUILD_CFLAGS, and GCC_PLUGINS_CFLAGS.
Since they are exported, they are not empty when the top Makefile
is recursively invoked.
The recursion occurs in several places. For example, the top
Makefile invokes itself for silentoldconfig. "make tinyconfig",
"make rpm-pkg" are the cases, too.
In those cases, the second call of cc-option from the same line
runs a different shell command due to non-pristine KBUILD_CFLAGS.
To get the same result all the time, KBUILD_* and GCC_PLUGINS_CFLAGS
must be initialized before any call of cc-option. This avoids
garbage data in the .cache.mk file.
Move all calls of cc-option below the config targets because target
compiler flags are unnecessary for Kconfig.
Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Reviewed-by: Douglas Anderson <dianders(a)chromium.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
Makefile | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
--- a/Makefile
+++ b/Makefile
@@ -370,9 +370,6 @@ LDFLAGS_MODULE =
CFLAGS_KERNEL =
AFLAGS_KERNEL =
LDFLAGS_vmlinux =
-CFLAGS_GCOV := -fprofile-arcs -ftest-coverage -fno-tree-loop-im $(call cc-disable-warning,maybe-uninitialized,)
-CFLAGS_KCOV := $(call cc-option,-fsanitize-coverage=trace-pc,)
-
# Use USERINCLUDE when you must reference the UAPI directories only.
USERINCLUDE := \
@@ -393,21 +390,19 @@ LINUXINCLUDE := \
LINUXINCLUDE += $(filter-out $(LINUXINCLUDE),$(USERINCLUDE))
-KBUILD_CPPFLAGS := -D__KERNEL__
-
+KBUILD_AFLAGS := -D__ASSEMBLY__
KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common \
-Werror-implicit-function-declaration \
-Wno-format-security \
- -std=gnu89 $(call cc-option,-fno-PIE)
-
-
+ -std=gnu89
+KBUILD_CPPFLAGS := -D__KERNEL__
KBUILD_AFLAGS_KERNEL :=
KBUILD_CFLAGS_KERNEL :=
-KBUILD_AFLAGS := -D__ASSEMBLY__ $(call cc-option,-fno-PIE)
KBUILD_AFLAGS_MODULE := -DMODULE
KBUILD_CFLAGS_MODULE := -DMODULE
KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds
+GCC_PLUGINS_CFLAGS :=
# Read KERNELRELEASE from include/config/kernel.release (if it exists)
KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
@@ -420,7 +415,7 @@ export MAKE AWK GENKSYMS INSTALLKERNEL P
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
-export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV CFLAGS_KCOV CFLAGS_KASAN CFLAGS_UBSAN
+export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_KASAN CFLAGS_UBSAN
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
@@ -620,6 +615,12 @@ endif
# Defaults to vmlinux, but the arch makefile usually adds further targets
all: vmlinux
+KBUILD_CFLAGS += $(call cc-option,-fno-PIE)
+KBUILD_AFLAGS += $(call cc-option,-fno-PIE)
+CFLAGS_GCOV := -fprofile-arcs -ftest-coverage -fno-tree-loop-im $(call cc-disable-warning,maybe-uninitialized,)
+CFLAGS_KCOV := $(call cc-option,-fsanitize-coverage=trace-pc,)
+export CFLAGS_GCOV CFLAGS_KCOV
+
# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
# values of the respective KBUILD_* variables
ARCH_CPPFLAGS :=
Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are
queue-4.9/kbuild-do-not-call-cc-option-before-kbuild_cflags-initialization.patch
This is a note to let you know that I've just added the patch titled
ipvlan: fix ipv6 outbound device
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipvlan-fix-ipv6-outbound-device.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 13:26:17 CET 2017
From: Keefe Liu <liuqifa(a)huawei.com>
Date: Thu, 9 Nov 2017 20:09:31 +0800
Subject: ipvlan: fix ipv6 outbound device
From: Keefe Liu <liuqifa(a)huawei.com>
[ Upstream commit ca29fd7cce5a6444d57fb86517589a1a31c759e1 ]
When process the outbound packet of ipv6, we should assign the master
device to output device other than input device.
Signed-off-by: Keefe Liu <liuqifa(a)huawei.com>
Acked-by: Mahesh Bandewar <maheshb(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ipvlan/ipvlan_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -404,7 +404,7 @@ static int ipvlan_process_v6_outbound(st
struct dst_entry *dst;
int err, ret = NET_XMIT_DROP;
struct flowi6 fl6 = {
- .flowi6_iif = dev->ifindex,
+ .flowi6_oif = dev->ifindex,
.daddr = ip6h->daddr,
.saddr = ip6h->saddr,
.flowi6_flags = FLOWI_FLAG_ANYSRC,
Patches currently in stable-queue which might be from liuqifa(a)huawei.com are
queue-4.9/ipvlan-fix-ipv6-outbound-device.patch
This is a note to let you know that I've just added the patch titled
audit: ensure that 'audit=1' actually enables audit for PID 1
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
audit-ensure-that-audit-1-actually-enables-audit-for-pid-1.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Dec 12 13:26:17 CET 2017
From: Paul Moore <paul(a)paul-moore.com>
Date: Fri, 1 Sep 2017 09:44:34 -0400
Subject: audit: ensure that 'audit=1' actually enables audit for PID 1
From: Paul Moore <paul(a)paul-moore.com>
[ Upstream commit 173743dd99a49c956b124a74c8aacb0384739a4c ]
Prior to this patch we enabled audit in audit_init(), which is too
late for PID 1 as the standard initcalls are run after the PID 1 task
is forked. This means that we never allocate an audit_context (see
audit_alloc()) for PID 1 and therefore miss a lot of audit events
generated by PID 1.
This patch enables audit as early as possible to help ensure that when
PID 1 is forked it can allocate an audit_context if required.
Reviewed-by: Richard Guy Briggs <rgb(a)redhat.com>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/audit.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -79,13 +79,13 @@ static int audit_initialized;
#define AUDIT_OFF 0
#define AUDIT_ON 1
#define AUDIT_LOCKED 2
-u32 audit_enabled;
-u32 audit_ever_enabled;
+u32 audit_enabled = AUDIT_OFF;
+u32 audit_ever_enabled = !!AUDIT_OFF;
EXPORT_SYMBOL_GPL(audit_enabled);
/* Default state when kernel boots without any parameters. */
-static u32 audit_default;
+static u32 audit_default = AUDIT_OFF;
/* If auditing cannot proceed, audit_failure selects what happens. */
static u32 audit_failure = AUDIT_FAIL_PRINTK;
@@ -1199,8 +1199,6 @@ static int __init audit_init(void)
skb_queue_head_init(&audit_skb_queue);
skb_queue_head_init(&audit_skb_hold_queue);
audit_initialized = AUDIT_INITIALIZED;
- audit_enabled = audit_default;
- audit_ever_enabled |= !!audit_default;
audit_log(NULL, GFP_KERNEL, AUDIT_KERNEL, "initialized");
@@ -1217,6 +1215,8 @@ static int __init audit_enable(char *str
audit_default = !!simple_strtol(str, NULL, 0);
if (!audit_default)
audit_initialized = AUDIT_DISABLED;
+ audit_enabled = audit_default;
+ audit_ever_enabled = !!audit_enabled;
pr_info("%s\n", audit_default ?
"enabled (after initialization)" : "disabled (until reboot)");
Patches currently in stable-queue which might be from paul(a)paul-moore.com are
queue-4.9/audit-ensure-that-audit-1-actually-enables-audit-for-pid-1.patch
From: Len Brown <len.brown(a)intel.com>
Linux-4.10 added X86_FEATURE_TSC_KNOWN_FREQ.
commit 4ca4df0b7eb0
("x86/tsc: Mark TSC frequency determined by CPUID as known")
When it is set, run-time refined TSC calibration is disabled.
But native_calibrate_tsc() sets it on all systems with CPUID.15,
even if crystal_khz can not be discovered via CPUID.15 or via
built-in table. eg. When a new Intel processor comes out
that does not return CPUID.15.crystal_khz, and does not have
its model# and crystal_khz listed in native_calibate_tsc().
This results in (tsc_khz = cpu_khz) and TSC refined calibration
disabled. But for machines with the TSC and CPU in different clock
domains (and those support CPUID.15), almost all such configurations
will experience measurable negative timeofday clock drift.
Signed-off-by: Len Brown <len.brown(a)intel.com>
Cc: Bin Gao <bin.gao(a)intel.com>
Cc: <stable(a)vger.kernel.org> # v4.10+
---
arch/x86/kernel/tsc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 8ea117f8142e..49d772672367 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -609,6 +609,8 @@ unsigned long native_calibrate_tsc(void)
case INTEL_FAM6_ATOM_GOLDMONT:
crystal_khz = 19200; /* 19.2 MHz */
break;
+ default:
+ return 0; /* no X86_FEATURE_TSC_KNOWN_FREQ */
}
}
--
2.14.0-rc0
From: Michal Hocko <mhocko(a)suse.com>
Subject: mm, oom_reaper: fix memory corruption
David Rientjes has reported the following memory corruption while the oom
reaper tries to unmap the victims address space
BUG: Bad page map in process oom_reaper pte:6353826300000000 pmd:00000000
addr:00007f50cab1d000 vm_flags:08100073 anon_vma:ffff9eea335603f0 mapping: (null) index:7f50cab1d
file: (null) fault: (null) mmap: (null) readpage: (null)
CPU: 2 PID: 1001 Comm: oom_reaper
Call Trace:
[<ffffffffa4bd967d>] dump_stack+0x4d/0x70
[<ffffffffa4a03558>] unmap_page_range+0x1068/0x1130
[<ffffffffa4a2e07f>] __oom_reap_task_mm+0xd5/0x16b
[<ffffffffa4a2e226>] oom_reaper+0xff/0x14c
[<ffffffffa48d6ad1>] kthread+0xc1/0xe0
Tetsuo Handa has noticed that the synchronization inside exit_mmap is
insufficient. We only synchronize with the oom reaper if
tsk_is_oom_victim which is not true if the final __mmput is called from a
different context than the oom victim exit path. This can trivially
happen from context of any task which has grabbed mm reference (e.g. to
read /proc/<pid>/ file which requires mm etc.). The race would look like
this
oom_reaper oom_victim task
mmget_not_zero
do_exit
mmput
__oom_reap_task_mm mmput
__mmput
exit_mmap
remove_vma
unmap_page_range
Fix this issue by providing a new mm_is_oom_victim() helper which operates
on the mm struct rather than a task. Any context which operates on a
remote mm struct should use this helper in place of tsk_is_oom_victim.
The flag is set in mark_oom_victim and never cleared so it is stable in
the exit_mmap path.
Debugged by Tetsuo Handa.
Link: http://lkml.kernel.org/r/20171210095130.17110-1-mhocko@kernel.org
Fixes: 212925802454 ("mm: oom: let oom_reap_task and exit_mmap run concurrently")
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: David Rientjes <rientjes(a)google.com>
Acked-by: David Rientjes <rientjes(a)google.com>
Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Cc: Andrea Argangeli <andrea(a)kernel.org>
Cc: <stable(a)vger.kernel.org> [4.14]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/oom.h | 9 +++++++++
include/linux/sched/coredump.h | 1 +
mm/mmap.c | 10 +++++-----
mm/oom_kill.c | 4 +++-
4 files changed, 18 insertions(+), 6 deletions(-)
diff -puN include/linux/oom.h~mm-oom_reaper-fix-memory-corruption include/linux/oom.h
--- a/include/linux/oom.h~mm-oom_reaper-fix-memory-corruption
+++ a/include/linux/oom.h
@@ -67,6 +67,15 @@ static inline bool tsk_is_oom_victim(str
}
/*
+ * Use this helper if tsk->mm != mm and the victim mm needs a special
+ * handling. This is guaranteed to stay true after once set.
+ */
+static inline bool mm_is_oom_victim(struct mm_struct *mm)
+{
+ return test_bit(MMF_OOM_VICTIM, &mm->flags);
+}
+
+/*
* Checks whether a page fault on the given mm is still reliable.
* This is no longer true if the oom reaper started to reap the
* address space which is reflected by MMF_UNSTABLE flag set in
diff -puN include/linux/sched/coredump.h~mm-oom_reaper-fix-memory-corruption include/linux/sched/coredump.h
--- a/include/linux/sched/coredump.h~mm-oom_reaper-fix-memory-corruption
+++ a/include/linux/sched/coredump.h
@@ -70,6 +70,7 @@ static inline int get_dumpable(struct mm
#define MMF_UNSTABLE 22 /* mm is unstable for copy_from_user */
#define MMF_HUGE_ZERO_PAGE 23 /* mm has ever used the global huge zero page */
#define MMF_DISABLE_THP 24 /* disable THP for all VMAs */
+#define MMF_OOM_VICTIM 25 /* mm is the oom victim */
#define MMF_DISABLE_THP_MASK (1 << MMF_DISABLE_THP)
#define MMF_INIT_MASK (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK |\
diff -puN mm/mmap.c~mm-oom_reaper-fix-memory-corruption mm/mmap.c
--- a/mm/mmap.c~mm-oom_reaper-fix-memory-corruption
+++ a/mm/mmap.c
@@ -3019,20 +3019,20 @@ void exit_mmap(struct mm_struct *mm)
/* Use -1 here to ensure all VMAs in the mm are unmapped */
unmap_vmas(&tlb, vma, 0, -1);
- set_bit(MMF_OOM_SKIP, &mm->flags);
- if (unlikely(tsk_is_oom_victim(current))) {
+ if (unlikely(mm_is_oom_victim(mm))) {
/*
* Wait for oom_reap_task() to stop working on this
* mm. Because MMF_OOM_SKIP is already set before
* calling down_read(), oom_reap_task() will not run
* on this "mm" post up_write().
*
- * tsk_is_oom_victim() cannot be set from under us
- * either because current->mm is already set to NULL
+ * mm_is_oom_victim() cannot be set from under us
+ * either because victim->mm is already set to NULL
* under task_lock before calling mmput and oom_mm is
- * set not NULL by the OOM killer only if current->mm
+ * set not NULL by the OOM killer only if victim->mm
* is found not NULL while holding the task_lock.
*/
+ set_bit(MMF_OOM_SKIP, &mm->flags);
down_write(&mm->mmap_sem);
up_write(&mm->mmap_sem);
}
diff -puN mm/oom_kill.c~mm-oom_reaper-fix-memory-corruption mm/oom_kill.c
--- a/mm/oom_kill.c~mm-oom_reaper-fix-memory-corruption
+++ a/mm/oom_kill.c
@@ -683,8 +683,10 @@ static void mark_oom_victim(struct task_
return;
/* oom_mm is bound to the signal struct life time. */
- if (!cmpxchg(&tsk->signal->oom_mm, NULL, mm))
+ if (!cmpxchg(&tsk->signal->oom_mm, NULL, mm)) {
mmgrab(tsk->signal->oom_mm);
+ set_bit(MMF_OOM_VICTIM, &mm->flags);
+ }
/*
* Make sure that the task is woken up from uninterruptible sleep
_
From: Arnd Bergmann <arnd(a)arndb.de>
Subject: string.h: workaround for increased stack usage
The hardened strlen() function causes rather large stack usage in at least
one file in the kernel, in particular when CONFIG_KASAN is enabled:
drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
drivers/media/usb/em28xx/em28xx-dvb.c:2062:1: error: the frame size of 3256 bytes is larger than 204 bytes [-Werror=frame-larger-than=]
Analyzing this problem led to the discovery that gcc fails to merge the
stack slots for the i2c_board_info[] structures after we strlcpy() into
them, due to the 'noreturn' attribute on the source string length check.
I reported this as a gcc bug, but it is unlikely to get fixed for gcc-8,
since it is relatively easy to work around, and it gets triggered rarely.
An earlier workaround I did added an empty inline assembly statement
before the call to fortify_panic(), which works surprisingly well, but is
really ugly and unintuitive.
This is a new approach to the same problem, this time addressing it by not
calling the 'extern __real_strnlen()' function for string constants where
__builtin_strlen() is a compile-time constant and therefore known to be
safe. We do this by checking if the last character in the string is a
compile-time constant '\0'. If it is, we can assume that strlen() of the
string is also constant. As a side-effect, this should also improve the
object code output for any other call of strlen() on a string constant.
[akpm(a)linux-foundation.org: add comment]
Link: http://lkml.kernel.org/r/20171205215143.3085755-1-arnd@arndb.de
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
Link: https://patchwork.kernel.org/patch/9980413/
Link: https://patchwork.kernel.org/patch/9974047/
Fixes: 6974f0c4555 ("include/linux/string.h: add the option of fortified string.h functions")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Daniel Micay <danielmicay(a)gmail.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Martin Wilck <mwilck(a)suse.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/string.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff -puN include/linux/string.h~stringh-work-around-for-increased-stack-usage include/linux/string.h
--- a/include/linux/string.h~stringh-work-around-for-increased-stack-usage
+++ a/include/linux/string.h
@@ -259,7 +259,10 @@ __FORTIFY_INLINE __kernel_size_t strlen(
{
__kernel_size_t ret;
size_t p_size = __builtin_object_size(p, 0);
- if (p_size == (size_t)-1)
+
+ /* Work around gcc excess stack consumption issue */
+ if (p_size == (size_t)-1 ||
+ (__builtin_constant_p(p[p_size - 1]) && p[p_size - 1] == '\0'))
return __builtin_strlen(p);
ret = strnlen(p, p_size);
if (p_size <= ret)
_
From: Marc Zyngier <marc.zyngier(a)arm.com>
Commit 64afe6e9eb4841f35317da4393de21a047a883b3 upstream.
The current pending table parsing code assumes that we keep the
previous read of the pending bits, but keep that variable in
the current block, making sure it is discarded on each loop.
We end-up using whatever is on the stack. Who knows, it might
just be the right thing...
Fixes: 33d3bc9556a7d ("KVM: arm64: vgic-its: Read initial LPI pending table")
Cc: <stable(a)vger.kernel.org> # 4.8
Reported-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
---
virt/kvm/arm/vgic/vgic-its.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
index 547f12dc4d54..d5a8bfe78bc4 100644
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -393,6 +393,7 @@ static int its_sync_lpi_pending_table(struct kvm_vcpu *vcpu)
int ret = 0;
u32 *intids;
int nr_irqs, i;
+ u8 pendmask;
nr_irqs = vgic_copy_lpi_list(vcpu, &intids);
if (nr_irqs < 0)
@@ -400,7 +401,6 @@ static int its_sync_lpi_pending_table(struct kvm_vcpu *vcpu)
for (i = 0; i < nr_irqs; i++) {
int byte_offset, bit_nr;
- u8 pendmask;
byte_offset = intids[i] / BITS_PER_BYTE;
bit_nr = intids[i] % BITS_PER_BYTE;
--
2.14.2
This is a note to let you know that I've just added the patch titled
arm: KVM: Fix VTTBR_BADDR_MASK BUG_ON off-by-one
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5553b142be11e794ebc0805950b2e8313f93d718 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Thu, 16 Nov 2017 17:58:21 +0000
Subject: arm: KVM: Fix VTTBR_BADDR_MASK BUG_ON off-by-one
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit 5553b142be11e794ebc0805950b2e8313f93d718 upstream.
VTTBR_BADDR_MASK is used to sanity check the size and alignment of the
VTTBR address. It seems to currently be off by one, thereby only
allowing up to 39-bit addresses (instead of 40-bit) and also
insufficiently checking the alignment. This patch fixes it.
This patch is the 32bit pendent of Kristina's arm64 fix, and
she deserves the actual kudos for pinpointing that one.
Fixes: f7ed45be3ba52 ("KVM: ARM: World-switch implementation")
Cc: <stable(a)vger.kernel.org> # 3.9
Reported-by: Kristina Martsenko <kristina.martsenko(a)arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/include/asm/kvm_arm.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm/include/asm/kvm_arm.h
+++ b/arch/arm/include/asm/kvm_arm.h
@@ -161,8 +161,7 @@
#else
#define VTTBR_X (5 - KVM_T0SZ)
#endif
-#define VTTBR_BADDR_SHIFT (VTTBR_X - 1)
-#define VTTBR_BADDR_MASK (((1LLU << (40 - VTTBR_X)) - 1) << VTTBR_BADDR_SHIFT)
+#define VTTBR_BADDR_MASK (((1LLU << (40 - VTTBR_X)) - 1) << VTTBR_X)
#define VTTBR_VMID_SHIFT (48LLU)
#define VTTBR_VMID_MASK (0xffLLU << VTTBR_VMID_SHIFT)
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.4/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
queue-4.4/arm-kvm-survive-unknown-traps-from-guests.patch
queue-4.4/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
queue-4.4/irqchip-crossbar-fix-incorrect-type-of-register-size.patch
queue-4.4/arm64-kvm-survive-unknown-traps-from-guests.patch
From: Marc Zyngier <marc.zyngier(a)arm.com>
Commit 5553b142be11e794ebc0805950b2e8313f93d718 upstream.
VTTBR_BADDR_MASK is used to sanity check the size and alignment of the
VTTBR address. It seems to currently be off by one, thereby only
allowing up to 39-bit addresses (instead of 40-bit) and also
insufficiently checking the alignment. This patch fixes it.
This patch is the 32bit pendent of Kristina's arm64 fix, and
she deserves the actual kudos for pinpointing that one.
Fixes: f7ed45be3ba52 ("KVM: ARM: World-switch implementation")
Cc: <stable(a)vger.kernel.org> # 3.9
Reported-by: Kristina Martsenko <kristina.martsenko(a)arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
---
arch/arm/include/asm/kvm_arm.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
index 816db0bf2dd8..46b336df4ec1 100644
--- a/arch/arm/include/asm/kvm_arm.h
+++ b/arch/arm/include/asm/kvm_arm.h
@@ -161,8 +161,7 @@
#else
#define VTTBR_X (5 - KVM_T0SZ)
#endif
-#define VTTBR_BADDR_SHIFT (VTTBR_X - 1)
-#define VTTBR_BADDR_MASK (((1LLU << (40 - VTTBR_X)) - 1) << VTTBR_BADDR_SHIFT)
+#define VTTBR_BADDR_MASK (((1LLU << (40 - VTTBR_X)) - 1) << VTTBR_X)
#define VTTBR_VMID_SHIFT (48LLU)
#define VTTBR_VMID_MASK (0xffLLU << VTTBR_VMID_SHIFT)
--
2.14.2
This is a note to let you know that I've just added the patch titled
arm: KVM: Fix VTTBR_BADDR_MASK BUG_ON off-by-one
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5553b142be11e794ebc0805950b2e8313f93d718 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Thu, 16 Nov 2017 17:58:21 +0000
Subject: arm: KVM: Fix VTTBR_BADDR_MASK BUG_ON off-by-one
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit 5553b142be11e794ebc0805950b2e8313f93d718 upstream.
VTTBR_BADDR_MASK is used to sanity check the size and alignment of the
VTTBR address. It seems to currently be off by one, thereby only
allowing up to 39-bit addresses (instead of 40-bit) and also
insufficiently checking the alignment. This patch fixes it.
This patch is the 32bit pendent of Kristina's arm64 fix, and
she deserves the actual kudos for pinpointing that one.
Fixes: f7ed45be3ba52 ("KVM: ARM: World-switch implementation")
Reported-by: Kristina Martsenko <kristina.martsenko(a)arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/include/asm/kvm_arm.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm/include/asm/kvm_arm.h
+++ b/arch/arm/include/asm/kvm_arm.h
@@ -161,8 +161,7 @@
#else
#define VTTBR_X (5 - KVM_T0SZ)
#endif
-#define VTTBR_BADDR_SHIFT (VTTBR_X - 1)
-#define VTTBR_BADDR_MASK (((1LLU << (40 - VTTBR_X)) - 1) << VTTBR_BADDR_SHIFT)
+#define VTTBR_BADDR_MASK (((1LLU << (40 - VTTBR_X)) - 1) << VTTBR_X)
#define VTTBR_VMID_SHIFT (48LLU)
#define VTTBR_VMID_MASK (0xffLLU << VTTBR_VMID_SHIFT)
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-3.18/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
queue-3.18/arm-kvm-survive-unknown-traps-from-guests.patch
queue-3.18/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
queue-3.18/irqchip-crossbar-fix-incorrect-type-of-register-size.patch
From: Marc Zyngier <marc.zyngier(a)arm.com>
Commit 5553b142be11e794ebc0805950b2e8313f93d718 upstream.
VTTBR_BADDR_MASK is used to sanity check the size and alignment of the
VTTBR address. It seems to currently be off by one, thereby only
allowing up to 39-bit addresses (instead of 40-bit) and also
insufficiently checking the alignment. This patch fixes it.
This patch is the 32bit pendent of Kristina's arm64 fix, and
she deserves the actual kudos for pinpointing that one.
Fixes: f7ed45be3ba52 ("KVM: ARM: World-switch implementation")
Cc: <stable(a)vger.kernel.org> # 3.9
Reported-by: Kristina Martsenko <kristina.martsenko(a)arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
---
arch/arm/include/asm/kvm_arm.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
index dc641ddf0784..0f2720713492 100644
--- a/arch/arm/include/asm/kvm_arm.h
+++ b/arch/arm/include/asm/kvm_arm.h
@@ -161,8 +161,7 @@
#else
#define VTTBR_X (5 - KVM_T0SZ)
#endif
-#define VTTBR_BADDR_SHIFT (VTTBR_X - 1)
-#define VTTBR_BADDR_MASK (((1LLU << (40 - VTTBR_X)) - 1) << VTTBR_BADDR_SHIFT)
+#define VTTBR_BADDR_MASK (((1LLU << (40 - VTTBR_X)) - 1) << VTTBR_X)
#define VTTBR_VMID_SHIFT (48LLU)
#define VTTBR_VMID_MASK (0xffLLU << VTTBR_VMID_SHIFT)
--
2.14.2
This is a note to let you know that I've just added the patch titled
KVM: arm/arm64: vgic-its: Preserve the revious read from the pending table
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-arm-arm64-vgic-its-preserve-the-revious-read-from-the-pending-table.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 64afe6e9eb4841f35317da4393de21a047a883b3 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Thu, 16 Nov 2017 17:58:17 +0000
Subject: KVM: arm/arm64: vgic-its: Preserve the revious read from the pending table
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit 64afe6e9eb4841f35317da4393de21a047a883b3 upstream.
The current pending table parsing code assumes that we keep the
previous read of the pending bits, but keep that variable in
the current block, making sure it is discarded on each loop.
We end-up using whatever is on the stack. Who knows, it might
just be the right thing...
Fixes: 33d3bc9556a7d ("KVM: arm64: vgic-its: Read initial LPI pending table")
Cc: stable(a)vger.kernel.org # 4.8
Reported-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
virt/kvm/arm/vgic/vgic-its.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -322,6 +322,7 @@ static int its_sync_lpi_pending_table(st
int ret = 0;
u32 *intids;
int nr_irqs, i;
+ u8 pendmask;
nr_irqs = vgic_copy_lpi_list(vcpu->kvm, &intids);
if (nr_irqs < 0)
@@ -329,7 +330,6 @@ static int its_sync_lpi_pending_table(st
for (i = 0; i < nr_irqs; i++) {
int byte_offset, bit_nr;
- u8 pendmask;
byte_offset = intids[i] / BITS_PER_BYTE;
bit_nr = intids[i] % BITS_PER_BYTE;
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.9/kvm-arm-arm64-vgic-its-preserve-the-revious-read-from-the-pending-table.patch
From: Marc Zyngier <marc.zyngier(a)arm.com>
Commit 64afe6e9eb4841f35317da4393de21a047a883b3 upstream.
The current pending table parsing code assumes that we keep the
previous read of the pending bits, but keep that variable in
the current block, making sure it is discarded on each loop.
We end-up using whatever is on the stack. Who knows, it might
just be the right thing...
Fixes: 33d3bc9556a7d ("KVM: arm64: vgic-its: Read initial LPI pending table")
Cc: <stable(a)vger.kernel.org> # 4.8
Reported-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
---
virt/kvm/arm/vgic/vgic-its.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
index 4660a7d04eea..bbd4a988e8c1 100644
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -322,6 +322,7 @@ static int its_sync_lpi_pending_table(struct kvm_vcpu *vcpu)
int ret = 0;
u32 *intids;
int nr_irqs, i;
+ u8 pendmask;
nr_irqs = vgic_copy_lpi_list(vcpu->kvm, &intids);
if (nr_irqs < 0)
@@ -329,7 +330,6 @@ static int its_sync_lpi_pending_table(struct kvm_vcpu *vcpu)
for (i = 0; i < nr_irqs; i++) {
int byte_offset, bit_nr;
- u8 pendmask;
byte_offset = intids[i] / BITS_PER_BYTE;
bit_nr = intids[i] % BITS_PER_BYTE;
--
2.14.2
This is a note to let you know that I've just added the patch titled
KVM: arm/arm64: vgic-its: Preserve the revious read from the pending table
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-arm-arm64-vgic-its-preserve-the-revious-read-from-the-pending-table.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 64afe6e9eb4841f35317da4393de21a047a883b3 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Thu, 16 Nov 2017 17:58:17 +0000
Subject: KVM: arm/arm64: vgic-its: Preserve the revious read from the pending table
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit 64afe6e9eb4841f35317da4393de21a047a883b3 upstream.
The current pending table parsing code assumes that we keep the
previous read of the pending bits, but keep that variable in
the current block, making sure it is discarded on each loop.
We end-up using whatever is on the stack. Who knows, it might
just be the right thing...
Fixes: 33d3bc9556a7d ("KVM: arm64: vgic-its: Read initial LPI pending table")
Reported-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
virt/kvm/arm/vgic/vgic-its.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -393,6 +393,7 @@ static int its_sync_lpi_pending_table(st
int ret = 0;
u32 *intids;
int nr_irqs, i;
+ u8 pendmask;
nr_irqs = vgic_copy_lpi_list(vcpu, &intids);
if (nr_irqs < 0)
@@ -400,7 +401,6 @@ static int its_sync_lpi_pending_table(st
for (i = 0; i < nr_irqs; i++) {
int byte_offset, bit_nr;
- u8 pendmask;
byte_offset = intids[i] / BITS_PER_BYTE;
bit_nr = intids[i] % BITS_PER_BYTE;
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.14/kvm-arm-arm64-vgic-its-preserve-the-revious-read-from-the-pending-table.patch
From: Marc Zyngier <marc.zyngier(a)arm.com>
Commit 64afe6e9eb4841f35317da4393de21a047a883b3 upstream.
The current pending table parsing code assumes that we keep the
previous read of the pending bits, but keep that variable in
the current block, making sure it is discarded on each loop.
We end-up using whatever is on the stack. Who knows, it might
just be the right thing...
Fixes: 33d3bc9556a7d ("KVM: arm64: vgic-its: Read initial LPI pending table")
Cc: <stable(a)vger.kernel.org> # 4.8
Reported-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
---
virt/kvm/arm/vgic/vgic-its.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
index 547f12dc4d54..d5a8bfe78bc4 100644
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -393,6 +393,7 @@ static int its_sync_lpi_pending_table(struct kvm_vcpu *vcpu)
int ret = 0;
u32 *intids;
int nr_irqs, i;
+ u8 pendmask;
nr_irqs = vgic_copy_lpi_list(vcpu, &intids);
if (nr_irqs < 0)
@@ -400,7 +401,6 @@ static int its_sync_lpi_pending_table(struct kvm_vcpu *vcpu)
for (i = 0; i < nr_irqs; i++) {
int byte_offset, bit_nr;
- u8 pendmask;
byte_offset = intids[i] / BITS_PER_BYTE;
bit_nr = intids[i] % BITS_PER_BYTE;
--
2.14.2
This is a note to let you know that I've just added the patch titled
arm: KVM: Fix VTTBR_BADDR_MASK BUG_ON off-by-one
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5553b142be11e794ebc0805950b2e8313f93d718 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Thu, 16 Nov 2017 17:58:21 +0000
Subject: arm: KVM: Fix VTTBR_BADDR_MASK BUG_ON off-by-one
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit 5553b142be11e794ebc0805950b2e8313f93d718 upstream.
VTTBR_BADDR_MASK is used to sanity check the size and alignment of the
VTTBR address. It seems to currently be off by one, thereby only
allowing up to 39-bit addresses (instead of 40-bit) and also
insufficiently checking the alignment. This patch fixes it.
This patch is the 32bit pendent of Kristina's arm64 fix, and
she deserves the actual kudos for pinpointing that one.
Fixes: f7ed45be3ba52 ("KVM: ARM: World-switch implementation")
Cc: <stable(a)vger.kernel.org> # 3.9
Reported-by: Kristina Martsenko <kristina.martsenko(a)arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/include/asm/kvm_arm.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm/include/asm/kvm_arm.h
+++ b/arch/arm/include/asm/kvm_arm.h
@@ -161,8 +161,7 @@
#else
#define VTTBR_X (5 - KVM_T0SZ)
#endif
-#define VTTBR_BADDR_SHIFT (VTTBR_X - 1)
-#define VTTBR_BADDR_MASK (((1LLU << (40 - VTTBR_X)) - 1) << VTTBR_BADDR_SHIFT)
+#define VTTBR_BADDR_MASK (((1LLU << (40 - VTTBR_X)) - 1) << VTTBR_X)
#define VTTBR_VMID_SHIFT (48LLU)
#define VTTBR_VMID_MASK (0xffLLU << VTTBR_VMID_SHIFT)
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-3.18/arm-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
queue-3.18/arm-kvm-survive-unknown-traps-from-guests.patch
queue-3.18/arm64-kvm-fix-vttbr_baddr_mask-bug_on-off-by-one.patch
queue-3.18/irqchip-crossbar-fix-incorrect-type-of-register-size.patch
The patch titled
Subject: mm/mprotect: add a cond_resched() inside change_pmd_range()
has been added to the -mm tree. Its filename is
mm-mprotect-add-a-cond_resched-inside-change_pmd_range.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-mprotect-add-a-cond_resched-ins…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-mprotect-add-a-cond_resched-ins…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Anshuman Khandual <khandual(a)linux.vnet.ibm.com>
Subject: mm/mprotect: add a cond_resched() inside change_pmd_range()
While testing on a large CPU system, detected the following RCU stall many
times over the span of the workload. This problem is solved by adding a
cond_resched() in the change_pmd_range() function.
[ 850.962530] INFO: rcu_sched detected stalls on CPUs/tasks:
[ 850.962584] 154-....: (670 ticks this GP) idle=022/140000000000000/0 softirq=2825/2825 fqs=612
[ 850.962605] (detected by 955, t=6002 jiffies, g=4486, c=4485, q=90864)
[ 850.962895] Sending NMI from CPU 955 to CPUs 154:
[ 850.992667] NMI backtrace for cpu 154
[ 850.993069] CPU: 154 PID: 147071 Comm: workload Not tainted 4.15.0-rc3+ #3
[ 850.993258] NIP: c0000000000b3f64 LR: c0000000000b33d4 CTR: 000000000000aa18
[ 850.993503] REGS: 00000000a4b0fb44 TRAP: 0501 Not tainted (4.15.0-rc3+)
[ 850.993707] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22422082 XER: 00000000
[ 850.994386] CFAR: 00000000006cf8f0 SOFTE: 1
GPR00: 0010000000000000 c00003ef9b1cb8c0 c0000000010cc600 0000000000000000
GPR04: 8e0000018c32b200 40017b3858fd6e00 8e0000018c32b208 40017b3858fd6e00
GPR08: 8e0000018c32b210 40017b3858fd6e00 8e0000018c32b218 40017b3858fd6e00
GPR12: ffffffffffffffff c00000000fb25100
[ 850.995976] NIP [c0000000000b3f64] plpar_hcall9+0x44/0x7c
[ 850.996174] LR [c0000000000b33d4] pSeries_lpar_flush_hash_range+0x384/0x420
[ 850.996401] Call Trace:
[ 850.996600] [c00003ef9b1cb8c0] [c00003fa8fff7d40] 0xc00003fa8fff7d40 (unreliable)
[ 850.996959] [c00003ef9b1cba40] [c0000000000688a8] flush_hash_range+0x48/0x100
[ 850.997261] [c00003ef9b1cba90] [c000000000071b14] __flush_tlb_pending+0x44/0xd0
[ 850.997600] [c00003ef9b1cbac0] [c000000000071fa8] hpte_need_flush+0x408/0x470
[ 850.997958] [c00003ef9b1cbb30] [c0000000002c646c] change_protection_range+0xaac/0xf10
[ 850.998180] [c00003ef9b1cbcb0] [c0000000002f2510] change_prot_numa+0x30/0xb0
[ 850.998502] [c00003ef9b1cbce0] [c00000000013a950] task_numa_work+0x2d0/0x3e0
[ 850.998816] [c00003ef9b1cbda0] [c00000000011ea30] task_work_run+0x130/0x190
[ 850.999121] [c00003ef9b1cbe00] [c00000000001bcd8] do_notify_resume+0x118/0x120
[ 850.999421] [c00003ef9b1cbe30] [c00000000000b744] ret_from_except_lite+0x70/0x74
[ 850.999716] Instruction dump:
[ 850.999959] 60000000 f8810028 7ca42b78 7cc53378 7ce63b78 7d074378 7d284b78 7d495378
[ 851.000575] e9410060 e9610068 e9810070 44000022 <7d806378> e9810028 f88c0000 f8ac0008
Link: http://lkml.kernel.org/r/20171214140551.5794-1-khandual@linux.vnet.ibm.com
Signed-off-by: Anshuman Khandual <khandual(a)linux.vnet.ibm.com>
Suggested-by: Nicholas Piggin <npiggin(a)gmail.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/mprotect.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff -puN mm/mprotect.c~mm-mprotect-add-a-cond_resched-inside-change_pmd_range mm/mprotect.c
--- a/mm/mprotect.c~mm-mprotect-add-a-cond_resched-inside-change_pmd_range
+++ a/mm/mprotect.c
@@ -166,7 +166,7 @@ static inline unsigned long change_pmd_r
next = pmd_addr_end(addr, end);
if (!is_swap_pmd(*pmd) && !pmd_trans_huge(*pmd) && !pmd_devmap(*pmd)
&& pmd_none_or_clear_bad(pmd))
- continue;
+ goto next;
/* invoke the mmu notifier if the pmd is populated */
if (!mni_start) {
@@ -188,7 +188,7 @@ static inline unsigned long change_pmd_r
}
/* huge pmd was handled */
- continue;
+ goto next;
}
}
/* fall through, the trans huge pmd just split */
@@ -196,6 +196,8 @@ static inline unsigned long change_pmd_r
this_pages = change_pte_range(vma, pmd, addr, next, newprot,
dirty_accountable, prot_numa);
pages += this_pages;
+next:
+ cond_resched();
} while (pmd++, addr = next, addr != end);
if (mni_start)
_
Patches currently in -mm which might be from khandual(a)linux.vnet.ibm.com are
mm-mprotect-add-a-cond_resched-inside-change_pmd_range.patch
This is a note to let you know that I've just added the patch titled
xfrm: Copy policy family in clone_policy
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfrm-copy-policy-family-in-clone_policy.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Herbert Xu <herbert(a)gondor.apana.org.au>
Date: Fri, 10 Nov 2017 14:14:06 +1100
Subject: xfrm: Copy policy family in clone_policy
From: Herbert Xu <herbert(a)gondor.apana.org.au>
[ Upstream commit 0e74aa1d79a5bbc663e03a2804399cae418a0321 ]
The syzbot found an ancient bug in the IPsec code. When we cloned
a socket policy (for example, for a child TCP socket derived from a
listening socket), we did not copy the family field. This results
in a live policy with a zero family field. This triggers a BUG_ON
check in the af_key code when the cloned policy is retrieved.
This patch fixes it by copying the family field over.
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_policy.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1345,6 +1345,7 @@ static struct xfrm_policy *clone_policy(
newp->xfrm_nr = old->xfrm_nr;
newp->index = old->index;
newp->type = old->type;
+ newp->family = old->family;
memcpy(newp->xfrm_vec, old->xfrm_vec,
newp->xfrm_nr*sizeof(struct xfrm_tmpl));
write_lock_bh(&net->xfrm.xfrm_policy_lock);
Patches currently in stable-queue which might be from herbert(a)gondor.apana.org.au are
queue-3.18/xfrm-copy-policy-family-in-clone_policy.patch
queue-3.18/crypto-s5p-sss-fix-completing-crypto-request-in-irq-handler.patch
This is a note to let you know that I've just added the patch titled
USB: gadgetfs: Fix a potential memory leak in 'dev_config()'
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadgetfs-fix-a-potential-memory-leak-in-dev_config.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Tue, 21 Feb 2017 22:33:11 +0100
Subject: USB: gadgetfs: Fix a potential memory leak in 'dev_config()'
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit b6e7aeeaf235901c42ec35de4633c7c69501d303 ]
'kbuf' is allocated just a few lines above using 'memdup_user()'.
If the 'if (dev->buf)' test fails, this memory is never released.
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/legacy/inode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -1921,8 +1921,10 @@ dev_config (struct file *fd, const char
spin_lock_irq (&dev->lock);
value = -EINVAL;
- if (dev->buf)
+ if (dev->buf) {
+ kfree(kbuf);
goto fail;
+ }
dev->buf = kbuf;
/* full or low speed config */
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-3.18/usb-gadgetfs-fix-a-potential-memory-leak-in-dev_config.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: configs: plug memory leak
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadget-configs-plug-memory-leak.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: John Keeping <john(a)metanate.com>
Date: Tue, 28 Feb 2017 10:55:30 +0000
Subject: usb: gadget: configs: plug memory leak
From: John Keeping <john(a)metanate.com>
[ Upstream commit 38355b2a44776c25b0f2ad466e8c51bb805b3032 ]
When binding a gadget to a device, "name" is stored in gi->udc_name, but
this does not happen when unregistering and the string is leaked.
Signed-off-by: John Keeping <john(a)metanate.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/configfs.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -266,6 +266,7 @@ static ssize_t gadget_dev_desc_UDC_store
ret = unregister_gadget(gi);
if (ret)
goto err;
+ kfree(name);
} else {
if (gi->udc_name) {
ret = -EBUSY;
Patches currently in stable-queue which might be from john(a)metanate.com are
queue-3.18/usb-gadget-configs-plug-memory-leak.patch
This is a note to let you know that I've just added the patch titled
workqueue: trigger WARN if queue_delayed_work() is called with NULL @wq
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
workqueue-trigger-warn-if-queue_delayed_work-is-called-with-null-wq.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Tejun Heo <tj(a)kernel.org>
Date: Mon, 6 Mar 2017 15:33:42 -0500
Subject: workqueue: trigger WARN if queue_delayed_work() is called with NULL @wq
From: Tejun Heo <tj(a)kernel.org>
[ Upstream commit 637fdbae60d6cb9f6e963c1079d7e0445c86ff7d ]
If queue_delayed_work() gets called with NULL @wq, the kernel will
oops asynchronuosly on timer expiration which isn't too helpful in
tracking down the offender. This actually happened with smc.
__queue_delayed_work() already does several input sanity checks
synchronously. Add NULL @wq check.
Reported-by: Dave Jones <davej(a)codemonkey.org.uk>
Link: http://lkml.kernel.org/r/20170227171439.jshx3qplflyrgcv7@codemonkey.org.uk
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/workqueue.c | 1 +
1 file changed, 1 insertion(+)
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1452,6 +1452,7 @@ static void __queue_delayed_work(int cpu
struct timer_list *timer = &dwork->timer;
struct work_struct *work = &dwork->work;
+ WARN_ON_ONCE(!wq);
WARN_ON_ONCE(timer->function != delayed_work_timer_fn ||
timer->data != (unsigned long)dwork);
WARN_ON_ONCE(timer_pending(timer));
Patches currently in stable-queue which might be from tj(a)kernel.org are
queue-3.18/libata-drop-warn-from-protocol-error-in-ata_sff_qc_issue.patch
queue-3.18/workqueue-trigger-warn-if-queue_delayed_work-is-called-with-null-wq.patch
This is a note to let you know that I've just added the patch titled
sunrpc: Fix rpc_task_begin trace point
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sunrpc-fix-rpc_task_begin-trace-point.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Chuck Lever <chuck.lever(a)oracle.com>
Date: Fri, 3 Nov 2017 13:46:06 -0400
Subject: sunrpc: Fix rpc_task_begin trace point
From: Chuck Lever <chuck.lever(a)oracle.com>
[ Upstream commit b2bfe5915d5fe7577221031a39ac722a0a2a1199 ]
The rpc_task_begin trace point always display a task ID of zero.
Move the trace point call site so that it picks up the new task ID.
Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sunrpc/sched.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -273,10 +273,9 @@ static inline void rpc_task_set_debuginf
static void rpc_set_active(struct rpc_task *task)
{
- trace_rpc_task_begin(task->tk_client, task, NULL);
-
rpc_task_set_debuginfo(task);
set_bit(RPC_TASK_ACTIVE, &task->tk_runstate);
+ trace_rpc_task_begin(task->tk_client, task, NULL);
}
/*
Patches currently in stable-queue which might be from chuck.lever(a)oracle.com are
queue-3.18/sunrpc-fix-rpc_task_begin-trace-point.patch
This is a note to let you know that I've just added the patch titled
spi_ks8995: fix "BUG: key accdaa28 not in .data!"
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
spi_ks8995-fix-bug-key-accdaa28-not-in-.data.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: "Blomme, Maarten" <Maarten.Blomme(a)flir.com>
Date: Thu, 2 Mar 2017 13:08:36 +0100
Subject: spi_ks8995: fix "BUG: key accdaa28 not in .data!"
From: "Blomme, Maarten" <Maarten.Blomme(a)flir.com>
[ Upstream commit 4342696df764ec65dcdfbd0c10d90ea52505f8ba ]
Signed-off-by: Maarten Blomme <Maarten.Blomme(a)flir.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/phy/spi_ks8995.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/phy/spi_ks8995.c
+++ b/drivers/net/phy/spi_ks8995.c
@@ -332,6 +332,7 @@ static int ks8995_probe(struct spi_devic
if (err)
return err;
+ sysfs_attr_init(&ks->regs_attr.attr);
err = sysfs_create_bin_file(&spi->dev.kobj, &ks->regs_attr);
if (err) {
dev_err(&spi->dev, "unable to create sysfs file, err=%d\n",
Patches currently in stable-queue which might be from Maarten.Blomme(a)flir.com are
queue-3.18/spi_ks8995-fix-bug-key-accdaa28-not-in-.data.patch
This is a note to let you know that I've just added the patch titled
sparc64/mm: set fields in deferred pages
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sparc64-mm-set-fields-in-deferred-pages.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Date: Wed, 15 Nov 2017 17:36:18 -0800
Subject: sparc64/mm: set fields in deferred pages
From: Pavel Tatashin <pasha.tatashin(a)oracle.com>
[ Upstream commit 2a20aa171071a334d80c4e5d5af719d8374702fc ]
Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT),
flags and other fields in "struct page"es are never changed prior to
first initializing struct pages by going through __init_single_page().
With deferred struct page feature enabled there is a case where we set
some fields prior to initializing:
mem_init() {
register_page_bootmem_info();
free_all_bootmem();
...
}
When register_page_bootmem_info() is called only non-deferred struct
pages are initialized. But, this function goes through some reserved
pages which might be part of the deferred, and thus are not yet
initialized.
mem_init
register_page_bootmem_info
register_page_bootmem_info_node
get_page_bootmem
.. setting fields here ..
such as: page->freelist = (void *)type;
free_all_bootmem()
free_low_memory_core_early()
for_each_reserved_mem_region()
reserve_bootmem_region()
init_reserved_page() <- Only if this is deferred reserved page
__init_single_pfn()
__init_single_page()
memset(0) <-- Loose the set fields here
We end up with similar issue as in the previous patch, where currently
we do not observe problem as memory is zeroed. But, if flag asserts are
changed we can start hitting issues.
Also, because in this patch series we will stop zeroing struct page
memory during allocation, we must make sure that struct pages are
properly initialized prior to using them.
The deferred-reserved pages are initialized in free_all_bootmem().
Therefore, the fix is to switch the above calls.
Link: http://lkml.kernel.org/r/20171013173214.27300-4-pasha.tatashin@oracle.com
Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Reviewed-by: Steven Sistare <steven.sistare(a)oracle.com>
Reviewed-by: Daniel Jordan <daniel.m.jordan(a)oracle.com>
Reviewed-by: Bob Picco <bob.picco(a)oracle.com>
Acked-by: David S. Miller <davem(a)davemloft.net>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: Christian Borntraeger <borntraeger(a)de.ibm.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Mark Rutland <mark.rutland(a)arm.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Sam Ravnborg <sam(a)ravnborg.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/sparc/mm/init_64.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -2215,10 +2215,17 @@ void __init mem_init(void)
{
high_memory = __va(last_valid_pfn << PAGE_SHIFT);
- register_page_bootmem_info();
free_all_bootmem();
/*
+ * Must be done after boot memory is put on freelist, because here we
+ * might set fields in deferred struct pages that have not yet been
+ * initialized, and free_all_bootmem() initializes all the reserved
+ * deferred pages for us.
+ */
+ register_page_bootmem_info();
+
+ /*
* Set up the zero page, mark it reserved, so that page count
* is not manipulated when freeing the page from user ptes.
*/
Patches currently in stable-queue which might be from pasha.tatashin(a)oracle.com are
queue-3.18/sparc64-mm-set-fields-in-deferred-pages.patch
This is a note to let you know that I've just added the patch titled
selftest/powerpc: Fix false failures for skipped tests
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
selftest-powerpc-fix-false-failures-for-skipped-tests.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Sachin Sant <sachinp(a)linux.vnet.ibm.com>
Date: Sun, 26 Feb 2017 11:38:39 +0530
Subject: selftest/powerpc: Fix false failures for skipped tests
From: Sachin Sant <sachinp(a)linux.vnet.ibm.com>
[ Upstream commit a6d8a21596df041f36f4c2ccc260c459e3e851f1 ]
Tests under alignment subdirectory are skipped when executed on previous
generation hardware, but harness still marks them as failed.
test: test_copy_unaligned
tags: git_version:unknown
[SKIP] Test skipped on line 26
skip: test_copy_unaligned
selftests: copy_unaligned [FAIL]
The MAGIC_SKIP_RETURN_VALUE value assigned to rc variable is retained till
the program exit which causes the test to be marked as failed.
This patch resets the value before returning to the main() routine.
With this patch the test o/p is as follows:
test: test_copy_unaligned
tags: git_version:unknown
[SKIP] Test skipped on line 26
skip: test_copy_unaligned
selftests: copy_unaligned [PASS]
Signed-off-by: Sachin Sant <sachinp(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/testing/selftests/powerpc/harness.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/tools/testing/selftests/powerpc/harness.c
+++ b/tools/testing/selftests/powerpc/harness.c
@@ -105,9 +105,11 @@ int test_harness(int (test_function)(voi
rc = run_test(test_function, name);
- if (rc == MAGIC_SKIP_RETURN_VALUE)
+ if (rc == MAGIC_SKIP_RETURN_VALUE) {
test_skip(name);
- else
+ /* so that skipped test is not marked as failed */
+ rc = 0;
+ } else
test_finish(name, rc);
return rc;
Patches currently in stable-queue which might be from sachinp(a)linux.vnet.ibm.com are
queue-3.18/selftest-powerpc-fix-false-failures-for-skipped-tests.patch
This is a note to let you know that I've just added the patch titled
sctp: use the right sk after waking up from wait_buf sleep
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sctp-use-the-right-sk-after-waking-up-from-wait_buf-sleep.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Wed, 15 Nov 2017 16:57:26 +0800
Subject: sctp: use the right sk after waking up from wait_buf sleep
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit cea0cc80a6777beb6eb643d4ad53690e1ad1d4ff ]
Commit dfcb9f4f99f1 ("sctp: deny peeloff operation on asocs with threads
sleeping on it") fixed the race between peeloff and wait sndbuf by
checking waitqueue_active(&asoc->wait) in sctp_do_peeloff().
But it actually doesn't work, as even if waitqueue_active returns false
the waiting sndbuf thread may still not yet hold sk lock. After asoc is
peeled off, sk is not asoc->base.sk any more, then to hold the old sk
lock couldn't make assoc safe to access.
This patch is to fix this by changing to hold the new sk lock if sk is
not asoc->base.sk, meanwhile, also set the sk in sctp_sendmsg with the
new sk.
With this fix, there is no more race between peeloff and waitbuf, the
check 'waitqueue_active' in sctp_do_peeloff can be removed.
Thanks Marcelo and Neil for making this clear.
v1->v2:
fix it by changing to lock the new sock instead of adding a flag in asoc.
Suggested-by: Neil Horman <nhorman(a)tuxdriver.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Neil Horman <nhorman(a)tuxdriver.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/socket.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -82,8 +82,8 @@
/* Forward declarations for internal helper functions. */
static int sctp_writeable(struct sock *sk);
static void sctp_wfree(struct sk_buff *skb);
-static int sctp_wait_for_sndbuf(struct sctp_association *, long *timeo_p,
- size_t msg_len);
+static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p,
+ size_t msg_len, struct sock **orig_sk);
static int sctp_wait_for_packet(struct sock *sk, int *err, long *timeo_p);
static int sctp_wait_for_connect(struct sctp_association *, long *timeo_p);
static int sctp_wait_for_accept(struct sock *sk, long timeo);
@@ -1949,7 +1949,8 @@ static int sctp_sendmsg(struct kiocb *io
timeo = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT);
if (!sctp_wspace(asoc)) {
- err = sctp_wait_for_sndbuf(asoc, &timeo, msg_len);
+ /* sk can be changed by peel off when waiting for buf. */
+ err = sctp_wait_for_sndbuf(asoc, &timeo, msg_len, &sk);
if (err) {
if (err == -ESRCH) {
/* asoc is already dead. */
@@ -4479,12 +4480,6 @@ int sctp_do_peeloff(struct sock *sk, sct
if (!asoc)
return -EINVAL;
- /* If there is a thread waiting on more sndbuf space for
- * sending on this asoc, it cannot be peeled.
- */
- if (waitqueue_active(&asoc->wait))
- return -EBUSY;
-
/* An association cannot be branched off from an already peeled-off
* socket, nor is this supported for tcp style sockets.
*/
@@ -6988,7 +6983,7 @@ void sctp_sock_rfree(struct sk_buff *skb
/* Helper function to wait for space in the sndbuf. */
static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p,
- size_t msg_len)
+ size_t msg_len, struct sock **orig_sk)
{
struct sock *sk = asoc->base.sk;
int err = 0;
@@ -7022,11 +7017,17 @@ static int sctp_wait_for_sndbuf(struct s
release_sock(sk);
current_timeo = schedule_timeout(current_timeo);
lock_sock(sk);
+ if (sk != asoc->base.sk) {
+ release_sock(sk);
+ sk = asoc->base.sk;
+ lock_sock(sk);
+ }
*timeo_p = current_timeo;
}
out:
+ *orig_sk = sk;
finish_wait(&asoc->wait, &wait);
/* Release the association's refcnt. */
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-3.18/route-update-fnhe_expires-for-redirect-when-the-fnhe-exists.patch
queue-3.18/route-also-update-fnhe_genid-when-updating-a-route-cache.patch
queue-3.18/sctp-use-the-right-sk-after-waking-up-from-wait_buf-sleep.patch
queue-3.18/sctp-do-not-free-asoc-when-it-is-already-dead-in-sctp_sendmsg.patch
This is a note to let you know that I've just added the patch titled
sctp: do not free asoc when it is already dead in sctp_sendmsg
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sctp-do-not-free-asoc-when-it-is-already-dead-in-sctp_sendmsg.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Wed, 15 Nov 2017 16:55:54 +0800
Subject: sctp: do not free asoc when it is already dead in sctp_sendmsg
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit ca3af4dd28cff4e7216e213ba3b671fbf9f84758 ]
Now in sctp_sendmsg sctp_wait_for_sndbuf could schedule out without
holding sock sk. It means the current asoc can be freed elsewhere,
like when receiving an abort packet.
If the asoc is just created in sctp_sendmsg and sctp_wait_for_sndbuf
returns err, the asoc will be freed again due to new_asoc is not nil.
An use-after-free issue would be triggered by this.
This patch is to fix it by setting new_asoc with nil if the asoc is
already dead when cpu schedules back, so that it will not be freed
again in sctp_sendmsg.
v1->v2:
set new_asoc as nil in sctp_sendmsg instead of sctp_wait_for_sndbuf.
Suggested-by: Neil Horman <nhorman(a)tuxdriver.com>
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Neil Horman <nhorman(a)tuxdriver.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/socket.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1950,8 +1950,14 @@ static int sctp_sendmsg(struct kiocb *io
timeo = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT);
if (!sctp_wspace(asoc)) {
err = sctp_wait_for_sndbuf(asoc, &timeo, msg_len);
- if (err)
+ if (err) {
+ if (err == -ESRCH) {
+ /* asoc is already dead. */
+ new_asoc = NULL;
+ err = -EPIPE;
+ }
goto out_free;
+ }
}
/* If an address is passed with the sendto/sendmsg call, it is used
@@ -6999,10 +7005,11 @@ static int sctp_wait_for_sndbuf(struct s
for (;;) {
prepare_to_wait_exclusive(&asoc->wait, &wait,
TASK_INTERRUPTIBLE);
+ if (asoc->base.dead)
+ goto do_dead;
if (!*timeo_p)
goto do_nonblock;
- if (sk->sk_err || asoc->state >= SCTP_STATE_SHUTDOWN_PENDING ||
- asoc->base.dead)
+ if (sk->sk_err || asoc->state >= SCTP_STATE_SHUTDOWN_PENDING)
goto do_error;
if (signal_pending(current))
goto do_interrupted;
@@ -7027,6 +7034,10 @@ out:
return err;
+do_dead:
+ err = -ESRCH;
+ goto out;
+
do_error:
err = -EPIPE;
goto out;
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-3.18/route-update-fnhe_expires-for-redirect-when-the-fnhe-exists.patch
queue-3.18/route-also-update-fnhe_genid-when-updating-a-route-cache.patch
queue-3.18/sctp-use-the-right-sk-after-waking-up-from-wait_buf-sleep.patch
queue-3.18/sctp-do-not-free-asoc-when-it-is-already-dead-in-sctp_sendmsg.patch
This is a note to let you know that I've just added the patch titled
route: update fnhe_expires for redirect when the fnhe exists
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
route-update-fnhe_expires-for-redirect-when-the-fnhe-exists.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Fri, 17 Nov 2017 14:27:06 +0800
Subject: route: update fnhe_expires for redirect when the fnhe exists
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit e39d5246111399dbc6e11cd39fd8580191b86c47 ]
Now when creating fnhe for redirect, it sets fnhe_expires for this
new route cache. But when updating the exist one, it doesn't do it.
It will cause this fnhe never to be expired.
Paolo already noticed it before, in Jianlin's test case, it became
even worse:
When ip route flush cache, the old fnhe is not to be removed, but
only clean it's members. When redirect comes again, this fnhe will
be found and updated, but never be expired due to fnhe_expires not
being set.
So fix it by simply updating fnhe_expires even it's for redirect.
Fixes: aee06da6726d ("ipv4: use seqlock for nh_exceptions")
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Acked-by: Hannes Frederic Sowa <hannes(a)stressinduktion.org>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/route.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -654,10 +654,9 @@ static void update_or_create_fnhe(struct
fnhe->fnhe_genid = genid;
if (gw)
fnhe->fnhe_gw = gw;
- if (pmtu) {
+ if (pmtu)
fnhe->fnhe_pmtu = pmtu;
- fnhe->fnhe_expires = max(1UL, expires);
- }
+ fnhe->fnhe_expires = max(1UL, expires);
/* Update all cached dsts too */
rt = rcu_dereference(fnhe->fnhe_rth_input);
if (rt)
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-3.18/route-update-fnhe_expires-for-redirect-when-the-fnhe-exists.patch
queue-3.18/route-also-update-fnhe_genid-when-updating-a-route-cache.patch
queue-3.18/sctp-use-the-right-sk-after-waking-up-from-wait_buf-sleep.patch
queue-3.18/sctp-do-not-free-asoc-when-it-is-already-dead-in-sctp_sendmsg.patch
This is a note to let you know that I've just added the patch titled
route: also update fnhe_genid when updating a route cache
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
route-also-update-fnhe_genid-when-updating-a-route-cache.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Fri, 17 Nov 2017 14:27:18 +0800
Subject: route: also update fnhe_genid when updating a route cache
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit cebe84c6190d741045a322f5343f717139993c08 ]
Now when ip route flush cache and it turn out all fnhe_genid != genid.
If a redirect/pmtu icmp packet comes and the old fnhe is found and all
it's members but fnhe_genid will be updated.
Then next time when it looks up route and tries to rebind this fnhe to
the new dst, the fnhe will be flushed due to fnhe_genid != genid. It
causes this redirect/pmtu icmp packet acutally not to be applied.
This patch is to also reset fnhe_genid when updating a route cache.
Fixes: 5aad1de5ea2c ("ipv4: use separate genid for next hop exceptions")
Acked-by: Hannes Frederic Sowa <hannes(a)stressinduktion.org>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/route.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -622,9 +622,12 @@ static void update_or_create_fnhe(struct
struct fnhe_hash_bucket *hash;
struct fib_nh_exception *fnhe;
struct rtable *rt;
+ u32 genid, hval;
unsigned int i;
int depth;
- u32 hval = fnhe_hashfun(daddr);
+
+ genid = fnhe_genid(dev_net(nh->nh_dev));
+ hval = fnhe_hashfun(daddr);
spin_lock_bh(&fnhe_lock);
@@ -647,6 +650,8 @@ static void update_or_create_fnhe(struct
}
if (fnhe) {
+ if (fnhe->fnhe_genid != genid)
+ fnhe->fnhe_genid = genid;
if (gw)
fnhe->fnhe_gw = gw;
if (pmtu) {
@@ -671,7 +676,7 @@ static void update_or_create_fnhe(struct
fnhe->fnhe_next = hash->chain;
rcu_assign_pointer(hash->chain, fnhe);
}
- fnhe->fnhe_genid = fnhe_genid(dev_net(nh->nh_dev));
+ fnhe->fnhe_genid = genid;
fnhe->fnhe_daddr = daddr;
fnhe->fnhe_gw = gw;
fnhe->fnhe_pmtu = pmtu;
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-3.18/route-update-fnhe_expires-for-redirect-when-the-fnhe-exists.patch
queue-3.18/route-also-update-fnhe_genid-when-updating-a-route-cache.patch
queue-3.18/sctp-use-the-right-sk-after-waking-up-from-wait_buf-sleep.patch
queue-3.18/sctp-do-not-free-asoc-when-it-is-already-dead-in-sctp_sendmsg.patch
This is a note to let you know that I've just added the patch titled
scsi: lpfc: Fix crash during Hardware error recovery on SLI3 adapters
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-lpfc-fix-crash-during-hardware-error-recovery-on-sli3-adapters.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: James Smart <jsmart2021(a)gmail.com>
Date: Sat, 4 Mar 2017 09:30:25 -0800
Subject: scsi: lpfc: Fix crash during Hardware error recovery on SLI3 adapters
From: James Smart <jsmart2021(a)gmail.com>
[ Upstream commit 5d181531bc6169e19a02a27d202cf0e982db9d0e ]
if REG_VPI fails, the driver was incorrectly issuing INIT_VFI
(a SLI4 command) on a SLI3 adapter.
Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com>
Signed-off-by: James Smart <james.smart(a)broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/lpfc/lpfc_els.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -7265,11 +7265,17 @@ lpfc_cmpl_reg_new_vport(struct lpfc_hba
spin_lock_irq(shost->host_lock);
vport->fc_flag |= FC_VPORT_NEEDS_REG_VPI;
spin_unlock_irq(shost->host_lock);
- if (vport->port_type == LPFC_PHYSICAL_PORT
- && !(vport->fc_flag & FC_LOGO_RCVD_DID_CHNG))
- lpfc_issue_init_vfi(vport);
- else
+ if (mb->mbxStatus == MBX_NOT_FINISHED)
+ break;
+ if ((vport->port_type == LPFC_PHYSICAL_PORT) &&
+ !(vport->fc_flag & FC_LOGO_RCVD_DID_CHNG)) {
+ if (phba->sli_rev == LPFC_SLI_REV4)
+ lpfc_issue_init_vfi(vport);
+ else
+ lpfc_initial_flogi(vport);
+ } else {
lpfc_initial_fdisc(vport);
+ }
break;
}
} else {
Patches currently in stable-queue which might be from jsmart2021(a)gmail.com are
queue-3.18/scsi-lpfc-fix-crash-during-hardware-error-recovery-on-sli3-adapters.patch
This is a note to let you know that I've just added the patch titled
Revert "drm/armada: Fix compile fail"
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-drm-armada-fix-compile-fail.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Sasha Levin <alexander.levin(a)verizon.com>
Date: Thu, 7 Dec 2017 23:21:06 -0500
Subject: Revert "drm/armada: Fix compile fail"
From: Sasha Levin <alexander.levin(a)verizon.com>
This reverts commit 82f260d472c3b4dbb7324624e395c3e91f73a040.
Not required on < 4.10.
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/armada/Makefile | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/gpu/drm/armada/Makefile
+++ b/drivers/gpu/drm/armada/Makefile
@@ -5,5 +5,3 @@ armada-y += armada_510.o
armada-$(CONFIG_DEBUG_FS) += armada_debugfs.o
obj-$(CONFIG_DRM_ARMADA) := armada.o
-
-CFLAGS_armada_trace.o := -I$(src)
Patches currently in stable-queue which might be from alexander.levin(a)verizon.com are
queue-3.18/xfrm-copy-policy-family-in-clone_policy.patch
queue-3.18/scsi-lpfc-fix-crash-during-hardware-error-recovery-on-sli3-adapters.patch
queue-3.18/atm-horizon-fix-irq-release-error.patch
queue-3.18/ipv6-reorder-icmpv6_init-and-ip6_mr_init.patch
queue-3.18/kvm-nvmx-reset-nested_run_pending-if-the-vcpu-is-going-to-be-reset.patch
queue-3.18/axonram-fix-gendisk-handling.patch
queue-3.18/usb-gadgetfs-fix-a-potential-memory-leak-in-dev_config.patch
queue-3.18/spi_ks8995-fix-bug-key-accdaa28-not-in-.data.patch
queue-3.18/bnx2x-fix-possible-overrun-of-vfpf-multicast-addresses-array.patch
queue-3.18/sunrpc-fix-rpc_task_begin-trace-point.patch
queue-3.18/arm-kvm-survive-unknown-traps-from-guests.patch
queue-3.18/crypto-s5p-sss-fix-completing-crypto-request-in-irq-handler.patch
queue-3.18/ib-mlx5-assign-send-cq-and-recv-cq-of-umr-qp.patch
queue-3.18/lib-genalloc.c-make-the-avail-variable-an-atomic_long_t.patch
queue-3.18/afs-connect-up-the-cb.probeuuid.patch
queue-3.18/route-update-fnhe_expires-for-redirect-when-the-fnhe-exists.patch
queue-3.18/edac-i5000-i5400-fix-definition-of-nrecmemb-register.patch
queue-3.18/libata-drop-warn-from-protocol-error-in-ata_sff_qc_issue.patch
queue-3.18/nfs-fix-a-typo-in-nfs_rename.patch
queue-3.18/audit-ensure-that-audit-1-actually-enables-audit-for-pid-1.patch
queue-3.18/sparc64-mm-set-fields-in-deferred-pages.patch
queue-3.18/route-also-update-fnhe_genid-when-updating-a-route-cache.patch
queue-3.18/selftest-powerpc-fix-false-failures-for-skipped-tests.patch
queue-3.18/edac-i5000-i5400-fix-use-of-mtr_dram_width-macro.patch
queue-3.18/workqueue-trigger-warn-if-queue_delayed_work-is-called-with-null-wq.patch
queue-3.18/irqchip-crossbar-fix-incorrect-type-of-register-size.patch
queue-3.18/revert-s390-kbuild-enable-modversions-for-symbols-exported-from-asm.patch
queue-3.18/sctp-use-the-right-sk-after-waking-up-from-wait_buf-sleep.patch
queue-3.18/dynamic-debug-howto-fix-optional-omitted-ending-line-number-to-be-large-instead-of-0.patch
queue-3.18/i2c-riic-fix-restart-condition.patch
queue-3.18/ib-mlx4-increase-maximal-message-size-under-ud-qp.patch
queue-3.18/usb-gadget-configs-plug-memory-leak.patch
queue-3.18/revert-drm-armada-fix-compile-fail.patch
queue-3.18/sctp-do-not-free-asoc-when-it-is-already-dead-in-sctp_sendmsg.patch
This is a note to let you know that I've just added the patch titled
Revert "s390/kbuild: enable modversions for symbols exported from asm"
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
revert-s390-kbuild-enable-modversions-for-symbols-exported-from-asm.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Sasha Levin <alexander.levin(a)verizon.com>
Date: Fri, 8 Dec 2017 00:11:47 -0500
Subject: Revert "s390/kbuild: enable modversions for symbols exported from asm"
From: Sasha Levin <alexander.levin(a)verizon.com>
This reverts commit cabab3f9f5ca077535080b3252e6168935b914af.
Not needed for < 4.9.
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/s390/include/asm/asm-prototypes.h | 8 --------
1 file changed, 8 deletions(-)
delete mode 100644 arch/s390/include/asm/asm-prototypes.h
--- a/arch/s390/include/asm/asm-prototypes.h
+++ /dev/null
@@ -1,8 +0,0 @@
-#ifndef _ASM_S390_PROTOTYPES_H
-
-#include <linux/kvm_host.h>
-#include <linux/ftrace.h>
-#include <asm/fpu/api.h>
-#include <asm-generic/asm-prototypes.h>
-
-#endif /* _ASM_S390_PROTOTYPES_H */
Patches currently in stable-queue which might be from alexander.levin(a)verizon.com are
queue-3.18/xfrm-copy-policy-family-in-clone_policy.patch
queue-3.18/scsi-lpfc-fix-crash-during-hardware-error-recovery-on-sli3-adapters.patch
queue-3.18/atm-horizon-fix-irq-release-error.patch
queue-3.18/ipv6-reorder-icmpv6_init-and-ip6_mr_init.patch
queue-3.18/kvm-nvmx-reset-nested_run_pending-if-the-vcpu-is-going-to-be-reset.patch
queue-3.18/axonram-fix-gendisk-handling.patch
queue-3.18/usb-gadgetfs-fix-a-potential-memory-leak-in-dev_config.patch
queue-3.18/spi_ks8995-fix-bug-key-accdaa28-not-in-.data.patch
queue-3.18/bnx2x-fix-possible-overrun-of-vfpf-multicast-addresses-array.patch
queue-3.18/sunrpc-fix-rpc_task_begin-trace-point.patch
queue-3.18/arm-kvm-survive-unknown-traps-from-guests.patch
queue-3.18/crypto-s5p-sss-fix-completing-crypto-request-in-irq-handler.patch
queue-3.18/ib-mlx5-assign-send-cq-and-recv-cq-of-umr-qp.patch
queue-3.18/lib-genalloc.c-make-the-avail-variable-an-atomic_long_t.patch
queue-3.18/afs-connect-up-the-cb.probeuuid.patch
queue-3.18/route-update-fnhe_expires-for-redirect-when-the-fnhe-exists.patch
queue-3.18/edac-i5000-i5400-fix-definition-of-nrecmemb-register.patch
queue-3.18/libata-drop-warn-from-protocol-error-in-ata_sff_qc_issue.patch
queue-3.18/nfs-fix-a-typo-in-nfs_rename.patch
queue-3.18/audit-ensure-that-audit-1-actually-enables-audit-for-pid-1.patch
queue-3.18/sparc64-mm-set-fields-in-deferred-pages.patch
queue-3.18/route-also-update-fnhe_genid-when-updating-a-route-cache.patch
queue-3.18/selftest-powerpc-fix-false-failures-for-skipped-tests.patch
queue-3.18/edac-i5000-i5400-fix-use-of-mtr_dram_width-macro.patch
queue-3.18/workqueue-trigger-warn-if-queue_delayed_work-is-called-with-null-wq.patch
queue-3.18/irqchip-crossbar-fix-incorrect-type-of-register-size.patch
queue-3.18/revert-s390-kbuild-enable-modversions-for-symbols-exported-from-asm.patch
queue-3.18/sctp-use-the-right-sk-after-waking-up-from-wait_buf-sleep.patch
queue-3.18/dynamic-debug-howto-fix-optional-omitted-ending-line-number-to-be-large-instead-of-0.patch
queue-3.18/i2c-riic-fix-restart-condition.patch
queue-3.18/ib-mlx4-increase-maximal-message-size-under-ud-qp.patch
queue-3.18/usb-gadget-configs-plug-memory-leak.patch
queue-3.18/revert-drm-armada-fix-compile-fail.patch
queue-3.18/sctp-do-not-free-asoc-when-it-is-already-dead-in-sctp_sendmsg.patch
This is a note to let you know that I've just added the patch titled
lib/genalloc.c: make the avail variable an atomic_long_t
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
lib-genalloc.c-make-the-avail-variable-an-atomic_long_t.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Stephen Bates <sbates(a)raithlin.com>
Date: Fri, 17 Nov 2017 15:28:16 -0800
Subject: lib/genalloc.c: make the avail variable an atomic_long_t
From: Stephen Bates <sbates(a)raithlin.com>
[ Upstream commit 36a3d1dd4e16bcd0d2ddfb4a2ec7092f0ae0d931 ]
If the amount of resources allocated to a gen_pool exceeds 2^32 then the
avail atomic overflows and this causes problems when clients try and
borrow resources from the pool. This is only expected to be an issue on
64 bit systems.
Add the <linux/atomic.h> header to pull in atomic_long* operations. So
that 32 bit systems continue to use atomic32_t but 64 bit systems can
use atomic64_t.
Link: http://lkml.kernel.org/r/1509033843-25667-1-git-send-email-sbates@raithlin.…
Signed-off-by: Stephen Bates <sbates(a)raithlin.com>
Reviewed-by: Logan Gunthorpe <logang(a)deltatee.com>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com>
Reviewed-by: Daniel Mentz <danielmentz(a)google.com>
Cc: Jonathan Corbet <corbet(a)lwn.net>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/genalloc.h | 3 ++-
lib/genalloc.c | 10 +++++-----
2 files changed, 7 insertions(+), 6 deletions(-)
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -31,6 +31,7 @@
#define __GENALLOC_H__
#include <linux/spinlock_types.h>
+#include <linux/atomic.h>
struct device;
struct device_node;
@@ -66,7 +67,7 @@ struct gen_pool {
*/
struct gen_pool_chunk {
struct list_head next_chunk; /* next chunk in pool */
- atomic_t avail;
+ atomic_long_t avail;
phys_addr_t phys_addr; /* physical starting address of memory chunk */
unsigned long start_addr; /* start address of memory chunk */
unsigned long end_addr; /* end address of memory chunk (inclusive) */
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -194,7 +194,7 @@ int gen_pool_add_virt(struct gen_pool *p
chunk->phys_addr = phys;
chunk->start_addr = virt;
chunk->end_addr = virt + size - 1;
- atomic_set(&chunk->avail, size);
+ atomic_long_set(&chunk->avail, size);
spin_lock(&pool->lock);
list_add_rcu(&chunk->next_chunk, &pool->chunks);
@@ -285,7 +285,7 @@ unsigned long gen_pool_alloc(struct gen_
nbits = (size + (1UL << order) - 1) >> order;
rcu_read_lock();
list_for_each_entry_rcu(chunk, &pool->chunks, next_chunk) {
- if (size > atomic_read(&chunk->avail))
+ if (size > atomic_long_read(&chunk->avail))
continue;
end_bit = chunk_size(chunk) >> order;
@@ -304,7 +304,7 @@ retry:
addr = chunk->start_addr + ((unsigned long)start_bit << order);
size = nbits << order;
- atomic_sub(size, &chunk->avail);
+ atomic_long_sub(size, &chunk->avail);
break;
}
rcu_read_unlock();
@@ -370,7 +370,7 @@ void gen_pool_free(struct gen_pool *pool
remain = bitmap_clear_ll(chunk->bits, start_bit, nbits);
BUG_ON(remain);
size = nbits << order;
- atomic_add(size, &chunk->avail);
+ atomic_long_add(size, &chunk->avail);
rcu_read_unlock();
return;
}
@@ -444,7 +444,7 @@ size_t gen_pool_avail(struct gen_pool *p
rcu_read_lock();
list_for_each_entry_rcu(chunk, &pool->chunks, next_chunk)
- avail += atomic_read(&chunk->avail);
+ avail += atomic_long_read(&chunk->avail);
rcu_read_unlock();
return avail;
}
Patches currently in stable-queue which might be from sbates(a)raithlin.com are
queue-3.18/lib-genalloc.c-make-the-avail-variable-an-atomic_long_t.patch
This is a note to let you know that I've just added the patch titled
NFS: Fix a typo in nfs_rename()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfs-fix-a-typo-in-nfs_rename.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Mon, 6 Nov 2017 15:28:04 -0500
Subject: NFS: Fix a typo in nfs_rename()
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
[ Upstream commit d803224c84be067754db7fa58a93f36f61566493 ]
On successful rename, the "old_dentry" is retained and is attached to
the "new_dir", so we need to call nfs_set_verifier() accordingly.
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -2063,7 +2063,7 @@ out:
if (new_inode != NULL)
nfs_drop_nlink(new_inode);
d_move(old_dentry, new_dentry);
- nfs_set_verifier(new_dentry,
+ nfs_set_verifier(old_dentry,
nfs_save_change_attribute(new_dir));
} else if (error == -ENOENT)
nfs_dentry_handle_enoent(old_dentry);
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-3.18/nfs-fix-a-typo-in-nfs_rename.patch
This is a note to let you know that I've just added the patch titled
libata: drop WARN from protocol error in ata_sff_qc_issue()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
libata-drop-warn-from-protocol-error-in-ata_sff_qc_issue.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Tejun Heo <tj(a)kernel.org>
Date: Mon, 6 Mar 2017 15:26:54 -0500
Subject: libata: drop WARN from protocol error in ata_sff_qc_issue()
From: Tejun Heo <tj(a)kernel.org>
[ Upstream commit 0580b762a4d6b70817476b90042813f8573283fa ]
ata_sff_qc_issue() expects upper layers to never issue commands on a
command protocol that it doesn't implement. While the assumption
holds fine with the usual IO path, nothing filters based on the
command protocol in the passthrough path (which was added later),
allowing the warning to be tripped with a passthrough command with the
right (well, wrong) protocol.
Failing with AC_ERR_SYSTEM is the right thing to do anyway. Remove
the unnecessary WARN.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Link: http://lkml.kernel.org/r/CACT4Y+bXkvevNZU8uP6X0QVqsj6wNoUA_1exfTSOzc+SmUtMO…
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/libata-sff.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -1480,7 +1480,6 @@ unsigned int ata_sff_qc_issue(struct ata
break;
default:
- WARN_ON_ONCE(1);
return AC_ERR_SYSTEM;
}
Patches currently in stable-queue which might be from tj(a)kernel.org are
queue-3.18/libata-drop-warn-from-protocol-error-in-ata_sff_qc_issue.patch
queue-3.18/workqueue-trigger-warn-if-queue_delayed_work-is-called-with-null-wq.patch
This is a note to let you know that I've just added the patch titled
KVM: nVMX: reset nested_run_pending if the vCPU is going to be reset
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-nvmx-reset-nested_run_pending-if-the-vcpu-is-going-to-be-reset.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
Date: Mon, 6 Mar 2017 04:03:28 -0800
Subject: KVM: nVMX: reset nested_run_pending if the vCPU is going to be reset
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
[ Upstream commit 2f707d97982286b307ef2a9b034e19aabc1abb56 ]
Reported by syzkaller:
WARNING: CPU: 1 PID: 27742 at arch/x86/kvm/vmx.c:11029
nested_vmx_vmexit+0x5c35/0x74d0 arch/x86/kvm/vmx.c:11029
CPU: 1 PID: 27742 Comm: a.out Not tainted 4.10.0+ #229
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:15 [inline]
dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
panic+0x1fb/0x412 kernel/panic.c:179
__warn+0x1c4/0x1e0 kernel/panic.c:540
warn_slowpath_null+0x2c/0x40 kernel/panic.c:583
nested_vmx_vmexit+0x5c35/0x74d0 arch/x86/kvm/vmx.c:11029
vmx_leave_nested arch/x86/kvm/vmx.c:11136 [inline]
vmx_set_msr+0x1565/0x1910 arch/x86/kvm/vmx.c:3324
kvm_set_msr+0xd4/0x170 arch/x86/kvm/x86.c:1099
do_set_msr+0x11e/0x190 arch/x86/kvm/x86.c:1128
__msr_io arch/x86/kvm/x86.c:2577 [inline]
msr_io+0x24b/0x450 arch/x86/kvm/x86.c:2614
kvm_arch_vcpu_ioctl+0x35b/0x46a0 arch/x86/kvm/x86.c:3497
kvm_vcpu_ioctl+0x232/0x1120 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2721
vfs_ioctl fs/ioctl.c:43 [inline]
do_vfs_ioctl+0x1bf/0x1790 fs/ioctl.c:683
SYSC_ioctl fs/ioctl.c:698 [inline]
SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689
entry_SYSCALL_64_fastpath+0x1f/0xc2
The syzkaller folks reported a nested_run_pending warning during userspace
clear VMX capability which is exposed to L1 before.
The warning gets thrown while doing
(*(uint32_t*)0x20aecfe8 = (uint32_t)0x1);
(*(uint32_t*)0x20aecfec = (uint32_t)0x0);
(*(uint32_t*)0x20aecff0 = (uint32_t)0x3a);
(*(uint32_t*)0x20aecff4 = (uint32_t)0x0);
(*(uint64_t*)0x20aecff8 = (uint64_t)0x0);
r[29] = syscall(__NR_ioctl, r[4], 0x4008ae89ul,
0x20aecfe8ul, 0, 0, 0, 0, 0, 0);
i.e. KVM_SET_MSR ioctl with
struct kvm_msrs {
.nmsrs = 1,
.pad = 0,
.entries = {
{.index = MSR_IA32_FEATURE_CONTROL,
.reserved = 0,
.data = 0}
}
}
The VMLANCH/VMRESUME emulation should be stopped since the CPU is going to
reset here. This patch resets the nested_run_pending since the CPU is going
to be reset hence there should be nothing pending.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Suggested-by: Radim Krčmář <rkrcmar(a)redhat.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: David Hildenbrand <david(a)redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Reviewed-by: Jim Mattson <jmattson(a)google.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -9086,8 +9086,10 @@ static void nested_vmx_vmexit(struct kvm
*/
static void vmx_leave_nested(struct kvm_vcpu *vcpu)
{
- if (is_guest_mode(vcpu))
+ if (is_guest_mode(vcpu)) {
+ to_vmx(vcpu)->nested.nested_run_pending = 0;
nested_vmx_vmexit(vcpu, -1, 0, 0);
+ }
free_nested(to_vmx(vcpu));
}
Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are
queue-3.18/kvm-nvmx-reset-nested_run_pending-if-the-vcpu-is-going-to-be-reset.patch
This is a note to let you know that I've just added the patch titled
ipv6: reorder icmpv6_init() and ip6_mr_init()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipv6-reorder-icmpv6_init-and-ip6_mr_init.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Dec 14 21:30:47 CET 2017
From: WANG Cong <xiyou.wangcong(a)gmail.com>
Date: Sun, 5 Mar 2017 12:34:53 -0800
Subject: ipv6: reorder icmpv6_init() and ip6_mr_init()
From: WANG Cong <xiyou.wangcong(a)gmail.com>
[ Upstream commit 15e668070a64bb97f102ad9cf3bccbca0545cda8 ]
Andrey reported the following kernel crash:
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 14446 Comm: syz-executor6 Not tainted 4.10.0+ #82
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88001f311700 task.stack: ffff88001f6e8000
RIP: 0010:ip6mr_sk_done+0x15a/0x3d0 net/ipv6/ip6mr.c:1618
RSP: 0018:ffff88001f6ef418 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 1ffff10003edde8c RCX: ffffc900043ee000
RDX: 0000000000000004 RSI: ffffffff83e3b3f8 RDI: 0000000000000020
RBP: ffff88001f6ef508 R08: fffffbfff0dcc5d8 R09: 0000000000000000
R10: ffffffff86e62ec0 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: ffff88001f6ef4e0 R15: ffff8800380a0040
FS: 00007f7a52cec700(0000) GS:ffff88003ec00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000061c500 CR3: 000000001f1ae000 CR4: 00000000000006f0
DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Call Trace:
rawv6_close+0x4c/0x80 net/ipv6/raw.c:1217
inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
inet6_release+0x50/0x70 net/ipv6/af_inet6.c:432
sock_release+0x8d/0x1e0 net/socket.c:597
__sock_create+0x39d/0x880 net/socket.c:1226
sock_create_kern+0x3f/0x50 net/socket.c:1243
inet_ctl_sock_create+0xbb/0x280 net/ipv4/af_inet.c:1526
icmpv6_sk_init+0x163/0x500 net/ipv6/icmp.c:954
ops_init+0x10a/0x550 net/core/net_namespace.c:115
setup_net+0x261/0x660 net/core/net_namespace.c:291
copy_net_ns+0x27e/0x540 net/core/net_namespace.c:396
9pnet_virtio: no channels available for device ./file1
create_new_namespaces+0x437/0x9b0 kernel/nsproxy.c:106
unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:205
SYSC_unshare kernel/fork.c:2281 [inline]
SyS_unshare+0x64e/0x1000 kernel/fork.c:2231
entry_SYSCALL_64_fastpath+0x1f/0xc2
This is because net->ipv6.mr6_tables is not initialized at that point,
ip6mr_rules_init() is not called yet, therefore on the error path when
we iterator the list, we trigger this oops. Fix this by reordering
ip6mr_rules_init() before icmpv6_sk_init().
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/af_inet6.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -887,12 +887,12 @@ static int __init inet6_init(void)
err = register_pernet_subsys(&inet6_net_ops);
if (err)
goto register_pernet_fail;
- err = icmpv6_init();
- if (err)
- goto icmp_fail;
err = ip6_mr_init();
if (err)
goto ipmr_fail;
+ err = icmpv6_init();
+ if (err)
+ goto icmp_fail;
err = ndisc_init();
if (err)
goto ndisc_fail;
@@ -1010,10 +1010,10 @@ igmp_fail:
ndisc_cleanup();
ndisc_fail:
ip6_mr_cleanup();
-ipmr_fail:
- icmpv6_cleanup();
icmp_fail:
unregister_pernet_subsys(&inet6_net_ops);
+ipmr_fail:
+ icmpv6_cleanup();
register_pernet_fail:
sock_unregister(PF_INET6);
rtnl_unregister_all(PF_INET6);
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-3.18/ipv6-reorder-icmpv6_init-and-ip6_mr_init.patch