This is a note to let you know that I've just added the patch titled
rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete
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:
rds-tcp-atomically-purge-entries-from-rds_tcp_conn_list-during-netns-delete.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 f10b4cff98c6977668434fbf5dd58695eeca2897 Mon Sep 17 00:00:00 2001
From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
Date: Thu, 30 Nov 2017 11:11:29 -0800
Subject: rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete
From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
commit f10b4cff98c6977668434fbf5dd58695eeca2897 upstream.
The rds_tcp_kill_sock() function parses the rds_tcp_conn_list
to find the rds_connection entries marked for deletion as part
of the netns deletion under the protection of the rds_tcp_conn_lock.
Since the rds_tcp_conn_list tracks rds_tcp_connections (which
have a 1:1 mapping with rds_conn_path), multiple tc entries in
the rds_tcp_conn_list will map to a single rds_connection, and will
be deleted as part of the rds_conn_destroy() operation that is
done outside the rds_tcp_conn_lock.
The rds_tcp_conn_list traversal done under the protection of
rds_tcp_conn_lock should not leave any doomed tc entries in
the list after the rds_tcp_conn_lock is released, else another
concurrently executiong netns delete (for a differnt netns) thread
may trip on these entries.
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/rds/tcp.c | 9 +++++++--
net/rds/tcp.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -303,7 +303,8 @@ static void rds_tcp_conn_free(void *arg)
rdsdebug("freeing tc %p\n", tc);
spin_lock_irqsave(&rds_tcp_conn_lock, flags);
- list_del(&tc->t_tcp_node);
+ if (!tc->t_tcp_node_detached)
+ list_del(&tc->t_tcp_node);
spin_unlock_irqrestore(&rds_tcp_conn_lock, flags);
kmem_cache_free(rds_tcp_conn_slab, tc);
@@ -528,8 +529,12 @@ static void rds_tcp_kill_sock(struct net
if (net != c_net || !tc->t_sock)
continue;
- if (!list_has_conn(&tmp_list, tc->t_cpath->cp_conn))
+ if (!list_has_conn(&tmp_list, tc->t_cpath->cp_conn)) {
list_move_tail(&tc->t_tcp_node, &tmp_list);
+ } else {
+ list_del(&tc->t_tcp_node);
+ tc->t_tcp_node_detached = true;
+ }
}
spin_unlock_irq(&rds_tcp_conn_lock);
list_for_each_entry_safe(tc, _tc, &tmp_list, t_tcp_node) {
--- a/net/rds/tcp.h
+++ b/net/rds/tcp.h
@@ -11,6 +11,7 @@ struct rds_tcp_incoming {
struct rds_tcp_connection {
struct list_head t_tcp_node;
+ bool t_tcp_node_detached;
struct rds_conn_path *t_cpath;
/* t_conn_path_lock synchronizes the connection establishment between
* rds_tcp_accept_one and rds_tcp_conn_path_connect
Patches currently in stable-queue which might be from sowmini.varadhan(a)oracle.com are
queue-4.9/rds-tcp-atomically-purge-entries-from-rds_tcp_conn_list-during-netns-delete.patch
This is a note to let you know that I've just added the patch titled
ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE
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:
ptr_ring-fail-early-if-queue-occupies-more-than-kmalloc_max_size.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 6e6e41c3112276288ccaf80c70916779b84bb276 Mon Sep 17 00:00:00 2001
From: Jason Wang <jasowang(a)redhat.com>
Date: Fri, 9 Feb 2018 17:45:49 +0800
Subject: ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE
From: Jason Wang <jasowang(a)redhat.com>
commit 6e6e41c3112276288ccaf80c70916779b84bb276 upstream.
To avoid slab to warn about exceeded size, fail early if queue
occupies more than KMALLOC_MAX_SIZE.
Reported-by: syzbot+e4d4f9ddd4295539735d(a)syzkaller.appspotmail.com
Fixes: 2e0ab8ca83c12 ("ptr_ring: array based FIFO for pointers")
Signed-off-by: Jason Wang <jasowang(a)redhat.com>
Acked-by: Michael S. Tsirkin <mst(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/ptr_ring.h | 2 ++
1 file changed, 2 insertions(+)
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -351,6 +351,8 @@ static inline void *ptr_ring_consume_bh(
static inline void **__ptr_ring_init_queue_alloc(unsigned int size, gfp_t gfp)
{
+ if (size * sizeof(void *) > KMALLOC_MAX_SIZE)
+ return NULL;
return kcalloc(size, sizeof(void *), gfp);
}
Patches currently in stable-queue which might be from jasowang(a)redhat.com are
queue-4.9/vhost-use-mutex_lock_nested-in-vhost_dev_lock_vqs.patch
queue-4.9/ptr_ring-fail-early-if-queue-occupies-more-than-kmalloc_max_size.patch
This is a note to let you know that I've just added the patch titled
netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
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:
netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.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 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Mon, 5 Feb 2018 14:41:45 -0800
Subject: netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 upstream.
rateest_hash is supposed to be protected by xt_rateest_mutex,
and, as suggested by Eric, lookup and insert should be atomic,
so we should acquire the xt_rateest_mutex once for both.
So introduce a non-locking helper for internal use and keep the
locking one for external.
Reported-by: <syzbot+5cb189720978275e4c75(a)syzkaller.appspotmail.com>
Fixes: 5859034d7eb8 ("[NETFILTER]: x_tables: add RATEEST target")
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Reviewed-by: Florian Westphal <fw(a)strlen.de>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/xt_RATEEST.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
--- a/net/netfilter/xt_RATEEST.c
+++ b/net/netfilter/xt_RATEEST.c
@@ -39,23 +39,31 @@ static void xt_rateest_hash_insert(struc
hlist_add_head(&est->list, &rateest_hash[h]);
}
-struct xt_rateest *xt_rateest_lookup(const char *name)
+static struct xt_rateest *__xt_rateest_lookup(const char *name)
{
struct xt_rateest *est;
unsigned int h;
h = xt_rateest_hash(name);
- mutex_lock(&xt_rateest_mutex);
hlist_for_each_entry(est, &rateest_hash[h], list) {
if (strcmp(est->name, name) == 0) {
est->refcnt++;
- mutex_unlock(&xt_rateest_mutex);
return est;
}
}
- mutex_unlock(&xt_rateest_mutex);
+
return NULL;
}
+
+struct xt_rateest *xt_rateest_lookup(const char *name)
+{
+ struct xt_rateest *est;
+
+ mutex_lock(&xt_rateest_mutex);
+ est = __xt_rateest_lookup(name);
+ mutex_unlock(&xt_rateest_mutex);
+ return est;
+}
EXPORT_SYMBOL_GPL(xt_rateest_lookup);
void xt_rateest_put(struct xt_rateest *est)
@@ -100,8 +108,10 @@ static int xt_rateest_tg_checkentry(cons
net_get_random_once(&jhash_rnd, sizeof(jhash_rnd));
- est = xt_rateest_lookup(info->name);
+ mutex_lock(&xt_rateest_mutex);
+ est = __xt_rateest_lookup(info->name);
if (est) {
+ mutex_unlock(&xt_rateest_mutex);
/*
* If estimator parameters are specified, they must match the
* existing estimator.
@@ -139,11 +149,13 @@ static int xt_rateest_tg_checkentry(cons
info->est = est;
xt_rateest_hash_insert(est);
+ mutex_unlock(&xt_rateest_mutex);
return 0;
err2:
kfree(est);
err1:
+ mutex_unlock(&xt_rateest_mutex);
return ret;
}
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.9/netfilter-xt_cgroup-initialize-info-priv-in-cgroup_mt_check_v1.patch
queue-4.9/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
queue-4.9/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
Provide a function to create a NUL-terminated string from unterminated data
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:
provide-a-function-to-create-a-nul-terminated-string-from-unterminated-data.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 f35157417215ec138c920320c746fdb3e04ef1d5 Mon Sep 17 00:00:00 2001
From: David Howells <dhowells(a)redhat.com>
Date: Tue, 4 Jul 2017 17:25:02 +0100
Subject: Provide a function to create a NUL-terminated string from unterminated data
From: David Howells <dhowells(a)redhat.com>
commit f35157417215ec138c920320c746fdb3e04ef1d5 upstream.
Provide a function, kmemdup_nul(), that will create a NUL-terminated string
from an unterminated character array where the length is known in advance.
This is better than kstrndup() in situations where we already know the
string length as the strnlen() in kstrndup() is superfluous.
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/string.h | 1 +
mm/util.c | 24 ++++++++++++++++++++++++
2 files changed, 25 insertions(+)
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -123,6 +123,7 @@ extern char *kstrdup(const char *s, gfp_
extern const char *kstrdup_const(const char *s, gfp_t gfp);
extern char *kstrndup(const char *s, size_t len, gfp_t gfp);
extern void *kmemdup(const void *src, size_t len, gfp_t gfp);
+extern char *kmemdup_nul(const char *s, size_t len, gfp_t gfp);
extern char **argv_split(gfp_t gfp, const char *str, int *argcp);
extern void argv_free(char **argv);
--- a/mm/util.c
+++ b/mm/util.c
@@ -80,6 +80,8 @@ EXPORT_SYMBOL(kstrdup_const);
* @s: the string to duplicate
* @max: read at most @max chars from @s
* @gfp: the GFP mask used in the kmalloc() call when allocating memory
+ *
+ * Note: Use kmemdup_nul() instead if the size is known exactly.
*/
char *kstrndup(const char *s, size_t max, gfp_t gfp)
{
@@ -118,6 +120,28 @@ void *kmemdup(const void *src, size_t le
EXPORT_SYMBOL(kmemdup);
/**
+ * kmemdup_nul - Create a NUL-terminated string from unterminated data
+ * @s: The data to stringify
+ * @len: The size of the data
+ * @gfp: the GFP mask used in the kmalloc() call when allocating memory
+ */
+char *kmemdup_nul(const char *s, size_t len, gfp_t gfp)
+{
+ char *buf;
+
+ if (!s)
+ return NULL;
+
+ buf = kmalloc_track_caller(len + 1, gfp);
+ if (buf) {
+ memcpy(buf, s, len);
+ buf[len] = '\0';
+ }
+ return buf;
+}
+EXPORT_SYMBOL(kmemdup_nul);
+
+/**
* memdup_user - duplicate memory region from user space
*
* @src: source address in user space
Patches currently in stable-queue which might be from dhowells(a)redhat.com are
queue-4.9/provide-a-function-to-create-a-nul-terminated-string-from-unterminated-data.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: fix int overflow in xt_alloc_table_info()
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:
netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.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 889c604fd0b5f6d3b8694ade229ee44124de1127 Mon Sep 17 00:00:00 2001
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Thu, 28 Dec 2017 09:48:54 +0100
Subject: netfilter: x_tables: fix int overflow in xt_alloc_table_info()
From: Dmitry Vyukov <dvyukov(a)google.com>
commit 889c604fd0b5f6d3b8694ade229ee44124de1127 upstream.
syzkaller triggered OOM kills by passing ipt_replace.size = -1
to IPT_SO_SET_REPLACE. The root cause is that SMP_ALIGN() in
xt_alloc_table_info() causes int overflow and the size check passes
when it should not. SMP_ALIGN() is no longer needed leftover.
Remove SMP_ALIGN() call in xt_alloc_table_info().
Reported-by: syzbot+4396883fa8c4f64e0175(a)syzkaller.appspotmail.com
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/x_tables.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -39,8 +39,6 @@ MODULE_LICENSE("GPL");
MODULE_AUTHOR("Harald Welte <laforge(a)netfilter.org>");
MODULE_DESCRIPTION("{ip,ip6,arp,eb}_tables backend module");
-#define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1))
-
struct compat_delta {
unsigned int offset; /* offset in kernel */
int delta; /* delta in 32bit user land */
@@ -952,7 +950,7 @@ struct xt_table_info *xt_alloc_table_inf
return NULL;
/* Pedantry: prevent them from hitting BUG() in vmalloc.c --RR */
- if ((SMP_ALIGN(size) >> PAGE_SHIFT) + 2 > totalram_pages)
+ if ((size >> PAGE_SHIFT) + 2 > totalram_pages)
return NULL;
if (sz <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER))
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-4.9/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
queue-4.9/blktrace-fix-unlocked-registration-of-tracepoints.patch
queue-4.9/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
queue-4.9/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
queue-4.9/kcov-detect-double-association-with-a-single-task.patch
This is a note to let you know that I've just added the patch titled
netfilter: xt_cgroup: initialize info->priv in cgroup_mt_check_v1()
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:
netfilter-xt_cgroup-initialize-info-priv-in-cgroup_mt_check_v1.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 ba7cd5d95f25cc6005f687dabdb4e7a6063adda9 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Wed, 31 Jan 2018 15:02:47 -0800
Subject: netfilter: xt_cgroup: initialize info->priv in cgroup_mt_check_v1()
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit ba7cd5d95f25cc6005f687dabdb4e7a6063adda9 upstream.
xt_cgroup_info_v1->priv is an internal pointer only used for kernel,
we should not trust what user-space provides.
Reported-by: <syzbot+4fbcfcc0d2e6592bd641(a)syzkaller.appspotmail.com>
Fixes: c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match")
Cc: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/xt_cgroup.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/netfilter/xt_cgroup.c
+++ b/net/netfilter/xt_cgroup.c
@@ -52,6 +52,7 @@ static int cgroup_mt_check_v1(const stru
return -EINVAL;
}
+ info->priv = NULL;
if (info->has_path) {
cgrp = cgroup_get_from_path(info->path);
if (IS_ERR(cgrp)) {
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.9/netfilter-xt_cgroup-initialize-info-priv-in-cgroup_mt_check_v1.patch
queue-4.9/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
queue-4.9/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
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:
netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.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 da17c73b6eb74aad3c3c0654394635675b623b3e Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 24 Jan 2018 17:16:09 -0800
Subject: netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
From: Eric Dumazet <edumazet(a)google.com>
commit da17c73b6eb74aad3c3c0654394635675b623b3e upstream.
It looks like syzbot found its way into netfilter territory.
Issue here is that @name comes from user space and might
not be null terminated.
Out-of-bound reads happen, KASAN is not happy.
v2 added similar fix for xt_request_find_target(),
as Florian advised.
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Acked-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/x_tables.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -207,6 +207,9 @@ xt_request_find_match(uint8_t nfproto, c
{
struct xt_match *match;
+ if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN)
+ return ERR_PTR(-EINVAL);
+
match = xt_find_match(nfproto, name, revision);
if (IS_ERR(match)) {
request_module("%st_%s", xt_prefix[nfproto], name);
@@ -249,6 +252,9 @@ struct xt_target *xt_request_find_target
{
struct xt_target *target;
+ if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN)
+ return ERR_PTR(-EINVAL);
+
target = xt_find_target(af, name, revision);
if (IS_ERR(target)) {
request_module("%st_%s", xt_prefix[af], name);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.9/kcm-check-if-sk_user_data-already-set-in-kcm_attach.patch
queue-4.9/netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch
queue-4.9/kcm-only-allow-tcp-sockets-to-be-attached-to-a-kcm-mux.patch
queue-4.9/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
This is a note to let you know that I've just added the patch titled
net: avoid skb_warn_bad_offload on IS_ERR
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:
net-avoid-skb_warn_bad_offload-on-is_err.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 8d74e9f88d65af8bb2e095aff506aa6eac755ada Mon Sep 17 00:00:00 2001
From: Willem de Bruijn <willemb(a)google.com>
Date: Tue, 12 Dec 2017 11:39:04 -0500
Subject: net: avoid skb_warn_bad_offload on IS_ERR
From: Willem de Bruijn <willemb(a)google.com>
commit 8d74e9f88d65af8bb2e095aff506aa6eac755ada upstream.
skb_warn_bad_offload warns when packets enter the GSO stack that
require skb_checksum_help or vice versa. Do not warn on arbitrary
bad packets. Packet sockets can craft many. Syzkaller was able to
demonstrate another one with eth_type games.
In particular, suppress the warning when segmentation returns an
error, which is for reasons other than checksum offload.
See also commit 36c92474498a ("net: WARN if skb_checksum_help() is
called on skb requiring segmentation") for context on this warning.
Signed-off-by: Willem de Bruijn <willemb(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2763,7 +2763,7 @@ struct sk_buff *__skb_gso_segment(struct
segs = skb_mac_gso_segment(skb, features);
- if (unlikely(skb_needs_check(skb, tx_path)))
+ if (unlikely(skb_needs_check(skb, tx_path) && !IS_ERR(segs)))
skb_warn_bad_offload(skb);
return segs;
Patches currently in stable-queue which might be from willemb(a)google.com are
queue-4.9/net-avoid-skb_warn_bad_offload-on-is_err.patch
This is a note to let you know that I've just added the patch titled
netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
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:
netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.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 1a38956cce5eabd7b74f94bab70265e4df83165e Mon Sep 17 00:00:00 2001
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Tue, 30 Jan 2018 15:21:34 +0100
Subject: netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
From: Dmitry Vyukov <dvyukov(a)google.com>
commit 1a38956cce5eabd7b74f94bab70265e4df83165e upstream.
Commit 136e92bbec0a switched local_nodes from an array to a bitmask
but did not add proper bounds checks. As the result
clusterip_config_init_nodelist() can both over-read
ipt_clusterip_tgt_info.local_nodes and over-write
clusterip_config.local_nodes.
Add bounds checks for both.
Fixes: 136e92bbec0a ("[NETFILTER] CLUSTERIP: use a bitmap to store node responsibility data")
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/netfilter/ipt_CLUSTERIP.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -365,7 +365,7 @@ static int clusterip_tg_check(const stru
struct ipt_clusterip_tgt_info *cipinfo = par->targinfo;
const struct ipt_entry *e = par->entryinfo;
struct clusterip_config *config;
- int ret;
+ int ret, i;
if (par->nft_compat) {
pr_err("cannot use CLUSTERIP target from nftables compat\n");
@@ -384,8 +384,18 @@ static int clusterip_tg_check(const stru
pr_info("Please specify destination IP\n");
return -EINVAL;
}
-
- /* FIXME: further sanity checks */
+ if (cipinfo->num_local_nodes > ARRAY_SIZE(cipinfo->local_nodes)) {
+ pr_info("bad num_local_nodes %u\n", cipinfo->num_local_nodes);
+ return -EINVAL;
+ }
+ for (i = 0; i < cipinfo->num_local_nodes; i++) {
+ if (cipinfo->local_nodes[i] - 1 >=
+ sizeof(config->local_nodes) * 8) {
+ pr_info("bad local_nodes[%d] %u\n",
+ i, cipinfo->local_nodes[i]);
+ return -EINVAL;
+ }
+ }
config = clusterip_config_find_get(par->net, e->ip.dst.s_addr, 1);
if (!config) {
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-4.9/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
queue-4.9/blktrace-fix-unlocked-registration-of-tracepoints.patch
queue-4.9/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
queue-4.9/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
queue-4.9/kcov-detect-double-association-with-a-single-task.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: fix escape of guest dr6 to the host
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-x86-fix-escape-of-guest-dr6-to-the-host.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 efdab992813fb2ed825745625b83c05032e9cda2 Mon Sep 17 00:00:00 2001
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
Date: Wed, 13 Dec 2017 10:46:40 +0100
Subject: KVM: x86: fix escape of guest dr6 to the host
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
commit efdab992813fb2ed825745625b83c05032e9cda2 upstream.
syzkaller reported:
WARNING: CPU: 0 PID: 12927 at arch/x86/kernel/traps.c:780 do_debug+0x222/0x250
CPU: 0 PID: 12927 Comm: syz-executor Tainted: G OE 4.15.0-rc2+ #16
RIP: 0010:do_debug+0x222/0x250
Call Trace:
<#DB>
debug+0x3e/0x70
RIP: 0010:copy_user_enhanced_fast_string+0x10/0x20
</#DB>
_copy_from_user+0x5b/0x90
SyS_timer_create+0x33/0x80
entry_SYSCALL_64_fastpath+0x23/0x9a
The testcase sets a watchpoint (with perf_event_open) on a buffer that is
passed to timer_create() as the struct sigevent argument. In timer_create(),
copy_from_user()'s rep movsb triggers the BP. The testcase also sets
the debug registers for the guest.
However, KVM only restores host debug registers when the host has active
watchpoints, which triggers a race condition when running the testcase with
multiple threads. The guest's DR6.BS bit can escape to the host before
another thread invokes timer_create(), and do_debug() complains.
The fix is to respect do_debug()'s dr6 invariant when leaving KVM.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Cc: David Hildenbrand <david(a)redhat.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/x86.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2847,6 +2847,12 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *
kvm_x86_ops->vcpu_put(vcpu);
kvm_put_guest_fpu(vcpu);
vcpu->arch.last_host_tsc = rdtsc();
+ /*
+ * If userspace has set any breakpoints or watchpoints, dr6 is restored
+ * on every vmexit, but if not, we might have a stale dr6 from the
+ * guest. do_debug expects dr6 to be cleared after it runs, do the same.
+ */
+ set_debugreg(0, 6);
}
static int kvm_vcpu_ioctl_get_lapic(struct kvm_vcpu *vcpu,
Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are
queue-4.9/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
This is a note to let you know that I've just added the patch titled
kcov: detect double association with a single task
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:
kcov-detect-double-association-with-a-single-task.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 a77660d231f8b3d84fd23ed482e0964f7aa546d6 Mon Sep 17 00:00:00 2001
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Tue, 6 Feb 2018 15:40:28 -0800
Subject: kcov: detect double association with a single task
From: Dmitry Vyukov <dvyukov(a)google.com>
commit a77660d231f8b3d84fd23ed482e0964f7aa546d6 upstream.
Currently KCOV_ENABLE does not check if the current task is already
associated with another kcov descriptor. As the result it is possible
to associate a single task with more than one kcov descriptor, which
later leads to a memory leak of the old descriptor. This relation is
really meant to be one-to-one (task has only one back link).
Extend validation to detect such misuse.
Link: http://lkml.kernel.org/r/20180122082520.15716-1-dvyukov@google.com
Fixes: 5c9a8750a640 ("kernel: add kcov code coverage")
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Reported-by: Shankara Pailoor <sp3485(a)columbia.edu>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: syzbot <syzkaller(a)googlegroups.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>
---
kernel/kcov.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/kcov.c
+++ b/kernel/kcov.c
@@ -220,9 +220,9 @@ static int kcov_ioctl_locked(struct kcov
if (unused != 0 || kcov->mode == KCOV_MODE_DISABLED ||
kcov->area == NULL)
return -EINVAL;
- if (kcov->t != NULL)
- return -EBUSY;
t = current;
+ if (kcov->t != NULL || t->kcov != NULL)
+ return -EBUSY;
/* Cache in task struct for performance. */
t->kcov_size = kcov->size;
t->kcov_area = kcov->area;
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-4.9/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
queue-4.9/blktrace-fix-unlocked-registration-of-tracepoints.patch
queue-4.9/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
queue-4.9/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
queue-4.9/kcov-detect-double-association-with-a-single-task.patch
This is a note to let you know that I've just added the patch titled
kcm: Check if sk_user_data already set in kcm_attach
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:
kcm-check-if-sk_user_data-already-set-in-kcm_attach.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 e5571240236c5652f3e079b1d5866716a7ad819c Mon Sep 17 00:00:00 2001
From: Tom Herbert <tom(a)quantonium.net>
Date: Wed, 24 Jan 2018 12:35:41 -0800
Subject: kcm: Check if sk_user_data already set in kcm_attach
From: Tom Herbert <tom(a)quantonium.net>
commit e5571240236c5652f3e079b1d5866716a7ad819c upstream.
This is needed to prevent sk_user_data being overwritten.
The check is done under the callback lock. This should prevent
a socket from being attached twice to a KCM mux. It also prevents
a socket from being attached for other use cases of sk_user_data
as long as the other cases set sk_user_data under the lock.
Followup work is needed to unify all the use cases of sk_user_data
to use the same locking.
Reported-by: syzbot+114b15f2be420a8886c3(a)syzkaller.appspotmail.com
Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
Signed-off-by: Tom Herbert <tom(a)quantonium.net>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/kcm/kcmsock.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -1404,9 +1404,18 @@ static int kcm_attach(struct socket *soc
return err;
}
- sock_hold(csk);
-
write_lock_bh(&csk->sk_callback_lock);
+
+ /* Check if sk_user_data is aready by KCM or someone else.
+ * Must be done under lock to prevent race conditions.
+ */
+ if (csk->sk_user_data) {
+ write_unlock_bh(&csk->sk_callback_lock);
+ strp_done(&psock->strp);
+ kmem_cache_free(kcm_psockp, psock);
+ return -EALREADY;
+ }
+
psock->save_data_ready = csk->sk_data_ready;
psock->save_write_space = csk->sk_write_space;
psock->save_state_change = csk->sk_state_change;
@@ -1414,8 +1423,11 @@ static int kcm_attach(struct socket *soc
csk->sk_data_ready = psock_data_ready;
csk->sk_write_space = psock_write_space;
csk->sk_state_change = psock_state_change;
+
write_unlock_bh(&csk->sk_callback_lock);
+ sock_hold(csk);
+
/* Finished initialization, now add the psock to the MUX. */
spin_lock_bh(&mux->lock);
head = &mux->psocks;
Patches currently in stable-queue which might be from tom(a)quantonium.net are
queue-4.9/kcm-check-if-sk_user_data-already-set-in-kcm_attach.patch
queue-4.9/kcm-only-allow-tcp-sockets-to-be-attached-to-a-kcm-mux.patch
This is a note to let you know that I've just added the patch titled
kcm: Only allow TCP sockets to be attached to a KCM mux
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:
kcm-only-allow-tcp-sockets-to-be-attached-to-a-kcm-mux.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 581e7226a5d43f629eb6399a121f85f6a15f81be Mon Sep 17 00:00:00 2001
From: Tom Herbert <tom(a)quantonium.net>
Date: Wed, 24 Jan 2018 12:35:40 -0800
Subject: kcm: Only allow TCP sockets to be attached to a KCM mux
From: Tom Herbert <tom(a)quantonium.net>
commit 581e7226a5d43f629eb6399a121f85f6a15f81be upstream.
TCP sockets for IPv4 and IPv6 that are not listeners or in closed
stated are allowed to be attached to a KCM mux.
Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
Reported-by: syzbot+8865eaff7f9acd593945(a)syzkaller.appspotmail.com
Signed-off-by: Tom Herbert <tom(a)quantonium.net>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/kcm/kcmsock.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -1381,8 +1381,13 @@ static int kcm_attach(struct socket *soc
if (!csk)
return -EINVAL;
- /* We must prevent loops or risk deadlock ! */
- if (csk->sk_family == PF_KCM)
+ /* Only allow TCP sockets to be attached for now */
+ if ((csk->sk_family != AF_INET && csk->sk_family != AF_INET6) ||
+ csk->sk_protocol != IPPROTO_TCP)
+ return -EOPNOTSUPP;
+
+ /* Don't allow listeners or closed sockets */
+ if (csk->sk_state == TCP_LISTEN || csk->sk_state == TCP_CLOSE)
return -EOPNOTSUPP;
psock = kmem_cache_zalloc(kcm_psockp, GFP_KERNEL);
Patches currently in stable-queue which might be from tom(a)quantonium.net are
queue-4.9/kcm-check-if-sk_user_data-already-set-in-kcm_attach.patch
queue-4.9/kcm-only-allow-tcp-sockets-to-be-attached-to-a-kcm-mux.patch
This is a note to let you know that I've just added the patch titled
drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all
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:
drm-require-__gfp_nofail-for-the-legacy-drm_modeset_lock_all.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 d18d1a5ac811d12f7ebc1129230312b5f2c50cb8 Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Tue, 31 Oct 2017 11:55:35 +0000
Subject: drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Chris Wilson <chris(a)chris-wilson.co.uk>
commit d18d1a5ac811d12f7ebc1129230312b5f2c50cb8 upstream.
To acquire all modeset locks requires a ww_ctx to be allocated. As this
is the legacy path and the allocation small, to reduce the changes
required (and complex untested error handling) to the legacy drivers, we
simply assume that the allocation succeeds. At present, it relies on the
too-small-to-fail rule, but syzbot found that by injecting a failure
here we would hit the WARN. Document that this allocation must succeed
with __GFP_NOFAIL.
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031115535.15166-1-chris@…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_modeset_lock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -81,7 +81,7 @@ void drm_modeset_lock_all(struct drm_dev
struct drm_modeset_acquire_ctx *ctx;
int ret;
- ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL | __GFP_NOFAIL);
if (WARN_ON(!ctx))
return;
Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are
queue-4.9/drm-require-__gfp_nofail-for-the-legacy-drm_modeset_lock_all.patch
This is a note to let you know that I've just added the patch titled
cfg80211: check dev_set_name() return value
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:
cfg80211-check-dev_set_name-return-value.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 59b179b48ce2a6076448a44531242ac2b3f6cef2 Mon Sep 17 00:00:00 2001
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Mon, 15 Jan 2018 09:58:27 +0100
Subject: cfg80211: check dev_set_name() return value
From: Johannes Berg <johannes.berg(a)intel.com>
commit 59b179b48ce2a6076448a44531242ac2b3f6cef2 upstream.
syzbot reported a warning from rfkill_alloc(), and after a while
I think that the reason is that it was doing fault injection and
the dev_set_name() failed, leaving the name NULL, and we didn't
check the return value and got to rfkill_alloc() with a NULL name.
Since we really don't want a NULL name, we ought to check the
return value.
Fixes: fb28ad35906a ("net: struct device - replace bus_id with dev_name(), dev_set_name()")
Reported-by: syzbot+1ddfb3357e1d7bb5b5d3(a)syzkaller.appspotmail.com
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/wireless/core.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -421,6 +421,8 @@ struct wiphy *wiphy_new_nm(const struct
if (rv)
goto use_default_name;
} else {
+ int rv;
+
use_default_name:
/* NOTE: This is *probably* safe w/out holding rtnl because of
* the restrictions on phy names. Probably this call could
@@ -428,7 +430,11 @@ use_default_name:
* phyX. But, might should add some locking and check return
* value, and use a different name if this one exists?
*/
- dev_set_name(&rdev->wiphy.dev, PHY_NAME "%d", rdev->wiphy_idx);
+ rv = dev_set_name(&rdev->wiphy.dev, PHY_NAME "%d", rdev->wiphy_idx);
+ if (rv < 0) {
+ kfree(rdev);
+ return NULL;
+ }
}
INIT_LIST_HEAD(&rdev->wiphy.wdev_list);
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.9/cfg80211-check-dev_set_name-return-value.patch
This is a note to let you know that I've just added the patch titled
blk_rq_map_user_iov: fix error override
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:
blk_rq_map_user_iov-fix-error-override.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 69e0927b3774563c19b5fb32e91d75edc147fb62 Mon Sep 17 00:00:00 2001
From: Douglas Gilbert <dgilbert(a)interlog.com>
Date: Sun, 14 Jan 2018 17:00:48 -0500
Subject: blk_rq_map_user_iov: fix error override
From: Douglas Gilbert <dgilbert(a)interlog.com>
commit 69e0927b3774563c19b5fb32e91d75edc147fb62 upstream.
During stress tests by syzkaller on the sg driver the block layer
infrequently returns EINVAL. Closer inspection shows the block
layer was trying to return ENOMEM (which is much more
understandable) but for some reason overroad that useful error.
Patch below does not show this (unchanged) line:
ret =__blk_rq_map_user_iov(rq, map_data, &i, gfp_mask, copy);
That 'ret' was being overridden when that function failed.
Signed-off-by: Douglas Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-map.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/block/blk-map.c
+++ b/block/blk-map.c
@@ -116,7 +116,7 @@ int blk_rq_map_user_iov(struct request_q
unsigned long align = q->dma_pad_mask | queue_dma_alignment(q);
struct bio *bio = NULL;
struct iov_iter i;
- int ret;
+ int ret = -EINVAL;
if (!iter_is_iovec(iter))
goto fail;
@@ -145,7 +145,7 @@ unmap_rq:
__blk_rq_unmap_user(bio);
fail:
rq->bio = NULL;
- return -EINVAL;
+ return ret;
}
EXPORT_SYMBOL(blk_rq_map_user_iov);
Patches currently in stable-queue which might be from dgilbert(a)interlog.com are
queue-4.9/blk_rq_map_user_iov-fix-error-override.patch
Two tiny patches for the IBRS code. They should go in
through the x86/pti tree and should apply to both 4.9 and 4.14 trees.
Thanks,
Paolo
v1->v2: remove patch 2, the same bug has already been fixed
Paolo Bonzini (3):
KVM: x86: use native MSR ops for SPEC_CTRL
KVM: VMX: mark RDMSR path as unlikely
arch/x86/kvm/svm.c | 9 +++++----
arch/x86/kvm/vmx.c | 9 +++++----
2 files changed, 10 insertions(+), 8 deletions(-)
--
1.8.3.1
commit a307a1e6bc0d ("cpufreq: s3c: use cpufreq_generic_init()")
accidentally broke cpufreq on s3c2410 and s3c2412. These two platforms
don't have a CPU frequency table and used to skip calling
cpufreq_table_validate_and_show() for them. But with the above commit,
we started calling it unconditionally and that will eventually fail as
the frequency table pointer is NULL.
Fix this by calling cpufreq_table_validate_and_show() conditionally
again.
Cc: stable(a)vger.kernel.org # v3.13+
Fixes: a307a1e6bc0d ("cpufreq: s3c: use cpufreq_generic_init()")
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
drivers/cpufreq/s3c24xx-cpufreq.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/s3c24xx-cpufreq.c b/drivers/cpufreq/s3c24xx-cpufreq.c
index 7b596fa38ad2..6bebc1f9f55a 100644
--- a/drivers/cpufreq/s3c24xx-cpufreq.c
+++ b/drivers/cpufreq/s3c24xx-cpufreq.c
@@ -351,7 +351,13 @@ struct clk *s3c_cpufreq_clk_get(struct device *dev, const char *name)
static int s3c_cpufreq_init(struct cpufreq_policy *policy)
{
policy->clk = clk_arm;
- return cpufreq_generic_init(policy, ftab, cpu_cur.info->latency);
+
+ policy->cpuinfo.transition_latency = cpu_cur.info->latency;
+
+ if (ftab)
+ return cpufreq_table_validate_and_show(policy, ftab);
+
+ return 0;
}
static int __init s3c_cpufreq_initclks(void)
--
2.15.0.194.g9af6a3dea062
Hi James,
Here's a collection of fixes for Linux keyrings, mostly thanks to Eric
Biggers, if you could pass them along to Linus. They include:
(1) Fix some PKCS#7 verification issues.
(2) Fix handling of unsupported crypto in X.509.
(3) Fix too-large allocation in big_key.
The patches can be found here also:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/tag/?…
And also on the keys-fixes branch.
David
---
David Howells (1):
KEYS: Use individual pages in big_key for crypto buffers
Eric Biggers (5):
PKCS#7: fix certificate chain verification
PKCS#7: fix certificate blacklisting
PKCS#7: fix direct verification of SignerInfo signature
X.509: fix BUG_ON() when hash algorithm is unsupported
X.509: fix NULL dereference when restricting key with unsupported_sig
crypto/asymmetric_keys/pkcs7_trust.c | 1
crypto/asymmetric_keys/pkcs7_verify.c | 12 ++--
crypto/asymmetric_keys/public_key.c | 4 +
crypto/asymmetric_keys/restrict.c | 21 ++++--
security/keys/big_key.c | 110 ++++++++++++++++++++++++++-------
5 files changed, 111 insertions(+), 37 deletions(-)
This is a note to let you know that I've just added the patch titled
xfrm: skip policies marked as dead while rehashing
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:
xfrm-skip-policies-marked-as-dead-while-rehashing.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 862591bf4f519d1b8d859af720fafeaebdd0162a Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Wed, 27 Dec 2017 23:25:45 +0100
Subject: xfrm: skip policies marked as dead while rehashing
From: Florian Westphal <fw(a)strlen.de>
commit 862591bf4f519d1b8d859af720fafeaebdd0162a upstream.
syzkaller triggered following KASAN splat:
BUG: KASAN: slab-out-of-bounds in xfrm_hash_rebuild+0xdbe/0xf00 net/xfrm/xfrm_policy.c:618
read of size 2 at addr ffff8801c8e92fe4 by task kworker/1:1/23 [..]
Workqueue: events xfrm_hash_rebuild [..]
__asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:428
xfrm_hash_rebuild+0xdbe/0xf00 net/xfrm/xfrm_policy.c:618
process_one_work+0xbbf/0x1b10 kernel/workqueue.c:2112
worker_thread+0x223/0x1990 kernel/workqueue.c:2246 [..]
The reproducer triggers:
1016 if (error) {
1017 list_move_tail(&walk->walk.all, &x->all);
1018 goto out;
1019 }
in xfrm_policy_walk() via pfkey (it sets tiny rcv space, dump
callback returns -ENOBUFS).
In this case, *walk is located the pfkey socket struct, so this socket
becomes visible in the global policy list.
It looks like this is intentional -- phony walker has walk.dead set to 1
and all other places skip such "policies".
Ccing original authors of the two commits that seem to expose this
issue (first patch missed ->dead check, second patch adds pfkey
sockets to policies dumper list).
Fixes: 880a6fab8f6ba5b ("xfrm: configure policy hash table thresholds by netlink")
Fixes: 12a169e7d8f4b1c ("ipsec: Put dumpers on the dump list")
Cc: Herbert Xu <herbert(a)gondor.apana.org.au>
Cc: Timo Teras <timo.teras(a)iki.fi>
Cc: Christophe Gouault <christophe.gouault(a)6wind.com>
Reported-by: syzbot <bot+c028095236fcb6f4348811565b75084c754dc729(a)syzkaller.appspotmail.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_policy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -610,7 +610,8 @@ static void xfrm_hash_rebuild(struct wor
/* re-insert all policies by order of creation */
list_for_each_entry_reverse(policy, &net->xfrm.policy_all, walk.all) {
- if (xfrm_policy_id2dir(policy->index) >= XFRM_POLICY_MAX) {
+ if (policy->walk.dead ||
+ xfrm_policy_id2dir(policy->index) >= XFRM_POLICY_MAX) {
/* skip socket policies */
continue;
}
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.14/xfrm-skip-policies-marked-as-dead-while-rehashing.patch
queue-4.14/netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch
queue-4.14/netfilter-on-sockopt-acquire-sock-lock-only-in-the-required-scope.patch
queue-4.14/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
queue-4.14/xfrm-don-t-call-xfrm_policy_cache_flush-while-holding-spinlock.patch
This is a note to let you know that I've just added the patch titled
xfrm: fix rcu usage in xfrm_get_type_offload
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:
xfrm-fix-rcu-usage-in-xfrm_get_type_offload.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 2f10a61cee8fdb9f8da90f5db687e1862b22cf06 Mon Sep 17 00:00:00 2001
From: Sabrina Dubroca <sd(a)queasysnail.net>
Date: Sun, 31 Dec 2017 16:18:56 +0100
Subject: xfrm: fix rcu usage in xfrm_get_type_offload
From: Sabrina Dubroca <sd(a)queasysnail.net>
commit 2f10a61cee8fdb9f8da90f5db687e1862b22cf06 upstream.
request_module can sleep, thus we cannot hold rcu_read_lock() while
calling it. The function also jumps back and takes rcu_read_lock()
again (in xfrm_state_get_afinfo()), resulting in an imbalance.
This codepath is triggered whenever a new offloaded state is created.
Fixes: ffdb5211da1c ("xfrm: Auto-load xfrm offload modules")
Reported-by: syzbot+ca425f44816d749e8eb49755567a75ee48cf4a30(a)syzkaller.appspotmail.com
Signed-off-by: Sabrina Dubroca <sd(a)queasysnail.net>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_state.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -313,13 +313,14 @@ retry:
if ((type && !try_module_get(type->owner)))
type = NULL;
+ rcu_read_unlock();
+
if (!type && try_load) {
request_module("xfrm-offload-%d-%d", family, proto);
try_load = 0;
goto retry;
}
- rcu_read_unlock();
return type;
}
Patches currently in stable-queue which might be from sd(a)queasysnail.net are
queue-4.14/xfrm-fix-rcu-usage-in-xfrm_get_type_offload.patch
This is a note to let you know that I've just added the patch titled
xfrm: Fix stack-out-of-bounds read on socket policy lookup.
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:
xfrm-fix-stack-out-of-bounds-read-on-socket-policy-lookup.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 ddc47e4404b58f03e98345398fb12d38fe291512 Mon Sep 17 00:00:00 2001
From: Steffen Klassert <steffen.klassert(a)secunet.com>
Date: Wed, 29 Nov 2017 06:53:55 +0100
Subject: xfrm: Fix stack-out-of-bounds read on socket policy lookup.
From: Steffen Klassert <steffen.klassert(a)secunet.com>
commit ddc47e4404b58f03e98345398fb12d38fe291512 upstream.
When we do tunnel or beet mode, we pass saddr and daddr from the
template to xfrm_state_find(), this is ok. On transport mode,
we pass the addresses from the flowi, assuming that the IP
addresses (and address family) don't change during transformation.
This assumption is wrong in the IPv4 mapped IPv6 case, packet
is IPv4 and template is IPv6.
Fix this by catching address family missmatches of the policy
and the flow already before we do the lookup.
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_policy.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1168,9 +1168,15 @@ static struct xfrm_policy *xfrm_sk_polic
again:
pol = rcu_dereference(sk->sk_policy[dir]);
if (pol != NULL) {
- bool match = xfrm_selector_match(&pol->selector, fl, family);
+ bool match;
int err = 0;
+ if (pol->family != family) {
+ pol = NULL;
+ goto out;
+ }
+
+ match = xfrm_selector_match(&pol->selector, fl, family);
if (match) {
if ((sk->sk_mark & pol->mark.m) != pol->mark.v) {
pol = NULL;
Patches currently in stable-queue which might be from steffen.klassert(a)secunet.com are
queue-4.14/xfrm-fix-stack-out-of-bounds-read-on-socket-policy-lookup.patch
queue-4.14/xfrm-skip-policies-marked-as-dead-while-rehashing.patch
queue-4.14/xfrm-fix-rcu-usage-in-xfrm_get_type_offload.patch
queue-4.14/esp-fix-gro-when-the-headers-not-fully-in-the-linear-part-of-the-skb.patch
queue-4.14/xfrm-don-t-call-xfrm_policy_cache_flush-while-holding-spinlock.patch
queue-4.14/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
xfrm: check id proto in validate_tmpl()
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:
xfrm-check-id-proto-in-validate_tmpl.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 6a53b7593233ab9e4f96873ebacc0f653a55c3e1 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Mon, 27 Nov 2017 11:15:16 -0800
Subject: xfrm: check id proto in validate_tmpl()
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit 6a53b7593233ab9e4f96873ebacc0f653a55c3e1 upstream.
syzbot reported a kernel warning in xfrm_state_fini(), which
indicates that we have entries left in the list
net->xfrm.state_all whose proto is zero. And
xfrm_id_proto_match() doesn't consider them as a match with
IPSEC_PROTO_ANY in this case.
Proto with value 0 is probably not a valid value, at least
verify_newsa_info() doesn't consider it valid either.
This patch fixes it by checking the proto value in
validate_tmpl() and rejecting invalid ones, like what iproute2
does in xfrm_xfrmproto_getbyname().
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Cc: Steffen Klassert <steffen.klassert(a)secunet.com>
Cc: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_user.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1443,6 +1443,21 @@ static int validate_tmpl(int nr, struct
default:
return -EINVAL;
}
+
+ switch (ut[i].id.proto) {
+ case IPPROTO_AH:
+ case IPPROTO_ESP:
+ case IPPROTO_COMP:
+#if IS_ENABLED(CONFIG_IPV6)
+ case IPPROTO_ROUTING:
+ case IPPROTO_DSTOPTS:
+#endif
+ case IPSEC_PROTO_ANY:
+ break;
+ default:
+ return -EINVAL;
+ }
+
}
return 0;
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.14/net_sched-gen_estimator-fix-lockdep-splat.patch
queue-4.14/netfilter-xt_cgroup-initialize-info-priv-in-cgroup_mt_check_v1.patch
queue-4.14/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
queue-4.14/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
xfrm: don't call xfrm_policy_cache_flush while holding spinlock
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:
xfrm-don-t-call-xfrm_policy_cache_flush-while-holding-spinlock.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 b1bdcb59b64f806ef08d25a85c39ffb3ad841ce6 Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Sat, 6 Jan 2018 01:13:08 +0100
Subject: xfrm: don't call xfrm_policy_cache_flush while holding spinlock
From: Florian Westphal <fw(a)strlen.de>
commit b1bdcb59b64f806ef08d25a85c39ffb3ad841ce6 upstream.
xfrm_policy_cache_flush can sleep, so it cannot be called while holding
a spinlock. We could release the lock first, but I don't see why we need
to invoke this function here in first place, the packet path won't reuse
an xdst entry unless its still valid.
While at it, add an annotation to xfrm_policy_cache_flush, it would
have probably caught this bug sooner.
Fixes: ec30d78c14a813 ("xfrm: add xdst pcpu cache")
Reported-by: syzbot+e149f7d1328c26f9c12f(a)syzkaller.appspotmail.com
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_policy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -975,8 +975,6 @@ int xfrm_policy_flush(struct net *net, u
}
if (!cnt)
err = -ESRCH;
- else
- xfrm_policy_cache_flush();
out:
spin_unlock_bh(&net->xfrm.xfrm_policy_lock);
return err;
@@ -1738,6 +1736,8 @@ void xfrm_policy_cache_flush(void)
bool found = 0;
int cpu;
+ might_sleep();
+
local_bh_disable();
rcu_read_lock();
for_each_possible_cpu(cpu) {
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.14/xfrm-skip-policies-marked-as-dead-while-rehashing.patch
queue-4.14/netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch
queue-4.14/netfilter-on-sockopt-acquire-sock-lock-only-in-the-required-scope.patch
queue-4.14/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
queue-4.14/xfrm-don-t-call-xfrm_policy_cache_flush-while-holding-spinlock.patch
This is a note to let you know that I've just added the patch titled
usb: core: Add a helper function to check the validity of EP type in URB
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-add-a-helper-function-to-check-the-validity-of-ep-type-in-urb.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 e901b9873876ca30a09253731bd3a6b00c44b5b0 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Wed, 4 Oct 2017 16:15:59 +0200
Subject: usb: core: Add a helper function to check the validity of EP type in URB
From: Takashi Iwai <tiwai(a)suse.de>
commit e901b9873876ca30a09253731bd3a6b00c44b5b0 upstream.
This patch adds a new helper function to perform a sanity check of the
given URB to see whether it contains a valid endpoint. It's a light-
weight version of what usb_submit_urb() does, but without the kernel
warning followed by the stack trace, just returns an error code.
Especially for a driver that doesn't parse the descriptor but fills
the URB with the fixed endpoint (e.g. some quirks for non-compliant
devices), this kind of check is preferable at the probe phase before
actually submitting the urb.
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/urb.c | 30 ++++++++++++++++++++++++++----
include/linux/usb.h | 2 ++
2 files changed, 28 insertions(+), 4 deletions(-)
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -187,6 +187,31 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb);
/*-------------------------------------------------------------------*/
+static const int pipetypes[4] = {
+ PIPE_CONTROL, PIPE_ISOCHRONOUS, PIPE_BULK, PIPE_INTERRUPT
+};
+
+/**
+ * usb_urb_ep_type_check - sanity check of endpoint in the given urb
+ * @urb: urb to be checked
+ *
+ * This performs a light-weight sanity check for the endpoint in the
+ * given urb. It returns 0 if the urb contains a valid endpoint, otherwise
+ * a negative error code.
+ */
+int usb_urb_ep_type_check(const struct urb *urb)
+{
+ const struct usb_host_endpoint *ep;
+
+ ep = usb_pipe_endpoint(urb->dev, urb->pipe);
+ if (!ep)
+ return -EINVAL;
+ if (usb_pipetype(urb->pipe) != pipetypes[usb_endpoint_type(&ep->desc)])
+ return -EINVAL;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_urb_ep_type_check);
+
/**
* usb_submit_urb - issue an asynchronous transfer request for an endpoint
* @urb: pointer to the urb describing the request
@@ -326,9 +351,6 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb);
*/
int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
{
- static int pipetypes[4] = {
- PIPE_CONTROL, PIPE_ISOCHRONOUS, PIPE_BULK, PIPE_INTERRUPT
- };
int xfertype, max;
struct usb_device *dev;
struct usb_host_endpoint *ep;
@@ -444,7 +466,7 @@ int usb_submit_urb(struct urb *urb, gfp_
*/
/* Check that the pipe's type matches the endpoint's type */
- if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
+ if (usb_urb_ep_type_check(urb))
dev_WARN(&dev->dev, "BOGUS urb xfer, pipe %x != type %x\n",
usb_pipetype(urb->pipe), pipetypes[xfertype]);
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -1729,6 +1729,8 @@ static inline int usb_urb_dir_out(struct
return (urb->transfer_flags & URB_DIR_MASK) == URB_DIR_OUT;
}
+int usb_urb_ep_type_check(const struct urb *urb);
+
void *usb_alloc_coherent(struct usb_device *dev, size_t size,
gfp_t mem_flags, dma_addr_t *dma);
void usb_free_coherent(struct usb_device *dev, size_t size,
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.14/alsa-bcd2000-add-a-sanity-check-for-invalid-eps.patch
queue-4.14/alsa-caiaq-add-a-sanity-check-for-invalid-eps.patch
queue-4.14/alsa-line6-add-a-sanity-check-for-invalid-eps.patch
queue-4.14/usb-core-add-a-helper-function-to-check-the-validity-of-ep-type-in-urb.patch
This is a note to let you know that I've just added the patch titled
vhost: use mutex_lock_nested() in vhost_dev_lock_vqs()
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:
vhost-use-mutex_lock_nested-in-vhost_dev_lock_vqs.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 e9cb4239134c860e5f92c75bf5321bd377bb505b Mon Sep 17 00:00:00 2001
From: Jason Wang <jasowang(a)redhat.com>
Date: Tue, 23 Jan 2018 17:27:25 +0800
Subject: vhost: use mutex_lock_nested() in vhost_dev_lock_vqs()
From: Jason Wang <jasowang(a)redhat.com>
commit e9cb4239134c860e5f92c75bf5321bd377bb505b upstream.
We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to
hold mutexes of all virtqueues. This may confuse lockdep to report a
possible deadlock because of trying to hold locks belong to same
class. Switch to use mutex_lock_nested() to avoid false positive.
Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API")
Reported-by: syzbot+dbb7c1161485e61b0241(a)syzkaller.appspotmail.com
Signed-off-by: Jason Wang <jasowang(a)redhat.com>
Acked-by: Michael S. Tsirkin <mst(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -904,7 +904,7 @@ static void vhost_dev_lock_vqs(struct vh
{
int i = 0;
for (i = 0; i < d->nvqs; ++i)
- mutex_lock(&d->vqs[i]->mutex);
+ mutex_lock_nested(&d->vqs[i]->mutex, i);
}
static void vhost_dev_unlock_vqs(struct vhost_dev *d)
Patches currently in stable-queue which might be from jasowang(a)redhat.com are
queue-4.14/ptr_ring-try-vmalloc-when-kmalloc-fails.patch
queue-4.14/vhost-use-mutex_lock_nested-in-vhost_dev_lock_vqs.patch
queue-4.14/ptr_ring-fail-early-if-queue-occupies-more-than-kmalloc_max_size.patch
This is a note to let you know that I've just added the patch titled
staging: android: ion: Switch from WARN to pr_warn
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:
staging-android-ion-switch-from-warn-to-pr_warn.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 e4e179a844f52e907e550f887d0a2171f1508af1 Mon Sep 17 00:00:00 2001
From: Laura Abbott <labbott(a)redhat.com>
Date: Fri, 5 Jan 2018 11:14:09 -0800
Subject: staging: android: ion: Switch from WARN to pr_warn
From: Laura Abbott <labbott(a)redhat.com>
commit e4e179a844f52e907e550f887d0a2171f1508af1 upstream.
Syzbot reported a warning with Ion:
WARNING: CPU: 0 PID: 3502 at drivers/staging/android/ion/ion-ioctl.c:73 ion_ioctl+0x2db/0x380 drivers/staging/android/ion/ion-ioctl.c:73
Kernel panic - not syncing: panic_on_warn set ...
This is a warning that validation of the ioctl fields failed. This was
deliberately added as a warning to make it very obvious to developers that
something needed to be fixed. In reality, this is overkill and disturbs
fuzzing. Switch to pr_warn for a message instead.
Reported-by: syzbot+fa2d5f63ee5904a0115a(a)syzkaller.appspotmail.com
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Laura Abbott <labbott(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ion/ion-ioctl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -71,8 +71,10 @@ long ion_ioctl(struct file *filp, unsign
return -EFAULT;
ret = validate_ioctl_arg(cmd, &data);
- if (WARN_ON_ONCE(ret))
+ if (ret) {
+ pr_warn_once("%s: ioctl validate failed\n", __func__);
return ret;
+ }
if (!(dir & _IOC_WRITE))
memset(&data, 0, sizeof(data));
Patches currently in stable-queue which might be from labbott(a)redhat.com are
queue-4.14/staging-android-ion-switch-from-warn-to-pr_warn.patch
queue-4.14/staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.patch
This is a note to let you know that I've just added the patch titled
staging: android: ion: Add __GFP_NOWARN for system contig heap
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:
staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.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 0c75f10312a35b149b2cebb1832316b35c2337ca Mon Sep 17 00:00:00 2001
From: Laura Abbott <labbott(a)redhat.com>
Date: Fri, 5 Jan 2018 11:14:08 -0800
Subject: staging: android: ion: Add __GFP_NOWARN for system contig heap
From: Laura Abbott <labbott(a)redhat.com>
commit 0c75f10312a35b149b2cebb1832316b35c2337ca upstream.
syzbot reported a warning from Ion:
WARNING: CPU: 1 PID: 3485 at mm/page_alloc.c:3926
...
__alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252
alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036
alloc_pages include/linux/gfp.h:492 [inline]
ion_system_contig_heap_allocate+0x40/0x2c0
drivers/staging/android/ion/ion_system_heap.c:374
ion_buffer_create drivers/staging/android/ion/ion.c:93 [inline]
ion_alloc+0x2c1/0x9e0 drivers/staging/android/ion/ion.c:420
ion_ioctl+0x26d/0x380 drivers/staging/android/ion/ion-ioctl.c:84
vfs_ioctl fs/ioctl.c:46 [inline]
do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
SYSC_ioctl fs/ioctl.c:701 [inline]
SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
This is a warning about attempting to allocate order > MAX_ORDER. This
is coming from a userspace Ion allocation request. Since userspace is
free to request however much memory it wants (and the kernel is free to
deny its allocation), silence the allocation attempt with __GFP_NOWARN
in case it fails.
Reported-by: syzbot+76e7efc4748495855a4d(a)syzkaller.appspotmail.com
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Laura Abbott <labbott(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ion/ion_system_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -371,7 +371,7 @@ static int ion_system_contig_heap_alloca
unsigned long i;
int ret;
- page = alloc_pages(low_order_gfp_flags, order);
+ page = alloc_pages(low_order_gfp_flags | __GFP_NOWARN, order);
if (!page)
return -ENOMEM;
Patches currently in stable-queue which might be from labbott(a)redhat.com are
queue-4.14/staging-android-ion-switch-from-warn-to-pr_warn.patch
queue-4.14/staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.patch
This is a note to let you know that I've just added the patch titled
selinux: skip bounded transition processing if the policy isn't loaded
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:
selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.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 4b14752ec4e0d87126e636384cf37c8dd9df157c Mon Sep 17 00:00:00 2001
From: Paul Moore <paul(a)paul-moore.com>
Date: Tue, 5 Dec 2017 17:17:43 -0500
Subject: selinux: skip bounded transition processing if the policy isn't loaded
From: Paul Moore <paul(a)paul-moore.com>
commit 4b14752ec4e0d87126e636384cf37c8dd9df157c upstream.
We can't do anything reasonable in security_bounded_transition() if we
don't have a policy loaded, and in fact we could run into problems
with some of the code inside expecting a policy. Fix these problems
like we do many others in security/selinux/ss/services.c by checking
to see if the policy is loaded (ss_initialized) and returning quickly
if it isn't.
Reported-by: syzbot <syzkaller-bugs(a)googlegroups.com>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Acked-by: Stephen Smalley <sds(a)tycho.nsa.gov>
Reviewed-by: James Morris <james.l.morris(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/selinux/ss/services.c | 3 +++
1 file changed, 3 insertions(+)
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -867,6 +867,9 @@ int security_bounded_transition(u32 old_
int index;
int rc;
+ if (!ss_initialized)
+ return 0;
+
read_lock(&policy_rwlock);
rc = -EINVAL;
Patches currently in stable-queue which might be from paul(a)paul-moore.com are
queue-4.14/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch
queue-4.14/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch
This is a note to let you know that I've just added the patch titled
sctp: set frag_point in sctp_setsockopt_maxseg correctly
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:
sctp-set-frag_point-in-sctp_setsockopt_maxseg-correctly.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 ecca8f88da5c4260cc2bccfefd2a24976704c366 Mon Sep 17 00:00:00 2001
From: Xin Long <lucien.xin(a)gmail.com>
Date: Fri, 17 Nov 2017 14:11:11 +0800
Subject: sctp: set frag_point in sctp_setsockopt_maxseg correctly
From: Xin Long <lucien.xin(a)gmail.com>
commit ecca8f88da5c4260cc2bccfefd2a24976704c366 upstream.
Now in sctp_setsockopt_maxseg user_frag or frag_point can be set with
val >= 8 and val <= SCTP_MAX_CHUNK_LEN. But both checks are incorrect.
val >= 8 means frag_point can even be less than SCTP_DEFAULT_MINSEGMENT.
Then in sctp_datamsg_from_user(), when it's value is greater than cookie
echo len and trying to bundle with cookie echo chunk, the first_len will
overflow.
The worse case is when it's value is equal as cookie echo len, first_len
becomes 0, it will go into a dead loop for fragment later on. In Hangbin
syzkaller testing env, oom was even triggered due to consecutive memory
allocation in that loop.
Besides, SCTP_MAX_CHUNK_LEN is the max size of the whole chunk, it should
deduct the data header for frag_point or user_frag check.
This patch does a proper check with SCTP_DEFAULT_MINSEGMENT subtracting
the sctphdr and datahdr, SCTP_MAX_CHUNK_LEN subtracting datahdr when
setting frag_point via sockopt. It also improves sctp_setsockopt_maxseg
codes.
Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Reported-by: Hangbin Liu <liuhangbin(a)gmail.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/net/sctp/sctp.h | 3 ++-
net/sctp/socket.c | 29 +++++++++++++++++++----------
2 files changed, 21 insertions(+), 11 deletions(-)
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -444,7 +444,8 @@ static inline int sctp_frag_point(const
if (asoc->user_frag)
frag = min_t(int, frag, asoc->user_frag);
- frag = SCTP_TRUNC4(min_t(int, frag, SCTP_MAX_CHUNK_LEN));
+ frag = SCTP_TRUNC4(min_t(int, frag, SCTP_MAX_CHUNK_LEN -
+ sizeof(struct sctp_data_chunk)));
return frag;
}
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -3136,9 +3136,9 @@ static int sctp_setsockopt_mappedv4(stru
*/
static int sctp_setsockopt_maxseg(struct sock *sk, char __user *optval, unsigned int optlen)
{
+ struct sctp_sock *sp = sctp_sk(sk);
struct sctp_assoc_value params;
struct sctp_association *asoc;
- struct sctp_sock *sp = sctp_sk(sk);
int val;
if (optlen == sizeof(int)) {
@@ -3154,26 +3154,35 @@ static int sctp_setsockopt_maxseg(struct
if (copy_from_user(¶ms, optval, optlen))
return -EFAULT;
val = params.assoc_value;
- } else
+ } else {
return -EINVAL;
+ }
- if ((val != 0) && ((val < 8) || (val > SCTP_MAX_CHUNK_LEN)))
- return -EINVAL;
+ if (val) {
+ int min_len, max_len;
- asoc = sctp_id2assoc(sk, params.assoc_id);
- if (!asoc && params.assoc_id && sctp_style(sk, UDP))
- return -EINVAL;
+ min_len = SCTP_DEFAULT_MINSEGMENT - sp->pf->af->net_header_len;
+ min_len -= sizeof(struct sctphdr) +
+ sizeof(struct sctp_data_chunk);
+
+ max_len = SCTP_MAX_CHUNK_LEN - sizeof(struct sctp_data_chunk);
+ if (val < min_len || val > max_len)
+ return -EINVAL;
+ }
+
+ asoc = sctp_id2assoc(sk, params.assoc_id);
if (asoc) {
if (val == 0) {
- val = asoc->pathmtu;
- val -= sp->pf->af->net_header_len;
+ val = asoc->pathmtu - sp->pf->af->net_header_len;
val -= sizeof(struct sctphdr) +
- sizeof(struct sctp_data_chunk);
+ sizeof(struct sctp_data_chunk);
}
asoc->user_frag = val;
asoc->frag_point = sctp_frag_point(asoc, asoc->pathmtu);
} else {
+ if (params.assoc_id && sctp_style(sk, UDP))
+ return -EINVAL;
sp->user_frag = val;
}
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.14/sctp-set-frag_point-in-sctp_setsockopt_maxseg-correctly.patch
This is a note to let you know that I've just added the patch titled
selinux: ensure the context is NUL terminated in security_context_to_sid_core()
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:
selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.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 ef28df55ac27e1e5cd122e19fa311d886d47a756 Mon Sep 17 00:00:00 2001
From: Paul Moore <paul(a)paul-moore.com>
Date: Tue, 28 Nov 2017 18:51:12 -0500
Subject: selinux: ensure the context is NUL terminated in security_context_to_sid_core()
From: Paul Moore <paul(a)paul-moore.com>
commit ef28df55ac27e1e5cd122e19fa311d886d47a756 upstream.
The syzbot/syzkaller automated tests found a problem in
security_context_to_sid_core() during early boot (before we load the
SELinux policy) where we could potentially feed context strings without
NUL terminators into the strcmp() function.
We already guard against this during normal operation (after the SELinux
policy has been loaded) by making a copy of the context strings and
explicitly adding a NUL terminator to the end. The patch extends this
protection to the early boot case (no loaded policy) by moving the context
copy earlier in security_context_to_sid_core().
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Reviewed-By: William Roberts <william.c.roberts(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/selinux/ss/services.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -1413,27 +1413,25 @@ static int security_context_to_sid_core(
if (!scontext_len)
return -EINVAL;
+ /* Copy the string to allow changes and ensure a NUL terminator */
+ scontext2 = kmemdup_nul(scontext, scontext_len, gfp_flags);
+ if (!scontext2)
+ return -ENOMEM;
+
if (!ss_initialized) {
int i;
for (i = 1; i < SECINITSID_NUM; i++) {
- if (!strcmp(initial_sid_to_string[i], scontext)) {
+ if (!strcmp(initial_sid_to_string[i], scontext2)) {
*sid = i;
- return 0;
+ goto out;
}
}
*sid = SECINITSID_KERNEL;
- return 0;
+ goto out;
}
*sid = SECSID_NULL;
- /* Copy the string so that we can modify the copy as we parse it. */
- scontext2 = kmalloc(scontext_len + 1, gfp_flags);
- if (!scontext2)
- return -ENOMEM;
- memcpy(scontext2, scontext, scontext_len);
- scontext2[scontext_len] = 0;
-
if (force) {
/* Save another copy for storing in uninterpreted form */
rc = -ENOMEM;
Patches currently in stable-queue which might be from paul(a)paul-moore.com are
queue-4.14/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch
queue-4.14/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch
This is a note to let you know that I've just added the patch titled
rds: tcp: correctly sequence cleanup on netns deletion.
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:
rds-tcp-correctly-sequence-cleanup-on-netns-deletion.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 681648e67d43cf269c5590ecf021ed481f4551fc Mon Sep 17 00:00:00 2001
From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
Date: Thu, 30 Nov 2017 11:11:28 -0800
Subject: rds: tcp: correctly sequence cleanup on netns deletion.
From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
commit 681648e67d43cf269c5590ecf021ed481f4551fc upstream.
Commit 8edc3affc077 ("rds: tcp: Take explicit refcounts on struct net")
introduces a regression in rds-tcp netns cleanup. The cleanup_net(),
(and thus rds_tcp_dev_event notification) is only called from put_net()
when all netns refcounts go to 0, but this cannot happen if the
rds_connection itself is holding a c_net ref that it expects to
release in rds_tcp_kill_sock.
Instead, the rds_tcp_kill_sock callback should make sure to
tear down state carefully, ensuring that the socket teardown
is only done after all data-structures and workqs that depend
on it are quiesced.
The original motivation for commit 8edc3affc077 ("rds: tcp: Take explicit
refcounts on struct net") was to resolve a race condition reported by
syzkaller where workqs for tx/rx/connect were triggered after the
namespace was deleted. Those worker threads should have been
cancelled/flushed before socket tear-down and indeed,
rds_conn_path_destroy() does try to sequence this by doing
/* cancel cp_send_w */
/* cancel cp_recv_w */
/* flush cp_down_w */
/* free data structures */
Here the "flush cp_down_w" will trigger rds_conn_shutdown and thus
invoke rds_tcp_conn_path_shutdown() to close the tcp socket, so that
we ought to have satisfied the requirement that "socket-close is
done after all other dependent state is quiesced". However,
rds_conn_shutdown has a bug in that it *always* triggers the reconnect
workq (and if connection is successful, we always restart tx/rx
workqs so with the right timing, we risk the race conditions reported
by syzkaller).
Netns deletion is like module teardown- no need to restart a
reconnect in this case. We can use the c_destroy_in_prog bit
to avoid restarting the reconnect.
Fixes: 8edc3affc077 ("rds: tcp: Take explicit refcounts on struct net")
Signed-off-by: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/rds/connection.c | 3 ++-
net/rds/rds.h | 6 +++---
net/rds/tcp.c | 4 ++--
3 files changed, 7 insertions(+), 6 deletions(-)
--- a/net/rds/connection.c
+++ b/net/rds/connection.c
@@ -366,6 +366,8 @@ void rds_conn_shutdown(struct rds_conn_p
* to the conn hash, so we never trigger a reconnect on this
* conn - the reconnect is always triggered by the active peer. */
cancel_delayed_work_sync(&cp->cp_conn_w);
+ if (conn->c_destroy_in_prog)
+ return;
rcu_read_lock();
if (!hlist_unhashed(&conn->c_hash_node)) {
rcu_read_unlock();
@@ -445,7 +447,6 @@ void rds_conn_destroy(struct rds_connect
*/
rds_cong_remove_conn(conn);
- put_net(conn->c_net);
kfree(conn->c_path);
kmem_cache_free(rds_conn_slab, conn);
--- a/net/rds/rds.h
+++ b/net/rds/rds.h
@@ -150,7 +150,7 @@ struct rds_connection {
/* Protocol version */
unsigned int c_version;
- struct net *c_net;
+ possible_net_t c_net;
struct list_head c_map_item;
unsigned long c_map_queued;
@@ -165,13 +165,13 @@ struct rds_connection {
static inline
struct net *rds_conn_net(struct rds_connection *conn)
{
- return conn->c_net;
+ return read_pnet(&conn->c_net);
}
static inline
void rds_conn_net_set(struct rds_connection *conn, struct net *net)
{
- conn->c_net = get_net(net);
+ write_pnet(&conn->c_net, net);
}
#define RDS_FLAG_CONG_BITMAP 0x01
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -527,7 +527,7 @@ static void rds_tcp_kill_sock(struct net
rds_tcp_listen_stop(lsock, &rtn->rds_tcp_accept_w);
spin_lock_irq(&rds_tcp_conn_lock);
list_for_each_entry_safe(tc, _tc, &rds_tcp_conn_list, t_tcp_node) {
- struct net *c_net = tc->t_cpath->cp_conn->c_net;
+ struct net *c_net = read_pnet(&tc->t_cpath->cp_conn->c_net);
if (net != c_net || !tc->t_sock)
continue;
@@ -586,7 +586,7 @@ static void rds_tcp_sysctl_reset(struct
spin_lock_irq(&rds_tcp_conn_lock);
list_for_each_entry_safe(tc, _tc, &rds_tcp_conn_list, t_tcp_node) {
- struct net *c_net = tc->t_cpath->cp_conn->c_net;
+ struct net *c_net = read_pnet(&tc->t_cpath->cp_conn->c_net);
if (net != c_net || !tc->t_sock)
continue;
Patches currently in stable-queue which might be from sowmini.varadhan(a)oracle.com are
queue-4.14/rds-tcp-atomically-purge-entries-from-rds_tcp_conn_list-during-netns-delete.patch
queue-4.14/rds-tcp-correctly-sequence-cleanup-on-netns-deletion.patch
This is a note to let you know that I've just added the patch titled
rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete
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:
rds-tcp-atomically-purge-entries-from-rds_tcp_conn_list-during-netns-delete.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 f10b4cff98c6977668434fbf5dd58695eeca2897 Mon Sep 17 00:00:00 2001
From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
Date: Thu, 30 Nov 2017 11:11:29 -0800
Subject: rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete
From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
commit f10b4cff98c6977668434fbf5dd58695eeca2897 upstream.
The rds_tcp_kill_sock() function parses the rds_tcp_conn_list
to find the rds_connection entries marked for deletion as part
of the netns deletion under the protection of the rds_tcp_conn_lock.
Since the rds_tcp_conn_list tracks rds_tcp_connections (which
have a 1:1 mapping with rds_conn_path), multiple tc entries in
the rds_tcp_conn_list will map to a single rds_connection, and will
be deleted as part of the rds_conn_destroy() operation that is
done outside the rds_tcp_conn_lock.
The rds_tcp_conn_list traversal done under the protection of
rds_tcp_conn_lock should not leave any doomed tc entries in
the list after the rds_tcp_conn_lock is released, else another
concurrently executiong netns delete (for a differnt netns) thread
may trip on these entries.
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/rds/tcp.c | 9 +++++++--
net/rds/tcp.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -306,7 +306,8 @@ static void rds_tcp_conn_free(void *arg)
rdsdebug("freeing tc %p\n", tc);
spin_lock_irqsave(&rds_tcp_conn_lock, flags);
- list_del(&tc->t_tcp_node);
+ if (!tc->t_tcp_node_detached)
+ list_del(&tc->t_tcp_node);
spin_unlock_irqrestore(&rds_tcp_conn_lock, flags);
kmem_cache_free(rds_tcp_conn_slab, tc);
@@ -531,8 +532,12 @@ static void rds_tcp_kill_sock(struct net
if (net != c_net || !tc->t_sock)
continue;
- if (!list_has_conn(&tmp_list, tc->t_cpath->cp_conn))
+ if (!list_has_conn(&tmp_list, tc->t_cpath->cp_conn)) {
list_move_tail(&tc->t_tcp_node, &tmp_list);
+ } else {
+ list_del(&tc->t_tcp_node);
+ tc->t_tcp_node_detached = true;
+ }
}
spin_unlock_irq(&rds_tcp_conn_lock);
list_for_each_entry_safe(tc, _tc, &tmp_list, t_tcp_node) {
--- a/net/rds/tcp.h
+++ b/net/rds/tcp.h
@@ -12,6 +12,7 @@ struct rds_tcp_incoming {
struct rds_tcp_connection {
struct list_head t_tcp_node;
+ bool t_tcp_node_detached;
struct rds_conn_path *t_cpath;
/* t_conn_path_lock synchronizes the connection establishment between
* rds_tcp_accept_one and rds_tcp_conn_path_connect
Patches currently in stable-queue which might be from sowmini.varadhan(a)oracle.com are
queue-4.14/rds-tcp-atomically-purge-entries-from-rds_tcp_conn_list-during-netns-delete.patch
queue-4.14/rds-tcp-correctly-sequence-cleanup-on-netns-deletion.patch
This is a note to let you know that I've just added the patch titled
ptr_ring: try vmalloc() when kmalloc() fails
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:
ptr_ring-try-vmalloc-when-kmalloc-fails.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 0bf7800f1799b5b1fd7d4f024e9ece53ac489011 Mon Sep 17 00:00:00 2001
From: Jason Wang <jasowang(a)redhat.com>
Date: Fri, 9 Feb 2018 17:45:50 +0800
Subject: ptr_ring: try vmalloc() when kmalloc() fails
From: Jason Wang <jasowang(a)redhat.com>
commit 0bf7800f1799b5b1fd7d4f024e9ece53ac489011 upstream.
This patch switch to use kvmalloc_array() for using a vmalloc()
fallback to help in case kmalloc() fails.
Reported-by: syzbot+e4d4f9ddd4295539735d(a)syzkaller.appspotmail.com
Fixes: 2e0ab8ca83c12 ("ptr_ring: array based FIFO for pointers")
Signed-off-by: Jason Wang <jasowang(a)redhat.com>
Acked-by: Michael S. Tsirkin <mst(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/ptr_ring.h | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -445,11 +445,14 @@ static inline int ptr_ring_consume_batch
__PTR_RING_PEEK_CALL_v; \
})
+/* Not all gfp_t flags (besides GFP_KERNEL) are allowed. See
+ * documentation for vmalloc for which of them are legal.
+ */
static inline void **__ptr_ring_init_queue_alloc(unsigned int size, gfp_t gfp)
{
if (size * sizeof(void *) > KMALLOC_MAX_SIZE)
return NULL;
- return kcalloc(size, sizeof(void *), gfp);
+ return kvmalloc_array(size, sizeof(void *), gfp | __GFP_ZERO);
}
static inline void __ptr_ring_set_size(struct ptr_ring *r, int size)
@@ -582,7 +585,7 @@ static inline int ptr_ring_resize(struct
spin_unlock(&(r)->producer_lock);
spin_unlock_irqrestore(&(r)->consumer_lock, flags);
- kfree(old);
+ kvfree(old);
return 0;
}
@@ -622,7 +625,7 @@ static inline int ptr_ring_resize_multip
}
for (i = 0; i < nrings; ++i)
- kfree(queues[i]);
+ kvfree(queues[i]);
kfree(queues);
@@ -630,7 +633,7 @@ static inline int ptr_ring_resize_multip
nomem:
while (--i >= 0)
- kfree(queues[i]);
+ kvfree(queues[i]);
kfree(queues);
@@ -645,7 +648,7 @@ static inline void ptr_ring_cleanup(stru
if (destroy)
while ((ptr = ptr_ring_consume(r)))
destroy(ptr);
- kfree(r->queue);
+ kvfree(r->queue);
}
#endif /* _LINUX_PTR_RING_H */
Patches currently in stable-queue which might be from jasowang(a)redhat.com are
queue-4.14/ptr_ring-try-vmalloc-when-kmalloc-fails.patch
queue-4.14/vhost-use-mutex_lock_nested-in-vhost_dev_lock_vqs.patch
queue-4.14/ptr_ring-fail-early-if-queue-occupies-more-than-kmalloc_max_size.patch
This is a note to let you know that I've just added the patch titled
netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
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:
netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.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 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Mon, 5 Feb 2018 14:41:45 -0800
Subject: netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 upstream.
rateest_hash is supposed to be protected by xt_rateest_mutex,
and, as suggested by Eric, lookup and insert should be atomic,
so we should acquire the xt_rateest_mutex once for both.
So introduce a non-locking helper for internal use and keep the
locking one for external.
Reported-by: <syzbot+5cb189720978275e4c75(a)syzkaller.appspotmail.com>
Fixes: 5859034d7eb8 ("[NETFILTER]: x_tables: add RATEEST target")
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Reviewed-by: Florian Westphal <fw(a)strlen.de>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/xt_RATEEST.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
--- a/net/netfilter/xt_RATEEST.c
+++ b/net/netfilter/xt_RATEEST.c
@@ -39,23 +39,31 @@ static void xt_rateest_hash_insert(struc
hlist_add_head(&est->list, &rateest_hash[h]);
}
-struct xt_rateest *xt_rateest_lookup(const char *name)
+static struct xt_rateest *__xt_rateest_lookup(const char *name)
{
struct xt_rateest *est;
unsigned int h;
h = xt_rateest_hash(name);
- mutex_lock(&xt_rateest_mutex);
hlist_for_each_entry(est, &rateest_hash[h], list) {
if (strcmp(est->name, name) == 0) {
est->refcnt++;
- mutex_unlock(&xt_rateest_mutex);
return est;
}
}
- mutex_unlock(&xt_rateest_mutex);
+
return NULL;
}
+
+struct xt_rateest *xt_rateest_lookup(const char *name)
+{
+ struct xt_rateest *est;
+
+ mutex_lock(&xt_rateest_mutex);
+ est = __xt_rateest_lookup(name);
+ mutex_unlock(&xt_rateest_mutex);
+ return est;
+}
EXPORT_SYMBOL_GPL(xt_rateest_lookup);
void xt_rateest_put(struct xt_rateest *est)
@@ -100,8 +108,10 @@ static int xt_rateest_tg_checkentry(cons
net_get_random_once(&jhash_rnd, sizeof(jhash_rnd));
- est = xt_rateest_lookup(info->name);
+ mutex_lock(&xt_rateest_mutex);
+ est = __xt_rateest_lookup(info->name);
if (est) {
+ mutex_unlock(&xt_rateest_mutex);
/*
* If estimator parameters are specified, they must match the
* existing estimator.
@@ -139,11 +149,13 @@ static int xt_rateest_tg_checkentry(cons
info->est = est;
xt_rateest_hash_insert(est);
+ mutex_unlock(&xt_rateest_mutex);
return 0;
err2:
kfree(est);
err1:
+ mutex_unlock(&xt_rateest_mutex);
return ret;
}
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.14/net_sched-gen_estimator-fix-lockdep-splat.patch
queue-4.14/netfilter-xt_cgroup-initialize-info-priv-in-cgroup_mt_check_v1.patch
queue-4.14/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
queue-4.14/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE
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:
ptr_ring-fail-early-if-queue-occupies-more-than-kmalloc_max_size.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 6e6e41c3112276288ccaf80c70916779b84bb276 Mon Sep 17 00:00:00 2001
From: Jason Wang <jasowang(a)redhat.com>
Date: Fri, 9 Feb 2018 17:45:49 +0800
Subject: ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE
From: Jason Wang <jasowang(a)redhat.com>
commit 6e6e41c3112276288ccaf80c70916779b84bb276 upstream.
To avoid slab to warn about exceeded size, fail early if queue
occupies more than KMALLOC_MAX_SIZE.
Reported-by: syzbot+e4d4f9ddd4295539735d(a)syzkaller.appspotmail.com
Fixes: 2e0ab8ca83c12 ("ptr_ring: array based FIFO for pointers")
Signed-off-by: Jason Wang <jasowang(a)redhat.com>
Acked-by: Michael S. Tsirkin <mst(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/ptr_ring.h | 2 ++
1 file changed, 2 insertions(+)
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -447,6 +447,8 @@ static inline int ptr_ring_consume_batch
static inline void **__ptr_ring_init_queue_alloc(unsigned int size, gfp_t gfp)
{
+ if (size * sizeof(void *) > KMALLOC_MAX_SIZE)
+ return NULL;
return kcalloc(size, sizeof(void *), gfp);
}
Patches currently in stable-queue which might be from jasowang(a)redhat.com are
queue-4.14/ptr_ring-try-vmalloc-when-kmalloc-fails.patch
queue-4.14/vhost-use-mutex_lock_nested-in-vhost_dev_lock_vqs.patch
queue-4.14/ptr_ring-fail-early-if-queue-occupies-more-than-kmalloc_max_size.patch
This is a note to let you know that I've just added the patch titled
netfilter: xt_cgroup: initialize info->priv in cgroup_mt_check_v1()
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:
netfilter-xt_cgroup-initialize-info-priv-in-cgroup_mt_check_v1.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 ba7cd5d95f25cc6005f687dabdb4e7a6063adda9 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Wed, 31 Jan 2018 15:02:47 -0800
Subject: netfilter: xt_cgroup: initialize info->priv in cgroup_mt_check_v1()
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit ba7cd5d95f25cc6005f687dabdb4e7a6063adda9 upstream.
xt_cgroup_info_v1->priv is an internal pointer only used for kernel,
we should not trust what user-space provides.
Reported-by: <syzbot+4fbcfcc0d2e6592bd641(a)syzkaller.appspotmail.com>
Fixes: c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match")
Cc: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/xt_cgroup.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/netfilter/xt_cgroup.c
+++ b/net/netfilter/xt_cgroup.c
@@ -52,6 +52,7 @@ static int cgroup_mt_check_v1(const stru
return -EINVAL;
}
+ info->priv = NULL;
if (info->has_path) {
cgrp = cgroup_get_from_path(info->path);
if (IS_ERR(cgrp)) {
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.14/net_sched-gen_estimator-fix-lockdep-splat.patch
queue-4.14/netfilter-xt_cgroup-initialize-info-priv-in-cgroup_mt_check_v1.patch
queue-4.14/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
queue-4.14/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
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:
netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.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 da17c73b6eb74aad3c3c0654394635675b623b3e Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 24 Jan 2018 17:16:09 -0800
Subject: netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
From: Eric Dumazet <edumazet(a)google.com>
commit da17c73b6eb74aad3c3c0654394635675b623b3e upstream.
It looks like syzbot found its way into netfilter territory.
Issue here is that @name comes from user space and might
not be null terminated.
Out-of-bound reads happen, KASAN is not happy.
v2 added similar fix for xt_request_find_target(),
as Florian advised.
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Acked-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/x_tables.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -209,6 +209,9 @@ xt_request_find_match(uint8_t nfproto, c
{
struct xt_match *match;
+ if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN)
+ return ERR_PTR(-EINVAL);
+
match = xt_find_match(nfproto, name, revision);
if (IS_ERR(match)) {
request_module("%st_%s", xt_prefix[nfproto], name);
@@ -251,6 +254,9 @@ struct xt_target *xt_request_find_target
{
struct xt_target *target;
+ if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN)
+ return ERR_PTR(-EINVAL);
+
target = xt_find_target(af, name, revision);
if (IS_ERR(target)) {
request_module("%st_%s", xt_prefix[af], name);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.14/kcm-check-if-sk_user_data-already-set-in-kcm_attach.patch
queue-4.14/net_sched-gen_estimator-fix-lockdep-splat.patch
queue-4.14/netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch
queue-4.14/kcm-only-allow-tcp-sockets-to-be-attached-to-a-kcm-mux.patch
queue-4.14/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: fix int overflow in xt_alloc_table_info()
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:
netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.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 889c604fd0b5f6d3b8694ade229ee44124de1127 Mon Sep 17 00:00:00 2001
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Thu, 28 Dec 2017 09:48:54 +0100
Subject: netfilter: x_tables: fix int overflow in xt_alloc_table_info()
From: Dmitry Vyukov <dvyukov(a)google.com>
commit 889c604fd0b5f6d3b8694ade229ee44124de1127 upstream.
syzkaller triggered OOM kills by passing ipt_replace.size = -1
to IPT_SO_SET_REPLACE. The root cause is that SMP_ALIGN() in
xt_alloc_table_info() causes int overflow and the size check passes
when it should not. SMP_ALIGN() is no longer needed leftover.
Remove SMP_ALIGN() call in xt_alloc_table_info().
Reported-by: syzbot+4396883fa8c4f64e0175(a)syzkaller.appspotmail.com
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/x_tables.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -39,7 +39,6 @@ MODULE_LICENSE("GPL");
MODULE_AUTHOR("Harald Welte <laforge(a)netfilter.org>");
MODULE_DESCRIPTION("{ip,ip6,arp,eb}_tables backend module");
-#define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1))
#define XT_PCPU_BLOCK_SIZE 4096
struct compat_delta {
@@ -1000,7 +999,7 @@ struct xt_table_info *xt_alloc_table_inf
return NULL;
/* Pedantry: prevent them from hitting BUG() in vmalloc.c --RR */
- if ((SMP_ALIGN(size) >> PAGE_SHIFT) + 2 > totalram_pages)
+ if ((size >> PAGE_SHIFT) + 2 > totalram_pages)
return NULL;
info = kvmalloc(sz, GFP_KERNEL);
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-4.14/kvm-x86-check-input-paging-mode-when-cs.l-is-set.patch
queue-4.14/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
queue-4.14/blktrace-fix-unlocked-registration-of-tracepoints.patch
queue-4.14/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
queue-4.14/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
queue-4.14/kcov-detect-double-association-with-a-single-task.patch
This is a note to let you know that I've just added the patch titled
netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
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:
netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.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 1a38956cce5eabd7b74f94bab70265e4df83165e Mon Sep 17 00:00:00 2001
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Tue, 30 Jan 2018 15:21:34 +0100
Subject: netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
From: Dmitry Vyukov <dvyukov(a)google.com>
commit 1a38956cce5eabd7b74f94bab70265e4df83165e upstream.
Commit 136e92bbec0a switched local_nodes from an array to a bitmask
but did not add proper bounds checks. As the result
clusterip_config_init_nodelist() can both over-read
ipt_clusterip_tgt_info.local_nodes and over-write
clusterip_config.local_nodes.
Add bounds checks for both.
Fixes: 136e92bbec0a ("[NETFILTER] CLUSTERIP: use a bitmap to store node responsibility data")
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/netfilter/ipt_CLUSTERIP.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -431,7 +431,7 @@ static int clusterip_tg_check(const stru
struct ipt_clusterip_tgt_info *cipinfo = par->targinfo;
const struct ipt_entry *e = par->entryinfo;
struct clusterip_config *config;
- int ret;
+ int ret, i;
if (par->nft_compat) {
pr_err("cannot use CLUSTERIP target from nftables compat\n");
@@ -450,8 +450,18 @@ static int clusterip_tg_check(const stru
pr_info("Please specify destination IP\n");
return -EINVAL;
}
-
- /* FIXME: further sanity checks */
+ if (cipinfo->num_local_nodes > ARRAY_SIZE(cipinfo->local_nodes)) {
+ pr_info("bad num_local_nodes %u\n", cipinfo->num_local_nodes);
+ return -EINVAL;
+ }
+ for (i = 0; i < cipinfo->num_local_nodes; i++) {
+ if (cipinfo->local_nodes[i] - 1 >=
+ sizeof(config->local_nodes) * 8) {
+ pr_info("bad local_nodes[%d] %u\n",
+ i, cipinfo->local_nodes[i]);
+ return -EINVAL;
+ }
+ }
config = clusterip_config_find_get(par->net, e->ip.dst.s_addr, 1);
if (!config) {
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-4.14/kvm-x86-check-input-paging-mode-when-cs.l-is-set.patch
queue-4.14/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
queue-4.14/blktrace-fix-unlocked-registration-of-tracepoints.patch
queue-4.14/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
queue-4.14/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
queue-4.14/kcov-detect-double-association-with-a-single-task.patch
This is a note to let you know that I've just added the patch titled
net_sched: gen_estimator: fix lockdep splat
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:
net_sched-gen_estimator-fix-lockdep-splat.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 40ca54e3a686f13117f3de0c443f8026dadf7c44 Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Sat, 27 Jan 2018 10:58:43 -0800
Subject: net_sched: gen_estimator: fix lockdep splat
From: Eric Dumazet <edumazet(a)google.com>
commit 40ca54e3a686f13117f3de0c443f8026dadf7c44 upstream.
syzbot reported a lockdep splat in gen_new_estimator() /
est_fetch_counters() when attempting to lock est->stats_lock.
Since est_fetch_counters() is called from BH context from timer
interrupt, we need to block BH as well when calling it from process
context.
Most qdiscs use per cpu counters and are immune to the problem,
but net/sched/act_api.c and net/netfilter/xt_RATEEST.c are using
a spinlock to protect their data. They both call gen_new_estimator()
while object is created and not yet alive, so this bug could
not trigger a deadlock, only a lockdep splat.
Fixes: 1c0d32fde5bd ("net_sched: gen_estimator: complete rewrite of rate estimators")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Acked-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/gen_estimator.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/net/core/gen_estimator.c
+++ b/net/core/gen_estimator.c
@@ -159,7 +159,11 @@ int gen_new_estimator(struct gnet_stats_
est->intvl_log = intvl_log;
est->cpu_bstats = cpu_bstats;
+ if (stats_lock)
+ local_bh_disable();
est_fetch_counters(est, &b);
+ if (stats_lock)
+ local_bh_enable();
est->last_bytes = b.bytes;
est->last_packets = b.packets;
old = rcu_dereference_protected(*rate_est, 1);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.14/kcm-check-if-sk_user_data-already-set-in-kcm_attach.patch
queue-4.14/net_sched-gen_estimator-fix-lockdep-splat.patch
queue-4.14/netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch
queue-4.14/kcm-only-allow-tcp-sockets-to-be-attached-to-a-kcm-mux.patch
queue-4.14/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
This is a note to let you know that I've just added the patch titled
net: avoid skb_warn_bad_offload on IS_ERR
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:
net-avoid-skb_warn_bad_offload-on-is_err.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 8d74e9f88d65af8bb2e095aff506aa6eac755ada Mon Sep 17 00:00:00 2001
From: Willem de Bruijn <willemb(a)google.com>
Date: Tue, 12 Dec 2017 11:39:04 -0500
Subject: net: avoid skb_warn_bad_offload on IS_ERR
From: Willem de Bruijn <willemb(a)google.com>
commit 8d74e9f88d65af8bb2e095aff506aa6eac755ada upstream.
skb_warn_bad_offload warns when packets enter the GSO stack that
require skb_checksum_help or vice versa. Do not warn on arbitrary
bad packets. Packet sockets can craft many. Syzkaller was able to
demonstrate another one with eth_type games.
In particular, suppress the warning when segmentation returns an
error, which is for reasons other than checksum offload.
See also commit 36c92474498a ("net: WARN if skb_checksum_help() is
called on skb requiring segmentation") for context on this warning.
Signed-off-by: Willem de Bruijn <willemb(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2792,7 +2792,7 @@ struct sk_buff *__skb_gso_segment(struct
segs = skb_mac_gso_segment(skb, features);
- if (unlikely(skb_needs_check(skb, tx_path)))
+ if (unlikely(skb_needs_check(skb, tx_path) && !IS_ERR(segs)))
skb_warn_bad_offload(skb);
return segs;
Patches currently in stable-queue which might be from willemb(a)google.com are
queue-4.14/net-avoid-skb_warn_bad_offload-on-is_err.patch
This is a note to let you know that I've just added the patch titled
mac80211_hwsim: validate number of different channels
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:
mac80211_hwsim-validate-number-of-different-channels.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 51a1aaa631c90223888d8beac4d649dc11d2ca55 Mon Sep 17 00:00:00 2001
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Mon, 15 Jan 2018 09:32:36 +0100
Subject: mac80211_hwsim: validate number of different channels
From: Johannes Berg <johannes.berg(a)intel.com>
commit 51a1aaa631c90223888d8beac4d649dc11d2ca55 upstream.
When creating a new radio on the fly, hwsim allows this
to be done with an arbitrary number of channels, but
cfg80211 only supports a limited number of simultaneous
channels, leading to a warning.
Fix this by validating the number - this requires moving
the define for the maximum out to a visible header file.
Reported-by: syzbot+8dd9051ff19940290931(a)syzkaller.appspotmail.com
Fixes: b59ec8dd4394 ("mac80211_hwsim: fix number of channels in interface combinations")
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/mac80211_hwsim.c | 5 +++++
include/net/cfg80211.h | 2 ++
net/wireless/core.h | 2 --
3 files changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3119,6 +3119,11 @@ static int hwsim_new_radio_nl(struct sk_
if (info->attrs[HWSIM_ATTR_CHANNELS])
param.channels = nla_get_u32(info->attrs[HWSIM_ATTR_CHANNELS]);
+ if (param.channels > CFG80211_MAX_NUM_DIFFERENT_CHANNELS) {
+ GENL_SET_ERR_MSG(info, "too many channels specified");
+ return -EINVAL;
+ }
+
if (info->attrs[HWSIM_ATTR_NO_VIF])
param.no_vif = true;
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -815,6 +815,8 @@ struct cfg80211_csa_settings {
u8 count;
};
+#define CFG80211_MAX_NUM_DIFFERENT_CHANNELS 10
+
/**
* struct iface_combination_params - input parameters for interface combinations
*
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -502,8 +502,6 @@ void cfg80211_stop_p2p_device(struct cfg
void cfg80211_stop_nan(struct cfg80211_registered_device *rdev,
struct wireless_dev *wdev);
-#define CFG80211_MAX_NUM_DIFFERENT_CHANNELS 10
-
#ifdef CONFIG_CFG80211_DEVELOPER_WARNINGS
#define CFG80211_DEV_WARN_ON(cond) WARN_ON(cond)
#else
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.14/cfg80211-check-dev_set_name-return-value.patch
queue-4.14/mac80211_hwsim-validate-number-of-different-channels.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: fix escape of guest dr6 to the host
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-x86-fix-escape-of-guest-dr6-to-the-host.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 efdab992813fb2ed825745625b83c05032e9cda2 Mon Sep 17 00:00:00 2001
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
Date: Wed, 13 Dec 2017 10:46:40 +0100
Subject: KVM: x86: fix escape of guest dr6 to the host
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
commit efdab992813fb2ed825745625b83c05032e9cda2 upstream.
syzkaller reported:
WARNING: CPU: 0 PID: 12927 at arch/x86/kernel/traps.c:780 do_debug+0x222/0x250
CPU: 0 PID: 12927 Comm: syz-executor Tainted: G OE 4.15.0-rc2+ #16
RIP: 0010:do_debug+0x222/0x250
Call Trace:
<#DB>
debug+0x3e/0x70
RIP: 0010:copy_user_enhanced_fast_string+0x10/0x20
</#DB>
_copy_from_user+0x5b/0x90
SyS_timer_create+0x33/0x80
entry_SYSCALL_64_fastpath+0x23/0x9a
The testcase sets a watchpoint (with perf_event_open) on a buffer that is
passed to timer_create() as the struct sigevent argument. In timer_create(),
copy_from_user()'s rep movsb triggers the BP. The testcase also sets
the debug registers for the guest.
However, KVM only restores host debug registers when the host has active
watchpoints, which triggers a race condition when running the testcase with
multiple threads. The guest's DR6.BS bit can escape to the host before
another thread invokes timer_create(), and do_debug() complains.
The fix is to respect do_debug()'s dr6 invariant when leaving KVM.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Cc: David Hildenbrand <david(a)redhat.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/x86.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2926,6 +2926,12 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *
kvm_x86_ops->vcpu_put(vcpu);
kvm_put_guest_fpu(vcpu);
vcpu->arch.last_host_tsc = rdtsc();
+ /*
+ * If userspace has set any breakpoints or watchpoints, dr6 is restored
+ * on every vmexit, but if not, we might have a stale dr6 from the
+ * guest. do_debug expects dr6 to be cleared after it runs, do the same.
+ */
+ set_debugreg(0, 6);
}
static int kvm_vcpu_ioctl_get_lapic(struct kvm_vcpu *vcpu,
Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are
queue-4.14/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
This is a note to let you know that I've just added the patch titled
KVM/x86: Check input paging mode when cs.l is set
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-x86-check-input-paging-mode-when-cs.l-is-set.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 f29810335965ac1f7bcb501ee2af5f039f792416 Mon Sep 17 00:00:00 2001
From: Lan Tianyu <tianyu.lan(a)intel.com>
Date: Thu, 14 Dec 2017 03:01:52 -0500
Subject: KVM/x86: Check input paging mode when cs.l is set
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Lan Tianyu <tianyu.lan(a)intel.com>
commit f29810335965ac1f7bcb501ee2af5f039f792416 upstream.
Reported by syzkaller:
WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 x86_emulate_insn+0x557/0x15f0 [kvm]
Modules linked in: kvm_intel kvm [last unloaded: kvm]
CPU: 0 PID: 27962 Comm: syz-executor Tainted: G B W 4.15.0-rc2-next-20171208+ #32
Hardware name: Intel Corporation S1200SP/S1200SP, BIOS S1200SP.86B.01.03.0006.040720161253 04/07/2016
RIP: 0010:x86_emulate_insn+0x557/0x15f0 [kvm]
RSP: 0018:ffff8807234476d0 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff88072d0237a0 RCX: ffffffffa0065c4d
RDX: 1ffff100e5a046f9 RSI: 0000000000000003 RDI: ffff88072d0237c8
RBP: ffff880723447728 R08: ffff88072d020000 R09: ffffffffa008d240
R10: 0000000000000002 R11: ffffed00e7d87db3 R12: ffff88072d0237c8
R13: ffff88072d023870 R14: ffff88072d0238c2 R15: ffffffffa008d080
FS: 00007f8a68666700(0000) GS:ffff880802200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000002009506c CR3: 000000071fec4005 CR4: 00000000003626f0
Call Trace:
x86_emulate_instruction+0x3bc/0xb70 [kvm]
? reexecute_instruction.part.162+0x130/0x130 [kvm]
vmx_handle_exit+0x46d/0x14f0 [kvm_intel]
? trace_event_raw_event_kvm_entry+0xe7/0x150 [kvm]
? handle_vmfunc+0x2f0/0x2f0 [kvm_intel]
? wait_lapic_expire+0x25/0x270 [kvm]
vcpu_enter_guest+0x720/0x1ef0 [kvm]
...
When CS.L is set, vcpu should run in the 64 bit paging mode.
Current kvm set_sregs function doesn't have such check when
userspace inputs sreg values. This will lead unexpected behavior.
This patch is to add checks for CS.L, EFER.LME, EFER.LMA and
CR4.PAE when get SREG inputs from userspace in order to avoid
unexpected behavior.
Suggested-by: Paolo Bonzini <pbonzini(a)redhat.com>
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Jim Mattson <jmattson(a)google.com>
Signed-off-by: Tianyu Lan <tianyu.lan(a)intel.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/x86.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7474,6 +7474,29 @@ int kvm_task_switch(struct kvm_vcpu *vcp
}
EXPORT_SYMBOL_GPL(kvm_task_switch);
+int kvm_valid_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs)
+{
+ if ((sregs->efer & EFER_LME) && (sregs->cr0 & X86_CR0_PG_BIT)) {
+ /*
+ * When EFER.LME and CR0.PG are set, the processor is in
+ * 64-bit mode (though maybe in a 32-bit code segment).
+ * CR4.PAE and EFER.LMA must be set.
+ */
+ if (!(sregs->cr4 & X86_CR4_PAE_BIT)
+ || !(sregs->efer & EFER_LMA))
+ return -EINVAL;
+ } else {
+ /*
+ * Not in 64-bit mode: EFER.LMA is clear and the code
+ * segment cannot be 64-bit.
+ */
+ if (sregs->efer & EFER_LMA || sregs->cs.l)
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
struct kvm_sregs *sregs)
{
@@ -7486,6 +7509,9 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct
(sregs->cr4 & X86_CR4_OSXSAVE))
return -EINVAL;
+ if (kvm_valid_sregs(vcpu, sregs))
+ return -EINVAL;
+
apic_base_msr.data = sregs->apic_base;
apic_base_msr.host_initiated = true;
if (kvm_set_apic_base(vcpu, &apic_base_msr))
Patches currently in stable-queue which might be from tianyu.lan(a)intel.com are
queue-4.14/kvm-x86-check-input-paging-mode-when-cs.l-is-set.patch
This is a note to let you know that I've just added the patch titled
kcov: detect double association with a single task
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:
kcov-detect-double-association-with-a-single-task.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 a77660d231f8b3d84fd23ed482e0964f7aa546d6 Mon Sep 17 00:00:00 2001
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Tue, 6 Feb 2018 15:40:28 -0800
Subject: kcov: detect double association with a single task
From: Dmitry Vyukov <dvyukov(a)google.com>
commit a77660d231f8b3d84fd23ed482e0964f7aa546d6 upstream.
Currently KCOV_ENABLE does not check if the current task is already
associated with another kcov descriptor. As the result it is possible
to associate a single task with more than one kcov descriptor, which
later leads to a memory leak of the old descriptor. This relation is
really meant to be one-to-one (task has only one back link).
Extend validation to detect such misuse.
Link: http://lkml.kernel.org/r/20180122082520.15716-1-dvyukov@google.com
Fixes: 5c9a8750a640 ("kernel: add kcov code coverage")
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Reported-by: Shankara Pailoor <sp3485(a)columbia.edu>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: syzbot <syzkaller(a)googlegroups.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>
---
kernel/kcov.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/kcov.c
+++ b/kernel/kcov.c
@@ -225,9 +225,9 @@ static int kcov_ioctl_locked(struct kcov
if (unused != 0 || kcov->mode == KCOV_MODE_DISABLED ||
kcov->area == NULL)
return -EINVAL;
- if (kcov->t != NULL)
- return -EBUSY;
t = current;
+ if (kcov->t != NULL || t->kcov != NULL)
+ return -EBUSY;
/* Cache in task struct for performance. */
t->kcov_size = kcov->size;
t->kcov_area = kcov->area;
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-4.14/kvm-x86-check-input-paging-mode-when-cs.l-is-set.patch
queue-4.14/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
queue-4.14/blktrace-fix-unlocked-registration-of-tracepoints.patch
queue-4.14/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
queue-4.14/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
queue-4.14/kcov-detect-double-association-with-a-single-task.patch
This is a note to let you know that I've just added the patch titled
kcm: Only allow TCP sockets to be attached to a KCM mux
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:
kcm-only-allow-tcp-sockets-to-be-attached-to-a-kcm-mux.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 581e7226a5d43f629eb6399a121f85f6a15f81be Mon Sep 17 00:00:00 2001
From: Tom Herbert <tom(a)quantonium.net>
Date: Wed, 24 Jan 2018 12:35:40 -0800
Subject: kcm: Only allow TCP sockets to be attached to a KCM mux
From: Tom Herbert <tom(a)quantonium.net>
commit 581e7226a5d43f629eb6399a121f85f6a15f81be upstream.
TCP sockets for IPv4 and IPv6 that are not listeners or in closed
stated are allowed to be attached to a KCM mux.
Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
Reported-by: syzbot+8865eaff7f9acd593945(a)syzkaller.appspotmail.com
Signed-off-by: Tom Herbert <tom(a)quantonium.net>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/kcm/kcmsock.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -1387,8 +1387,13 @@ static int kcm_attach(struct socket *soc
if (!csk)
return -EINVAL;
- /* We must prevent loops or risk deadlock ! */
- if (csk->sk_family == PF_KCM)
+ /* Only allow TCP sockets to be attached for now */
+ if ((csk->sk_family != AF_INET && csk->sk_family != AF_INET6) ||
+ csk->sk_protocol != IPPROTO_TCP)
+ return -EOPNOTSUPP;
+
+ /* Don't allow listeners or closed sockets */
+ if (csk->sk_state == TCP_LISTEN || csk->sk_state == TCP_CLOSE)
return -EOPNOTSUPP;
psock = kmem_cache_zalloc(kcm_psockp, GFP_KERNEL);
Patches currently in stable-queue which might be from tom(a)quantonium.net are
queue-4.14/kcm-check-if-sk_user_data-already-set-in-kcm_attach.patch
queue-4.14/kcm-only-allow-tcp-sockets-to-be-attached-to-a-kcm-mux.patch
This is a note to let you know that I've just added the patch titled
kcm: Check if sk_user_data already set in kcm_attach
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:
kcm-check-if-sk_user_data-already-set-in-kcm_attach.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 e5571240236c5652f3e079b1d5866716a7ad819c Mon Sep 17 00:00:00 2001
From: Tom Herbert <tom(a)quantonium.net>
Date: Wed, 24 Jan 2018 12:35:41 -0800
Subject: kcm: Check if sk_user_data already set in kcm_attach
From: Tom Herbert <tom(a)quantonium.net>
commit e5571240236c5652f3e079b1d5866716a7ad819c upstream.
This is needed to prevent sk_user_data being overwritten.
The check is done under the callback lock. This should prevent
a socket from being attached twice to a KCM mux. It also prevents
a socket from being attached for other use cases of sk_user_data
as long as the other cases set sk_user_data under the lock.
Followup work is needed to unify all the use cases of sk_user_data
to use the same locking.
Reported-by: syzbot+114b15f2be420a8886c3(a)syzkaller.appspotmail.com
Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
Signed-off-by: Tom Herbert <tom(a)quantonium.net>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/kcm/kcmsock.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -1405,9 +1405,18 @@ static int kcm_attach(struct socket *soc
return err;
}
- sock_hold(csk);
-
write_lock_bh(&csk->sk_callback_lock);
+
+ /* Check if sk_user_data is aready by KCM or someone else.
+ * Must be done under lock to prevent race conditions.
+ */
+ if (csk->sk_user_data) {
+ write_unlock_bh(&csk->sk_callback_lock);
+ strp_done(&psock->strp);
+ kmem_cache_free(kcm_psockp, psock);
+ return -EALREADY;
+ }
+
psock->save_data_ready = csk->sk_data_ready;
psock->save_write_space = csk->sk_write_space;
psock->save_state_change = csk->sk_state_change;
@@ -1415,8 +1424,11 @@ static int kcm_attach(struct socket *soc
csk->sk_data_ready = psock_data_ready;
csk->sk_write_space = psock_write_space;
csk->sk_state_change = psock_state_change;
+
write_unlock_bh(&csk->sk_callback_lock);
+ sock_hold(csk);
+
/* Finished initialization, now add the psock to the MUX. */
spin_lock_bh(&mux->lock);
head = &mux->psocks;
Patches currently in stable-queue which might be from tom(a)quantonium.net are
queue-4.14/kcm-check-if-sk_user_data-already-set-in-kcm_attach.patch
queue-4.14/kcm-only-allow-tcp-sockets-to-be-attached-to-a-kcm-mux.patch
This is a note to let you know that I've just added the patch titled
esp: Fix GRO when the headers not fully in the linear part of the skb.
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:
esp-fix-gro-when-the-headers-not-fully-in-the-linear-part-of-the-skb.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 374d1b5a81f7f9cc5e7f095ac3d5aff3f6600376 Mon Sep 17 00:00:00 2001
From: Steffen Klassert <steffen.klassert(a)secunet.com>
Date: Fri, 5 Jan 2018 08:35:47 +0100
Subject: esp: Fix GRO when the headers not fully in the linear part of the skb.
From: Steffen Klassert <steffen.klassert(a)secunet.com>
commit 374d1b5a81f7f9cc5e7f095ac3d5aff3f6600376 upstream.
The GRO layer does not necessarily pull the complete headers
into the linear part of the skb, a part may remain on the
first page fragment. This can lead to a crash if we try to
pull the headers, so make sure we have them on the linear
part before pulling.
Fixes: 7785bba299a8 ("esp: Add a software GRO codepath")
Reported-by: syzbot+82bbd65569c49c6c0c4d(a)syzkaller.appspotmail.com
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/esp4_offload.c | 3 ++-
net/ipv6/esp6_offload.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
--- a/net/ipv4/esp4_offload.c
+++ b/net/ipv4/esp4_offload.c
@@ -38,7 +38,8 @@ static struct sk_buff **esp4_gro_receive
__be32 spi;
int err;
- skb_pull(skb, offset);
+ if (!pskb_pull(skb, offset))
+ return NULL;
if ((err = xfrm_parse_spi(skb, IPPROTO_ESP, &spi, &seq)) != 0)
goto out;
--- a/net/ipv6/esp6_offload.c
+++ b/net/ipv6/esp6_offload.c
@@ -60,7 +60,8 @@ static struct sk_buff **esp6_gro_receive
int nhoff;
int err;
- skb_pull(skb, offset);
+ if (!pskb_pull(skb, offset))
+ return NULL;
if ((err = xfrm_parse_spi(skb, IPPROTO_ESP, &spi, &seq)) != 0)
goto out;
Patches currently in stable-queue which might be from steffen.klassert(a)secunet.com are
queue-4.14/xfrm-fix-stack-out-of-bounds-read-on-socket-policy-lookup.patch
queue-4.14/xfrm-skip-policies-marked-as-dead-while-rehashing.patch
queue-4.14/xfrm-fix-rcu-usage-in-xfrm_get_type_offload.patch
queue-4.14/esp-fix-gro-when-the-headers-not-fully-in-the-linear-part-of-the-skb.patch
queue-4.14/xfrm-don-t-call-xfrm_policy_cache_flush-while-holding-spinlock.patch
queue-4.14/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all
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:
drm-require-__gfp_nofail-for-the-legacy-drm_modeset_lock_all.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 d18d1a5ac811d12f7ebc1129230312b5f2c50cb8 Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Tue, 31 Oct 2017 11:55:35 +0000
Subject: drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Chris Wilson <chris(a)chris-wilson.co.uk>
commit d18d1a5ac811d12f7ebc1129230312b5f2c50cb8 upstream.
To acquire all modeset locks requires a ww_ctx to be allocated. As this
is the legacy path and the allocation small, to reduce the changes
required (and complex untested error handling) to the legacy drivers, we
simply assume that the allocation succeeds. At present, it relies on the
too-small-to-fail rule, but syzbot found that by injecting a failure
here we would hit the WARN. Document that this allocation must succeed
with __GFP_NOFAIL.
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031115535.15166-1-chris@…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_modeset_lock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -88,7 +88,7 @@ void drm_modeset_lock_all(struct drm_dev
struct drm_modeset_acquire_ctx *ctx;
int ret;
- ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL | __GFP_NOFAIL);
if (WARN_ON(!ctx))
return;
Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are
queue-4.14/drm-require-__gfp_nofail-for-the-legacy-drm_modeset_lock_all.patch
This is a note to let you know that I've just added the patch titled
dnotify: Handle errors from fsnotify_add_mark_locked() in fcntl_dirnotify()
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:
dnotify-handle-errors-from-fsnotify_add_mark_locked-in-fcntl_dirnotify.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 b3a0066005821acdc0cdb092cb72587182ab583f Mon Sep 17 00:00:00 2001
From: Jan Kara <jack(a)suse.cz>
Date: Tue, 31 Oct 2017 09:53:28 +0100
Subject: dnotify: Handle errors from fsnotify_add_mark_locked() in fcntl_dirnotify()
From: Jan Kara <jack(a)suse.cz>
commit b3a0066005821acdc0cdb092cb72587182ab583f upstream.
fsnotify_add_mark_locked() can fail but we do not check its return
value. This didn't matter before commit 9dd813c15b2c "fsnotify: Move
mark list head from object into dedicated structure" as none of possible
failures could happen for dnotify but after that commit -ENOMEM can be
returned. Handle this error properly in fcntl_dirnotify() as
otherwise we just hit BUG_ON(dn_mark->dn) in dnotify_free_mark().
Reviewed-by: Amir Goldstein <amir73il(a)gmail.com>
Reported-by: syzkaller
Fixes: 9dd813c15b2c101168808d4f5941a29985758973
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/notify/dnotify/dnotify.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/fs/notify/dnotify/dnotify.c
+++ b/fs/notify/dnotify/dnotify.c
@@ -319,7 +319,11 @@ int fcntl_dirnotify(int fd, struct file
dn_mark = container_of(fsn_mark, struct dnotify_mark, fsn_mark);
spin_lock(&fsn_mark->lock);
} else {
- fsnotify_add_mark_locked(new_fsn_mark, inode, NULL, 0);
+ error = fsnotify_add_mark_locked(new_fsn_mark, inode, NULL, 0);
+ if (error) {
+ mutex_unlock(&dnotify_group->mark_mutex);
+ goto out_err;
+ }
spin_lock(&new_fsn_mark->lock);
fsn_mark = new_fsn_mark;
dn_mark = new_dn_mark;
@@ -345,6 +349,7 @@ int fcntl_dirnotify(int fd, struct file
*/
if (dn_mark == new_dn_mark)
destroy = 1;
+ error = 0;
goto out;
}
Patches currently in stable-queue which might be from jack(a)suse.cz are
queue-4.14/dnotify-handle-errors-from-fsnotify_add_mark_locked-in-fcntl_dirnotify.patch
This is a note to let you know that I've just added the patch titled
cfg80211: check dev_set_name() return value
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:
cfg80211-check-dev_set_name-return-value.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 59b179b48ce2a6076448a44531242ac2b3f6cef2 Mon Sep 17 00:00:00 2001
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Mon, 15 Jan 2018 09:58:27 +0100
Subject: cfg80211: check dev_set_name() return value
From: Johannes Berg <johannes.berg(a)intel.com>
commit 59b179b48ce2a6076448a44531242ac2b3f6cef2 upstream.
syzbot reported a warning from rfkill_alloc(), and after a while
I think that the reason is that it was doing fault injection and
the dev_set_name() failed, leaving the name NULL, and we didn't
check the return value and got to rfkill_alloc() with a NULL name.
Since we really don't want a NULL name, we ought to check the
return value.
Fixes: fb28ad35906a ("net: struct device - replace bus_id with dev_name(), dev_set_name()")
Reported-by: syzbot+1ddfb3357e1d7bb5b5d3(a)syzkaller.appspotmail.com
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/wireless/core.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -439,6 +439,8 @@ struct wiphy *wiphy_new_nm(const struct
if (rv)
goto use_default_name;
} else {
+ int rv;
+
use_default_name:
/* NOTE: This is *probably* safe w/out holding rtnl because of
* the restrictions on phy names. Probably this call could
@@ -446,7 +448,11 @@ use_default_name:
* phyX. But, might should add some locking and check return
* value, and use a different name if this one exists?
*/
- dev_set_name(&rdev->wiphy.dev, PHY_NAME "%d", rdev->wiphy_idx);
+ rv = dev_set_name(&rdev->wiphy.dev, PHY_NAME "%d", rdev->wiphy_idx);
+ if (rv < 0) {
+ kfree(rdev);
+ return NULL;
+ }
}
INIT_LIST_HEAD(&rdev->wiphy.wdev_list);
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.14/cfg80211-check-dev_set_name-return-value.patch
queue-4.14/mac80211_hwsim-validate-number-of-different-channels.patch
This is a note to let you know that I've just added the patch titled
blk_rq_map_user_iov: fix error override
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_rq_map_user_iov-fix-error-override.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 69e0927b3774563c19b5fb32e91d75edc147fb62 Mon Sep 17 00:00:00 2001
From: Douglas Gilbert <dgilbert(a)interlog.com>
Date: Sun, 14 Jan 2018 17:00:48 -0500
Subject: blk_rq_map_user_iov: fix error override
From: Douglas Gilbert <dgilbert(a)interlog.com>
commit 69e0927b3774563c19b5fb32e91d75edc147fb62 upstream.
During stress tests by syzkaller on the sg driver the block layer
infrequently returns EINVAL. Closer inspection shows the block
layer was trying to return ENOMEM (which is much more
understandable) but for some reason overroad that useful error.
Patch below does not show this (unchanged) line:
ret =__blk_rq_map_user_iov(rq, map_data, &i, gfp_mask, copy);
That 'ret' was being overridden when that function failed.
Signed-off-by: Douglas Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-map.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/block/blk-map.c
+++ b/block/blk-map.c
@@ -126,7 +126,7 @@ int blk_rq_map_user_iov(struct request_q
unsigned long align = q->dma_pad_mask | queue_dma_alignment(q);
struct bio *bio = NULL;
struct iov_iter i;
- int ret;
+ int ret = -EINVAL;
if (!iter_is_iovec(iter))
goto fail;
@@ -155,7 +155,7 @@ unmap_rq:
__blk_rq_unmap_user(bio);
fail:
rq->bio = NULL;
- return -EINVAL;
+ return ret;
}
EXPORT_SYMBOL(blk_rq_map_user_iov);
Patches currently in stable-queue which might be from dgilbert(a)interlog.com are
queue-4.14/blk_rq_map_user_iov-fix-error-override.patch
This is a note to let you know that I've just added the patch titled
ALSA: caiaq: Add a sanity check for invalid EPs
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:
alsa-caiaq-add-a-sanity-check-for-invalid-eps.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 58fc7f73a85d45a47057dad2af53502fdf6cf778 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Wed, 4 Oct 2017 15:07:21 +0200
Subject: ALSA: caiaq: Add a sanity check for invalid EPs
From: Takashi Iwai <tiwai(a)suse.de>
commit 58fc7f73a85d45a47057dad2af53502fdf6cf778 upstream.
As syzkaller spotted, currently caiaq driver submits a URB with the
fixed EP without checking whether it's actually available, which may
result in a kernel warning like:
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1150 at drivers/usb/core/urb.c:449
usb_submit_urb+0xf8a/0x11d0
Modules linked in:
CPU: 1 PID: 1150 Comm: kworker/1:1 Not tainted
4.14.0-rc2-42660-g24b7bd59eec0 #277
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
init_card sound/usb/caiaq/device.c:467
snd_probe+0x81c/0x1150 sound/usb/caiaq/device.c:525
usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
....
This patch adds a sanity check of validity of EPs at the device
initialization phase for avoiding the call with an invalid EP.
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/usb/caiaq/device.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/sound/usb/caiaq/device.c
+++ b/sound/usb/caiaq/device.c
@@ -461,6 +461,13 @@ static int init_card(struct snd_usb_caia
cdev->midi_out_buf, EP1_BUFSIZE,
snd_usb_caiaq_midi_output_done, cdev);
+ /* sanity checks of EPs before actually submitting */
+ if (usb_urb_ep_type_check(&cdev->ep1_in_urb) ||
+ usb_urb_ep_type_check(&cdev->midi_out_urb)) {
+ dev_err(dev, "invalid EPs\n");
+ return -EINVAL;
+ }
+
init_waitqueue_head(&cdev->ep1_wait_queue);
init_waitqueue_head(&cdev->prepare_wait_queue);
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.14/alsa-bcd2000-add-a-sanity-check-for-invalid-eps.patch
queue-4.14/alsa-caiaq-add-a-sanity-check-for-invalid-eps.patch
queue-4.14/alsa-line6-add-a-sanity-check-for-invalid-eps.patch
queue-4.14/usb-core-add-a-helper-function-to-check-the-validity-of-ep-type-in-urb.patch
This is a note to let you know that I've just added the patch titled
ALSA: line6: Add a sanity check for invalid EPs
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:
alsa-line6-add-a-sanity-check-for-invalid-eps.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 2a4340c57717162c6bf07a0860d05711d4de994b Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Wed, 4 Oct 2017 15:09:24 +0200
Subject: ALSA: line6: Add a sanity check for invalid EPs
From: Takashi Iwai <tiwai(a)suse.de>
commit 2a4340c57717162c6bf07a0860d05711d4de994b upstream.
As syzkaller spotted, currently line6 drivers submit a URB with the
fixed EP without checking whether it's actually available, which may
result in a kernel warning like:
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
------------[ cut here ]------------
WARNING: CPU: 0 PID: 24 at drivers/usb/core/urb.c:449
usb_submit_urb+0xf8a/0x11d0
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc2-42613-g1488251d1a98 #238
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
line6_start_listen+0x55f/0x9e0 sound/usb/line6/driver.c:82
line6_init_cap_control sound/usb/line6/driver.c:690
line6_probe+0x7c9/0x1310 sound/usb/line6/driver.c:764
podhd_probe+0x64/0x70 sound/usb/line6/podhd.c:474
usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
....
This patch adds a sanity check of validity of EPs at the device
initialization phase for avoiding the call with an invalid EP.
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/usb/line6/driver.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -78,6 +78,13 @@ static int line6_start_listen(struct usb
line6->buffer_listen, LINE6_BUFSIZE_LISTEN,
line6_data_received, line6);
}
+
+ /* sanity checks of EP before actually submitting */
+ if (usb_urb_ep_type_check(line6->urb_listen)) {
+ dev_err(line6->ifcdev, "invalid control EP\n");
+ return -EINVAL;
+ }
+
line6->urb_listen->actual_length = 0;
err = usb_submit_urb(line6->urb_listen, GFP_ATOMIC);
return err;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.14/alsa-bcd2000-add-a-sanity-check-for-invalid-eps.patch
queue-4.14/alsa-caiaq-add-a-sanity-check-for-invalid-eps.patch
queue-4.14/alsa-line6-add-a-sanity-check-for-invalid-eps.patch
queue-4.14/usb-core-add-a-helper-function-to-check-the-validity-of-ep-type-in-urb.patch
This is a note to let you know that I've just added the patch titled
ALSA: bcd2000: Add a sanity check for invalid EPs
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:
alsa-bcd2000-add-a-sanity-check-for-invalid-eps.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 6815a0b444572527256f0d0efd8efe3ddede6018 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Wed, 4 Oct 2017 15:03:40 +0200
Subject: ALSA: bcd2000: Add a sanity check for invalid EPs
From: Takashi Iwai <tiwai(a)suse.de>
commit 6815a0b444572527256f0d0efd8efe3ddede6018 upstream.
As syzkaller spotted, currently bcd2000 driver submits a URB with the
fixed EP without checking whether it's actually available, which may
result in a kernel warning like:
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1846 at drivers/usb/core/urb.c:449
usb_submit_urb+0xf8a/0x11d0
Modules linked in:
CPU: 0 PID: 1846 Comm: kworker/0:2 Not tainted
4.14.0-rc2-42613-g1488251d1a98 #238
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
bcd2000_init_device sound/usb/bcd2000/bcd2000.c:289
bcd2000_init_midi sound/usb/bcd2000/bcd2000.c:345
bcd2000_probe+0xe64/0x19e0 sound/usb/bcd2000/bcd2000.c:406
usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
....
This patch adds a sanity check of validity of EPs at the device
initialization phase for avoiding the call with an invalid EP.
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Tested-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/usb/bcd2000/bcd2000.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/sound/usb/bcd2000/bcd2000.c
+++ b/sound/usb/bcd2000/bcd2000.c
@@ -342,6 +342,13 @@ static int bcd2000_init_midi(struct bcd2
bcd2k->midi_out_buf, BUFSIZE,
bcd2000_output_complete, bcd2k, 1);
+ /* sanity checks of EPs before actually submitting */
+ if (usb_urb_ep_type_check(bcd2k->midi_in_urb) ||
+ usb_urb_ep_type_check(bcd2k->midi_out_urb)) {
+ dev_err(&bcd2k->dev->dev, "invalid MIDI EP\n");
+ return -EINVAL;
+ }
+
bcd2000_init_device(bcd2k);
return 0;
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.14/alsa-bcd2000-add-a-sanity-check-for-invalid-eps.patch
queue-4.14/alsa-caiaq-add-a-sanity-check-for-invalid-eps.patch
queue-4.14/alsa-line6-add-a-sanity-check-for-invalid-eps.patch
queue-4.14/usb-core-add-a-helper-function-to-check-the-validity-of-ep-type-in-urb.patch
This is a note to let you know that I've just added the patch titled
tun: fix tun_napi_alloc_frags() frag allocator
to the 4.15-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:
tun-fix-tun_napi_alloc_frags-frag-allocator.patch
and it can be found in the queue-4.15 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 43a08e0f58b3f236165029710a4e3b303815253b Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Thu, 15 Feb 2018 14:47:15 -0800
Subject: tun: fix tun_napi_alloc_frags() frag allocator
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Eric Dumazet <edumazet(a)google.com>
commit 43a08e0f58b3f236165029710a4e3b303815253b upstream.
<Mark Rutland reported>
While fuzzing arm64 v4.16-rc1 with Syzkaller, I've been hitting a
misaligned atomic in __skb_clone:
atomic_inc(&(skb_shinfo(skb)->dataref));
where dataref doesn't have the required natural alignment, and the
atomic operation faults. e.g. i often see it aligned to a single
byte boundary rather than a four byte boundary.
AFAICT, the skb_shared_info is misaligned at the instant it's
allocated in __napi_alloc_skb() __napi_alloc_skb()
</end of report>
Problem is caused by tun_napi_alloc_frags() using
napi_alloc_frag() with user provided seg sizes,
leading to other users of this API getting unaligned
page fragments.
Since we would like to not necessarily add paddings or alignments to
the frags that tun_napi_alloc_frags() attaches to the skb, switch to
another page frag allocator.
As a bonus skb_page_frag_refill() can use GFP_KERNEL allocations,
meaning that we can not deplete memory reserves as easily.
Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: Mark Rutland <mark.rutland(a)arm.com>
Tested-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/tun.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1317,27 +1317,23 @@ static struct sk_buff *tun_napi_alloc_fr
skb->truesize += skb->data_len;
for (i = 1; i < it->nr_segs; i++) {
+ struct page_frag *pfrag = ¤t->task_frag;
size_t fragsz = it->iov[i].iov_len;
- unsigned long offset;
- struct page *page;
- void *data;
if (fragsz == 0 || fragsz > PAGE_SIZE) {
err = -EINVAL;
goto free;
}
- local_bh_disable();
- data = napi_alloc_frag(fragsz);
- local_bh_enable();
- if (!data) {
+ if (!skb_page_frag_refill(fragsz, pfrag, GFP_KERNEL)) {
err = -ENOMEM;
goto free;
}
- page = virt_to_head_page(data);
- offset = data - page_address(page);
- skb_fill_page_desc(skb, i - 1, page, offset, fragsz);
+ skb_fill_page_desc(skb, i - 1, pfrag->page,
+ pfrag->offset, fragsz);
+ page_ref_inc(pfrag->page);
+ pfrag->offset += fragsz;
}
return skb;
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.15/net_sched-gen_estimator-fix-lockdep-splat.patch
queue-4.15/tun-fix-tun_napi_alloc_frags-frag-allocator.patch
queue-4.15/netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch
queue-4.15/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
This is a note to let you know that I've just added the patch titled
staging: android: ion: Switch from WARN to pr_warn
to the 4.15-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:
staging-android-ion-switch-from-warn-to-pr_warn.patch
and it can be found in the queue-4.15 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 e4e179a844f52e907e550f887d0a2171f1508af1 Mon Sep 17 00:00:00 2001
From: Laura Abbott <labbott(a)redhat.com>
Date: Fri, 5 Jan 2018 11:14:09 -0800
Subject: staging: android: ion: Switch from WARN to pr_warn
From: Laura Abbott <labbott(a)redhat.com>
commit e4e179a844f52e907e550f887d0a2171f1508af1 upstream.
Syzbot reported a warning with Ion:
WARNING: CPU: 0 PID: 3502 at drivers/staging/android/ion/ion-ioctl.c:73 ion_ioctl+0x2db/0x380 drivers/staging/android/ion/ion-ioctl.c:73
Kernel panic - not syncing: panic_on_warn set ...
This is a warning that validation of the ioctl fields failed. This was
deliberately added as a warning to make it very obvious to developers that
something needed to be fixed. In reality, this is overkill and disturbs
fuzzing. Switch to pr_warn for a message instead.
Reported-by: syzbot+fa2d5f63ee5904a0115a(a)syzkaller.appspotmail.com
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Laura Abbott <labbott(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ion/ion-ioctl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -70,8 +70,10 @@ long ion_ioctl(struct file *filp, unsign
return -EFAULT;
ret = validate_ioctl_arg(cmd, &data);
- if (WARN_ON_ONCE(ret))
+ if (ret) {
+ pr_warn_once("%s: ioctl validate failed\n", __func__);
return ret;
+ }
if (!(dir & _IOC_WRITE))
memset(&data, 0, sizeof(data));
Patches currently in stable-queue which might be from labbott(a)redhat.com are
queue-4.15/staging-android-ion-switch-from-warn-to-pr_warn.patch
queue-4.15/staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.patch
This is a note to let you know that I've just added the patch titled
selinux: skip bounded transition processing if the policy isn't loaded
to the 4.15-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:
selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch
and it can be found in the queue-4.15 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 4b14752ec4e0d87126e636384cf37c8dd9df157c Mon Sep 17 00:00:00 2001
From: Paul Moore <paul(a)paul-moore.com>
Date: Tue, 5 Dec 2017 17:17:43 -0500
Subject: selinux: skip bounded transition processing if the policy isn't loaded
From: Paul Moore <paul(a)paul-moore.com>
commit 4b14752ec4e0d87126e636384cf37c8dd9df157c upstream.
We can't do anything reasonable in security_bounded_transition() if we
don't have a policy loaded, and in fact we could run into problems
with some of the code inside expecting a policy. Fix these problems
like we do many others in security/selinux/ss/services.c by checking
to see if the policy is loaded (ss_initialized) and returning quickly
if it isn't.
Reported-by: syzbot <syzkaller-bugs(a)googlegroups.com>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Acked-by: Stephen Smalley <sds(a)tycho.nsa.gov>
Reviewed-by: James Morris <james.l.morris(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/selinux/ss/services.c | 3 +++
1 file changed, 3 insertions(+)
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -867,6 +867,9 @@ int security_bounded_transition(u32 old_
int index;
int rc;
+ if (!ss_initialized)
+ return 0;
+
read_lock(&policy_rwlock);
rc = -EINVAL;
Patches currently in stable-queue which might be from paul(a)paul-moore.com are
queue-4.15/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch
queue-4.15/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch
This is a note to let you know that I've just added the patch titled
staging: android: ion: Add __GFP_NOWARN for system contig heap
to the 4.15-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:
staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.patch
and it can be found in the queue-4.15 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 0c75f10312a35b149b2cebb1832316b35c2337ca Mon Sep 17 00:00:00 2001
From: Laura Abbott <labbott(a)redhat.com>
Date: Fri, 5 Jan 2018 11:14:08 -0800
Subject: staging: android: ion: Add __GFP_NOWARN for system contig heap
From: Laura Abbott <labbott(a)redhat.com>
commit 0c75f10312a35b149b2cebb1832316b35c2337ca upstream.
syzbot reported a warning from Ion:
WARNING: CPU: 1 PID: 3485 at mm/page_alloc.c:3926
...
__alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252
alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036
alloc_pages include/linux/gfp.h:492 [inline]
ion_system_contig_heap_allocate+0x40/0x2c0
drivers/staging/android/ion/ion_system_heap.c:374
ion_buffer_create drivers/staging/android/ion/ion.c:93 [inline]
ion_alloc+0x2c1/0x9e0 drivers/staging/android/ion/ion.c:420
ion_ioctl+0x26d/0x380 drivers/staging/android/ion/ion-ioctl.c:84
vfs_ioctl fs/ioctl.c:46 [inline]
do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
SYSC_ioctl fs/ioctl.c:701 [inline]
SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
This is a warning about attempting to allocate order > MAX_ORDER. This
is coming from a userspace Ion allocation request. Since userspace is
free to request however much memory it wants (and the kernel is free to
deny its allocation), silence the allocation attempt with __GFP_NOWARN
in case it fails.
Reported-by: syzbot+76e7efc4748495855a4d(a)syzkaller.appspotmail.com
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Laura Abbott <labbott(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ion/ion_system_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -371,7 +371,7 @@ static int ion_system_contig_heap_alloca
unsigned long i;
int ret;
- page = alloc_pages(low_order_gfp_flags, order);
+ page = alloc_pages(low_order_gfp_flags | __GFP_NOWARN, order);
if (!page)
return -ENOMEM;
Patches currently in stable-queue which might be from labbott(a)redhat.com are
queue-4.15/staging-android-ion-switch-from-warn-to-pr_warn.patch
queue-4.15/staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.patch
This is a note to let you know that I've just added the patch titled
selinux: ensure the context is NUL terminated in security_context_to_sid_core()
to the 4.15-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:
selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch
and it can be found in the queue-4.15 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 ef28df55ac27e1e5cd122e19fa311d886d47a756 Mon Sep 17 00:00:00 2001
From: Paul Moore <paul(a)paul-moore.com>
Date: Tue, 28 Nov 2017 18:51:12 -0500
Subject: selinux: ensure the context is NUL terminated in security_context_to_sid_core()
From: Paul Moore <paul(a)paul-moore.com>
commit ef28df55ac27e1e5cd122e19fa311d886d47a756 upstream.
The syzbot/syzkaller automated tests found a problem in
security_context_to_sid_core() during early boot (before we load the
SELinux policy) where we could potentially feed context strings without
NUL terminators into the strcmp() function.
We already guard against this during normal operation (after the SELinux
policy has been loaded) by making a copy of the context strings and
explicitly adding a NUL terminator to the end. The patch extends this
protection to the early boot case (no loaded policy) by moving the context
copy earlier in security_context_to_sid_core().
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Reviewed-By: William Roberts <william.c.roberts(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/selinux/ss/services.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -1413,27 +1413,25 @@ static int security_context_to_sid_core(
if (!scontext_len)
return -EINVAL;
+ /* Copy the string to allow changes and ensure a NUL terminator */
+ scontext2 = kmemdup_nul(scontext, scontext_len, gfp_flags);
+ if (!scontext2)
+ return -ENOMEM;
+
if (!ss_initialized) {
int i;
for (i = 1; i < SECINITSID_NUM; i++) {
- if (!strcmp(initial_sid_to_string[i], scontext)) {
+ if (!strcmp(initial_sid_to_string[i], scontext2)) {
*sid = i;
- return 0;
+ goto out;
}
}
*sid = SECINITSID_KERNEL;
- return 0;
+ goto out;
}
*sid = SECSID_NULL;
- /* Copy the string so that we can modify the copy as we parse it. */
- scontext2 = kmalloc(scontext_len + 1, gfp_flags);
- if (!scontext2)
- return -ENOMEM;
- memcpy(scontext2, scontext, scontext_len);
- scontext2[scontext_len] = 0;
-
if (force) {
/* Save another copy for storing in uninterpreted form */
rc = -ENOMEM;
Patches currently in stable-queue which might be from paul(a)paul-moore.com are
queue-4.15/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch
queue-4.15/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch
This is a note to let you know that I've just added the patch titled
rds: tcp: correctly sequence cleanup on netns deletion.
to the 4.15-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:
rds-tcp-correctly-sequence-cleanup-on-netns-deletion.patch
and it can be found in the queue-4.15 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 681648e67d43cf269c5590ecf021ed481f4551fc Mon Sep 17 00:00:00 2001
From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
Date: Thu, 30 Nov 2017 11:11:28 -0800
Subject: rds: tcp: correctly sequence cleanup on netns deletion.
From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
commit 681648e67d43cf269c5590ecf021ed481f4551fc upstream.
Commit 8edc3affc077 ("rds: tcp: Take explicit refcounts on struct net")
introduces a regression in rds-tcp netns cleanup. The cleanup_net(),
(and thus rds_tcp_dev_event notification) is only called from put_net()
when all netns refcounts go to 0, but this cannot happen if the
rds_connection itself is holding a c_net ref that it expects to
release in rds_tcp_kill_sock.
Instead, the rds_tcp_kill_sock callback should make sure to
tear down state carefully, ensuring that the socket teardown
is only done after all data-structures and workqs that depend
on it are quiesced.
The original motivation for commit 8edc3affc077 ("rds: tcp: Take explicit
refcounts on struct net") was to resolve a race condition reported by
syzkaller where workqs for tx/rx/connect were triggered after the
namespace was deleted. Those worker threads should have been
cancelled/flushed before socket tear-down and indeed,
rds_conn_path_destroy() does try to sequence this by doing
/* cancel cp_send_w */
/* cancel cp_recv_w */
/* flush cp_down_w */
/* free data structures */
Here the "flush cp_down_w" will trigger rds_conn_shutdown and thus
invoke rds_tcp_conn_path_shutdown() to close the tcp socket, so that
we ought to have satisfied the requirement that "socket-close is
done after all other dependent state is quiesced". However,
rds_conn_shutdown has a bug in that it *always* triggers the reconnect
workq (and if connection is successful, we always restart tx/rx
workqs so with the right timing, we risk the race conditions reported
by syzkaller).
Netns deletion is like module teardown- no need to restart a
reconnect in this case. We can use the c_destroy_in_prog bit
to avoid restarting the reconnect.
Fixes: 8edc3affc077 ("rds: tcp: Take explicit refcounts on struct net")
Signed-off-by: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/rds/connection.c | 3 ++-
net/rds/rds.h | 6 +++---
net/rds/tcp.c | 4 ++--
3 files changed, 7 insertions(+), 6 deletions(-)
--- a/net/rds/connection.c
+++ b/net/rds/connection.c
@@ -366,6 +366,8 @@ void rds_conn_shutdown(struct rds_conn_p
* to the conn hash, so we never trigger a reconnect on this
* conn - the reconnect is always triggered by the active peer. */
cancel_delayed_work_sync(&cp->cp_conn_w);
+ if (conn->c_destroy_in_prog)
+ return;
rcu_read_lock();
if (!hlist_unhashed(&conn->c_hash_node)) {
rcu_read_unlock();
@@ -445,7 +447,6 @@ void rds_conn_destroy(struct rds_connect
*/
rds_cong_remove_conn(conn);
- put_net(conn->c_net);
kfree(conn->c_path);
kmem_cache_free(rds_conn_slab, conn);
--- a/net/rds/rds.h
+++ b/net/rds/rds.h
@@ -150,7 +150,7 @@ struct rds_connection {
/* Protocol version */
unsigned int c_version;
- struct net *c_net;
+ possible_net_t c_net;
struct list_head c_map_item;
unsigned long c_map_queued;
@@ -165,13 +165,13 @@ struct rds_connection {
static inline
struct net *rds_conn_net(struct rds_connection *conn)
{
- return conn->c_net;
+ return read_pnet(&conn->c_net);
}
static inline
void rds_conn_net_set(struct rds_connection *conn, struct net *net)
{
- conn->c_net = get_net(net);
+ write_pnet(&conn->c_net, net);
}
#define RDS_FLAG_CONG_BITMAP 0x01
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -528,7 +528,7 @@ static void rds_tcp_kill_sock(struct net
rds_tcp_listen_stop(lsock, &rtn->rds_tcp_accept_w);
spin_lock_irq(&rds_tcp_conn_lock);
list_for_each_entry_safe(tc, _tc, &rds_tcp_conn_list, t_tcp_node) {
- struct net *c_net = tc->t_cpath->cp_conn->c_net;
+ struct net *c_net = read_pnet(&tc->t_cpath->cp_conn->c_net);
if (net != c_net || !tc->t_sock)
continue;
@@ -587,7 +587,7 @@ static void rds_tcp_sysctl_reset(struct
spin_lock_irq(&rds_tcp_conn_lock);
list_for_each_entry_safe(tc, _tc, &rds_tcp_conn_list, t_tcp_node) {
- struct net *c_net = tc->t_cpath->cp_conn->c_net;
+ struct net *c_net = read_pnet(&tc->t_cpath->cp_conn->c_net);
if (net != c_net || !tc->t_sock)
continue;
Patches currently in stable-queue which might be from sowmini.varadhan(a)oracle.com are
queue-4.15/rds-tcp-atomically-purge-entries-from-rds_tcp_conn_list-during-netns-delete.patch
queue-4.15/rds-tcp-correctly-sequence-cleanup-on-netns-deletion.patch
This is a note to let you know that I've just added the patch titled
rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete
to the 4.15-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:
rds-tcp-atomically-purge-entries-from-rds_tcp_conn_list-during-netns-delete.patch
and it can be found in the queue-4.15 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 f10b4cff98c6977668434fbf5dd58695eeca2897 Mon Sep 17 00:00:00 2001
From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
Date: Thu, 30 Nov 2017 11:11:29 -0800
Subject: rds: tcp: atomically purge entries from rds_tcp_conn_list during netns delete
From: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
commit f10b4cff98c6977668434fbf5dd58695eeca2897 upstream.
The rds_tcp_kill_sock() function parses the rds_tcp_conn_list
to find the rds_connection entries marked for deletion as part
of the netns deletion under the protection of the rds_tcp_conn_lock.
Since the rds_tcp_conn_list tracks rds_tcp_connections (which
have a 1:1 mapping with rds_conn_path), multiple tc entries in
the rds_tcp_conn_list will map to a single rds_connection, and will
be deleted as part of the rds_conn_destroy() operation that is
done outside the rds_tcp_conn_lock.
The rds_tcp_conn_list traversal done under the protection of
rds_tcp_conn_lock should not leave any doomed tc entries in
the list after the rds_tcp_conn_lock is released, else another
concurrently executiong netns delete (for a differnt netns) thread
may trip on these entries.
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Sowmini Varadhan <sowmini.varadhan(a)oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/rds/tcp.c | 9 +++++++--
net/rds/tcp.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -307,7 +307,8 @@ static void rds_tcp_conn_free(void *arg)
rdsdebug("freeing tc %p\n", tc);
spin_lock_irqsave(&rds_tcp_conn_lock, flags);
- list_del(&tc->t_tcp_node);
+ if (!tc->t_tcp_node_detached)
+ list_del(&tc->t_tcp_node);
spin_unlock_irqrestore(&rds_tcp_conn_lock, flags);
kmem_cache_free(rds_tcp_conn_slab, tc);
@@ -532,8 +533,12 @@ static void rds_tcp_kill_sock(struct net
if (net != c_net || !tc->t_sock)
continue;
- if (!list_has_conn(&tmp_list, tc->t_cpath->cp_conn))
+ if (!list_has_conn(&tmp_list, tc->t_cpath->cp_conn)) {
list_move_tail(&tc->t_tcp_node, &tmp_list);
+ } else {
+ list_del(&tc->t_tcp_node);
+ tc->t_tcp_node_detached = true;
+ }
}
spin_unlock_irq(&rds_tcp_conn_lock);
list_for_each_entry_safe(tc, _tc, &tmp_list, t_tcp_node) {
--- a/net/rds/tcp.h
+++ b/net/rds/tcp.h
@@ -12,6 +12,7 @@ struct rds_tcp_incoming {
struct rds_tcp_connection {
struct list_head t_tcp_node;
+ bool t_tcp_node_detached;
struct rds_conn_path *t_cpath;
/* t_conn_path_lock synchronizes the connection establishment between
* rds_tcp_accept_one and rds_tcp_conn_path_connect
Patches currently in stable-queue which might be from sowmini.varadhan(a)oracle.com are
queue-4.15/rds-tcp-atomically-purge-entries-from-rds_tcp_conn_list-during-netns-delete.patch
queue-4.15/rds-tcp-correctly-sequence-cleanup-on-netns-deletion.patch
This is a note to let you know that I've just added the patch titled
ptr_ring: try vmalloc() when kmalloc() fails
to the 4.15-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:
ptr_ring-try-vmalloc-when-kmalloc-fails.patch
and it can be found in the queue-4.15 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 0bf7800f1799b5b1fd7d4f024e9ece53ac489011 Mon Sep 17 00:00:00 2001
From: Jason Wang <jasowang(a)redhat.com>
Date: Fri, 9 Feb 2018 17:45:50 +0800
Subject: ptr_ring: try vmalloc() when kmalloc() fails
From: Jason Wang <jasowang(a)redhat.com>
commit 0bf7800f1799b5b1fd7d4f024e9ece53ac489011 upstream.
This patch switch to use kvmalloc_array() for using a vmalloc()
fallback to help in case kmalloc() fails.
Reported-by: syzbot+e4d4f9ddd4295539735d(a)syzkaller.appspotmail.com
Fixes: 2e0ab8ca83c12 ("ptr_ring: array based FIFO for pointers")
Signed-off-by: Jason Wang <jasowang(a)redhat.com>
Acked-by: Michael S. Tsirkin <mst(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/ptr_ring.h | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -451,11 +451,14 @@ static inline int ptr_ring_consume_batch
__PTR_RING_PEEK_CALL_v; \
})
+/* Not all gfp_t flags (besides GFP_KERNEL) are allowed. See
+ * documentation for vmalloc for which of them are legal.
+ */
static inline void **__ptr_ring_init_queue_alloc(unsigned int size, gfp_t gfp)
{
if (size * sizeof(void *) > KMALLOC_MAX_SIZE)
return NULL;
- return kcalloc(size, sizeof(void *), gfp);
+ return kvmalloc_array(size, sizeof(void *), gfp | __GFP_ZERO);
}
static inline void __ptr_ring_set_size(struct ptr_ring *r, int size)
@@ -588,7 +591,7 @@ static inline int ptr_ring_resize(struct
spin_unlock(&(r)->producer_lock);
spin_unlock_irqrestore(&(r)->consumer_lock, flags);
- kfree(old);
+ kvfree(old);
return 0;
}
@@ -628,7 +631,7 @@ static inline int ptr_ring_resize_multip
}
for (i = 0; i < nrings; ++i)
- kfree(queues[i]);
+ kvfree(queues[i]);
kfree(queues);
@@ -636,7 +639,7 @@ static inline int ptr_ring_resize_multip
nomem:
while (--i >= 0)
- kfree(queues[i]);
+ kvfree(queues[i]);
kfree(queues);
@@ -651,7 +654,7 @@ static inline void ptr_ring_cleanup(stru
if (destroy)
while ((ptr = ptr_ring_consume(r)))
destroy(ptr);
- kfree(r->queue);
+ kvfree(r->queue);
}
#endif /* _LINUX_PTR_RING_H */
Patches currently in stable-queue which might be from jasowang(a)redhat.com are
queue-4.15/ptr_ring-try-vmalloc-when-kmalloc-fails.patch
queue-4.15/ptr_ring-fail-early-if-queue-occupies-more-than-kmalloc_max_size.patch
This is a note to let you know that I've just added the patch titled
ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE
to the 4.15-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:
ptr_ring-fail-early-if-queue-occupies-more-than-kmalloc_max_size.patch
and it can be found in the queue-4.15 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 6e6e41c3112276288ccaf80c70916779b84bb276 Mon Sep 17 00:00:00 2001
From: Jason Wang <jasowang(a)redhat.com>
Date: Fri, 9 Feb 2018 17:45:49 +0800
Subject: ptr_ring: fail early if queue occupies more than KMALLOC_MAX_SIZE
From: Jason Wang <jasowang(a)redhat.com>
commit 6e6e41c3112276288ccaf80c70916779b84bb276 upstream.
To avoid slab to warn about exceeded size, fail early if queue
occupies more than KMALLOC_MAX_SIZE.
Reported-by: syzbot+e4d4f9ddd4295539735d(a)syzkaller.appspotmail.com
Fixes: 2e0ab8ca83c12 ("ptr_ring: array based FIFO for pointers")
Signed-off-by: Jason Wang <jasowang(a)redhat.com>
Acked-by: Michael S. Tsirkin <mst(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/ptr_ring.h | 2 ++
1 file changed, 2 insertions(+)
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -453,6 +453,8 @@ static inline int ptr_ring_consume_batch
static inline void **__ptr_ring_init_queue_alloc(unsigned int size, gfp_t gfp)
{
+ if (size * sizeof(void *) > KMALLOC_MAX_SIZE)
+ return NULL;
return kcalloc(size, sizeof(void *), gfp);
}
Patches currently in stable-queue which might be from jasowang(a)redhat.com are
queue-4.15/ptr_ring-try-vmalloc-when-kmalloc-fails.patch
queue-4.15/ptr_ring-fail-early-if-queue-occupies-more-than-kmalloc_max_size.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: fix int overflow in xt_alloc_table_info()
to the 4.15-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:
netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
and it can be found in the queue-4.15 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 889c604fd0b5f6d3b8694ade229ee44124de1127 Mon Sep 17 00:00:00 2001
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Thu, 28 Dec 2017 09:48:54 +0100
Subject: netfilter: x_tables: fix int overflow in xt_alloc_table_info()
From: Dmitry Vyukov <dvyukov(a)google.com>
commit 889c604fd0b5f6d3b8694ade229ee44124de1127 upstream.
syzkaller triggered OOM kills by passing ipt_replace.size = -1
to IPT_SO_SET_REPLACE. The root cause is that SMP_ALIGN() in
xt_alloc_table_info() causes int overflow and the size check passes
when it should not. SMP_ALIGN() is no longer needed leftover.
Remove SMP_ALIGN() call in xt_alloc_table_info().
Reported-by: syzbot+4396883fa8c4f64e0175(a)syzkaller.appspotmail.com
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/x_tables.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -39,7 +39,6 @@ MODULE_LICENSE("GPL");
MODULE_AUTHOR("Harald Welte <laforge(a)netfilter.org>");
MODULE_DESCRIPTION("{ip,ip6,arp,eb}_tables backend module");
-#define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1))
#define XT_PCPU_BLOCK_SIZE 4096
struct compat_delta {
@@ -1000,7 +999,7 @@ struct xt_table_info *xt_alloc_table_inf
return NULL;
/* Pedantry: prevent them from hitting BUG() in vmalloc.c --RR */
- if ((SMP_ALIGN(size) >> PAGE_SHIFT) + 2 > totalram_pages)
+ if ((size >> PAGE_SHIFT) + 2 > totalram_pages)
return NULL;
info = kvmalloc(sz, GFP_KERNEL);
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-4.15/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
queue-4.15/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
queue-4.15/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
queue-4.15/kcov-detect-double-association-with-a-single-task.patch
This is a note to let you know that I've just added the patch titled
netfilter: xt_cgroup: initialize info->priv in cgroup_mt_check_v1()
to the 4.15-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:
netfilter-xt_cgroup-initialize-info-priv-in-cgroup_mt_check_v1.patch
and it can be found in the queue-4.15 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 ba7cd5d95f25cc6005f687dabdb4e7a6063adda9 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Wed, 31 Jan 2018 15:02:47 -0800
Subject: netfilter: xt_cgroup: initialize info->priv in cgroup_mt_check_v1()
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit ba7cd5d95f25cc6005f687dabdb4e7a6063adda9 upstream.
xt_cgroup_info_v1->priv is an internal pointer only used for kernel,
we should not trust what user-space provides.
Reported-by: <syzbot+4fbcfcc0d2e6592bd641(a)syzkaller.appspotmail.com>
Fixes: c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match")
Cc: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/xt_cgroup.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/netfilter/xt_cgroup.c
+++ b/net/netfilter/xt_cgroup.c
@@ -52,6 +52,7 @@ static int cgroup_mt_check_v1(const stru
return -EINVAL;
}
+ info->priv = NULL;
if (info->has_path) {
cgrp = cgroup_get_from_path(info->path);
if (IS_ERR(cgrp)) {
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.15/net_sched-gen_estimator-fix-lockdep-splat.patch
queue-4.15/netfilter-xt_cgroup-initialize-info-priv-in-cgroup_mt_check_v1.patch
queue-4.15/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
This is a note to let you know that I've just added the patch titled
netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
to the 4.15-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:
netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
and it can be found in the queue-4.15 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 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Mon, 5 Feb 2018 14:41:45 -0800
Subject: netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 upstream.
rateest_hash is supposed to be protected by xt_rateest_mutex,
and, as suggested by Eric, lookup and insert should be atomic,
so we should acquire the xt_rateest_mutex once for both.
So introduce a non-locking helper for internal use and keep the
locking one for external.
Reported-by: <syzbot+5cb189720978275e4c75(a)syzkaller.appspotmail.com>
Fixes: 5859034d7eb8 ("[NETFILTER]: x_tables: add RATEEST target")
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Reviewed-by: Florian Westphal <fw(a)strlen.de>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/xt_RATEEST.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
--- a/net/netfilter/xt_RATEEST.c
+++ b/net/netfilter/xt_RATEEST.c
@@ -39,23 +39,31 @@ static void xt_rateest_hash_insert(struc
hlist_add_head(&est->list, &rateest_hash[h]);
}
-struct xt_rateest *xt_rateest_lookup(const char *name)
+static struct xt_rateest *__xt_rateest_lookup(const char *name)
{
struct xt_rateest *est;
unsigned int h;
h = xt_rateest_hash(name);
- mutex_lock(&xt_rateest_mutex);
hlist_for_each_entry(est, &rateest_hash[h], list) {
if (strcmp(est->name, name) == 0) {
est->refcnt++;
- mutex_unlock(&xt_rateest_mutex);
return est;
}
}
- mutex_unlock(&xt_rateest_mutex);
+
return NULL;
}
+
+struct xt_rateest *xt_rateest_lookup(const char *name)
+{
+ struct xt_rateest *est;
+
+ mutex_lock(&xt_rateest_mutex);
+ est = __xt_rateest_lookup(name);
+ mutex_unlock(&xt_rateest_mutex);
+ return est;
+}
EXPORT_SYMBOL_GPL(xt_rateest_lookup);
void xt_rateest_put(struct xt_rateest *est)
@@ -100,8 +108,10 @@ static int xt_rateest_tg_checkentry(cons
net_get_random_once(&jhash_rnd, sizeof(jhash_rnd));
- est = xt_rateest_lookup(info->name);
+ mutex_lock(&xt_rateest_mutex);
+ est = __xt_rateest_lookup(info->name);
if (est) {
+ mutex_unlock(&xt_rateest_mutex);
/*
* If estimator parameters are specified, they must match the
* existing estimator.
@@ -139,11 +149,13 @@ static int xt_rateest_tg_checkentry(cons
info->est = est;
xt_rateest_hash_insert(est);
+ mutex_unlock(&xt_rateest_mutex);
return 0;
err2:
kfree(est);
err1:
+ mutex_unlock(&xt_rateest_mutex);
return ret;
}
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.15/net_sched-gen_estimator-fix-lockdep-splat.patch
queue-4.15/netfilter-xt_cgroup-initialize-info-priv-in-cgroup_mt_check_v1.patch
queue-4.15/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
to the 4.15-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:
netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch
and it can be found in the queue-4.15 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 da17c73b6eb74aad3c3c0654394635675b623b3e Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 24 Jan 2018 17:16:09 -0800
Subject: netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
From: Eric Dumazet <edumazet(a)google.com>
commit da17c73b6eb74aad3c3c0654394635675b623b3e upstream.
It looks like syzbot found its way into netfilter territory.
Issue here is that @name comes from user space and might
not be null terminated.
Out-of-bound reads happen, KASAN is not happy.
v2 added similar fix for xt_request_find_target(),
as Florian advised.
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Acked-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/x_tables.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -209,6 +209,9 @@ xt_request_find_match(uint8_t nfproto, c
{
struct xt_match *match;
+ if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN)
+ return ERR_PTR(-EINVAL);
+
match = xt_find_match(nfproto, name, revision);
if (IS_ERR(match)) {
request_module("%st_%s", xt_prefix[nfproto], name);
@@ -251,6 +254,9 @@ struct xt_target *xt_request_find_target
{
struct xt_target *target;
+ if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN)
+ return ERR_PTR(-EINVAL);
+
target = xt_find_target(af, name, revision);
if (IS_ERR(target)) {
request_module("%st_%s", xt_prefix[af], name);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.15/net_sched-gen_estimator-fix-lockdep-splat.patch
queue-4.15/tun-fix-tun_napi_alloc_frags-frag-allocator.patch
queue-4.15/netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch
queue-4.15/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
This is a note to let you know that I've just added the patch titled
netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
to the 4.15-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:
netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
and it can be found in the queue-4.15 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 1a38956cce5eabd7b74f94bab70265e4df83165e Mon Sep 17 00:00:00 2001
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Tue, 30 Jan 2018 15:21:34 +0100
Subject: netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
From: Dmitry Vyukov <dvyukov(a)google.com>
commit 1a38956cce5eabd7b74f94bab70265e4df83165e upstream.
Commit 136e92bbec0a switched local_nodes from an array to a bitmask
but did not add proper bounds checks. As the result
clusterip_config_init_nodelist() can both over-read
ipt_clusterip_tgt_info.local_nodes and over-write
clusterip_config.local_nodes.
Add bounds checks for both.
Fixes: 136e92bbec0a ("[NETFILTER] CLUSTERIP: use a bitmap to store node responsibility data")
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/netfilter/ipt_CLUSTERIP.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -431,7 +431,7 @@ static int clusterip_tg_check(const stru
struct ipt_clusterip_tgt_info *cipinfo = par->targinfo;
const struct ipt_entry *e = par->entryinfo;
struct clusterip_config *config;
- int ret;
+ int ret, i;
if (par->nft_compat) {
pr_err("cannot use CLUSTERIP target from nftables compat\n");
@@ -450,8 +450,18 @@ static int clusterip_tg_check(const stru
pr_info("Please specify destination IP\n");
return -EINVAL;
}
-
- /* FIXME: further sanity checks */
+ if (cipinfo->num_local_nodes > ARRAY_SIZE(cipinfo->local_nodes)) {
+ pr_info("bad num_local_nodes %u\n", cipinfo->num_local_nodes);
+ return -EINVAL;
+ }
+ for (i = 0; i < cipinfo->num_local_nodes; i++) {
+ if (cipinfo->local_nodes[i] - 1 >=
+ sizeof(config->local_nodes) * 8) {
+ pr_info("bad local_nodes[%d] %u\n",
+ i, cipinfo->local_nodes[i]);
+ return -EINVAL;
+ }
+ }
config = clusterip_config_find_get(par->net, e->ip.dst.s_addr, 1);
if (!config) {
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-4.15/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
queue-4.15/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
queue-4.15/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
queue-4.15/kcov-detect-double-association-with-a-single-task.patch
This is a note to let you know that I've just added the patch titled
net_sched: gen_estimator: fix lockdep splat
to the 4.15-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:
net_sched-gen_estimator-fix-lockdep-splat.patch
and it can be found in the queue-4.15 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 40ca54e3a686f13117f3de0c443f8026dadf7c44 Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Sat, 27 Jan 2018 10:58:43 -0800
Subject: net_sched: gen_estimator: fix lockdep splat
From: Eric Dumazet <edumazet(a)google.com>
commit 40ca54e3a686f13117f3de0c443f8026dadf7c44 upstream.
syzbot reported a lockdep splat in gen_new_estimator() /
est_fetch_counters() when attempting to lock est->stats_lock.
Since est_fetch_counters() is called from BH context from timer
interrupt, we need to block BH as well when calling it from process
context.
Most qdiscs use per cpu counters and are immune to the problem,
but net/sched/act_api.c and net/netfilter/xt_RATEEST.c are using
a spinlock to protect their data. They both call gen_new_estimator()
while object is created and not yet alive, so this bug could
not trigger a deadlock, only a lockdep splat.
Fixes: 1c0d32fde5bd ("net_sched: gen_estimator: complete rewrite of rate estimators")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Acked-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/gen_estimator.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/net/core/gen_estimator.c
+++ b/net/core/gen_estimator.c
@@ -159,7 +159,11 @@ int gen_new_estimator(struct gnet_stats_
est->intvl_log = intvl_log;
est->cpu_bstats = cpu_bstats;
+ if (stats_lock)
+ local_bh_disable();
est_fetch_counters(est, &b);
+ if (stats_lock)
+ local_bh_enable();
est->last_bytes = b.bytes;
est->last_packets = b.packets;
old = rcu_dereference_protected(*rate_est, 1);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.15/net_sched-gen_estimator-fix-lockdep-splat.patch
queue-4.15/tun-fix-tun_napi_alloc_frags-frag-allocator.patch
queue-4.15/netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch
queue-4.15/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
This is a note to let you know that I've just added the patch titled
net: avoid skb_warn_bad_offload on IS_ERR
to the 4.15-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:
net-avoid-skb_warn_bad_offload-on-is_err.patch
and it can be found in the queue-4.15 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 8d74e9f88d65af8bb2e095aff506aa6eac755ada Mon Sep 17 00:00:00 2001
From: Willem de Bruijn <willemb(a)google.com>
Date: Tue, 12 Dec 2017 11:39:04 -0500
Subject: net: avoid skb_warn_bad_offload on IS_ERR
From: Willem de Bruijn <willemb(a)google.com>
commit 8d74e9f88d65af8bb2e095aff506aa6eac755ada upstream.
skb_warn_bad_offload warns when packets enter the GSO stack that
require skb_checksum_help or vice versa. Do not warn on arbitrary
bad packets. Packet sockets can craft many. Syzkaller was able to
demonstrate another one with eth_type games.
In particular, suppress the warning when segmentation returns an
error, which is for reasons other than checksum offload.
See also commit 36c92474498a ("net: WARN if skb_checksum_help() is
called on skb requiring segmentation") for context on this warning.
Signed-off-by: Willem de Bruijn <willemb(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2815,7 +2815,7 @@ struct sk_buff *__skb_gso_segment(struct
segs = skb_mac_gso_segment(skb, features);
- if (unlikely(skb_needs_check(skb, tx_path)))
+ if (unlikely(skb_needs_check(skb, tx_path) && !IS_ERR(segs)))
skb_warn_bad_offload(skb);
return segs;
Patches currently in stable-queue which might be from willemb(a)google.com are
queue-4.15/net-avoid-skb_warn_bad_offload-on-is_err.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: fix escape of guest dr6 to the host
to the 4.15-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-x86-fix-escape-of-guest-dr6-to-the-host.patch
and it can be found in the queue-4.15 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 efdab992813fb2ed825745625b83c05032e9cda2 Mon Sep 17 00:00:00 2001
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
Date: Wed, 13 Dec 2017 10:46:40 +0100
Subject: KVM: x86: fix escape of guest dr6 to the host
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
commit efdab992813fb2ed825745625b83c05032e9cda2 upstream.
syzkaller reported:
WARNING: CPU: 0 PID: 12927 at arch/x86/kernel/traps.c:780 do_debug+0x222/0x250
CPU: 0 PID: 12927 Comm: syz-executor Tainted: G OE 4.15.0-rc2+ #16
RIP: 0010:do_debug+0x222/0x250
Call Trace:
<#DB>
debug+0x3e/0x70
RIP: 0010:copy_user_enhanced_fast_string+0x10/0x20
</#DB>
_copy_from_user+0x5b/0x90
SyS_timer_create+0x33/0x80
entry_SYSCALL_64_fastpath+0x23/0x9a
The testcase sets a watchpoint (with perf_event_open) on a buffer that is
passed to timer_create() as the struct sigevent argument. In timer_create(),
copy_from_user()'s rep movsb triggers the BP. The testcase also sets
the debug registers for the guest.
However, KVM only restores host debug registers when the host has active
watchpoints, which triggers a race condition when running the testcase with
multiple threads. The guest's DR6.BS bit can escape to the host before
another thread invokes timer_create(), and do_debug() complains.
The fix is to respect do_debug()'s dr6 invariant when leaving KVM.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Cc: David Hildenbrand <david(a)redhat.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/x86.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2939,6 +2939,12 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *
pagefault_enable();
kvm_x86_ops->vcpu_put(vcpu);
vcpu->arch.last_host_tsc = rdtsc();
+ /*
+ * If userspace has set any breakpoints or watchpoints, dr6 is restored
+ * on every vmexit, but if not, we might have a stale dr6 from the
+ * guest. do_debug expects dr6 to be cleared after it runs, do the same.
+ */
+ set_debugreg(0, 6);
}
static int kvm_vcpu_ioctl_get_lapic(struct kvm_vcpu *vcpu,
Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are
queue-4.15/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
This is a note to let you know that I've just added the patch titled
kcov: detect double association with a single task
to the 4.15-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:
kcov-detect-double-association-with-a-single-task.patch
and it can be found in the queue-4.15 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 a77660d231f8b3d84fd23ed482e0964f7aa546d6 Mon Sep 17 00:00:00 2001
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Tue, 6 Feb 2018 15:40:28 -0800
Subject: kcov: detect double association with a single task
From: Dmitry Vyukov <dvyukov(a)google.com>
commit a77660d231f8b3d84fd23ed482e0964f7aa546d6 upstream.
Currently KCOV_ENABLE does not check if the current task is already
associated with another kcov descriptor. As the result it is possible
to associate a single task with more than one kcov descriptor, which
later leads to a memory leak of the old descriptor. This relation is
really meant to be one-to-one (task has only one back link).
Extend validation to detect such misuse.
Link: http://lkml.kernel.org/r/20180122082520.15716-1-dvyukov@google.com
Fixes: 5c9a8750a640 ("kernel: add kcov code coverage")
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Reported-by: Shankara Pailoor <sp3485(a)columbia.edu>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: syzbot <syzkaller(a)googlegroups.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>
---
kernel/kcov.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/kcov.c
+++ b/kernel/kcov.c
@@ -358,7 +358,8 @@ static int kcov_ioctl_locked(struct kcov
*/
if (kcov->mode != KCOV_MODE_INIT || !kcov->area)
return -EINVAL;
- if (kcov->t != NULL)
+ t = current;
+ if (kcov->t != NULL || t->kcov != NULL)
return -EBUSY;
if (arg == KCOV_TRACE_PC)
kcov->mode = KCOV_MODE_TRACE_PC;
@@ -370,7 +371,6 @@ static int kcov_ioctl_locked(struct kcov
#endif
else
return -EINVAL;
- t = current;
/* Cache in task struct for performance. */
t->kcov_size = kcov->size;
t->kcov_area = kcov->area;
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-4.15/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
queue-4.15/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
queue-4.15/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
queue-4.15/kcov-detect-double-association-with-a-single-task.patch
This is a note to let you know that I've just added the patch titled
blk_rq_map_user_iov: fix error override
to the 4.15-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_rq_map_user_iov-fix-error-override.patch
and it can be found in the queue-4.15 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 69e0927b3774563c19b5fb32e91d75edc147fb62 Mon Sep 17 00:00:00 2001
From: Douglas Gilbert <dgilbert(a)interlog.com>
Date: Sun, 14 Jan 2018 17:00:48 -0500
Subject: blk_rq_map_user_iov: fix error override
From: Douglas Gilbert <dgilbert(a)interlog.com>
commit 69e0927b3774563c19b5fb32e91d75edc147fb62 upstream.
During stress tests by syzkaller on the sg driver the block layer
infrequently returns EINVAL. Closer inspection shows the block
layer was trying to return ENOMEM (which is much more
understandable) but for some reason overroad that useful error.
Patch below does not show this (unchanged) line:
ret =__blk_rq_map_user_iov(rq, map_data, &i, gfp_mask, copy);
That 'ret' was being overridden when that function failed.
Signed-off-by: Douglas Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
block/blk-map.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/block/blk-map.c
+++ b/block/blk-map.c
@@ -119,7 +119,7 @@ int blk_rq_map_user_iov(struct request_q
unsigned long align = q->dma_pad_mask | queue_dma_alignment(q);
struct bio *bio = NULL;
struct iov_iter i;
- int ret;
+ int ret = -EINVAL;
if (!iter_is_iovec(iter))
goto fail;
@@ -148,7 +148,7 @@ unmap_rq:
__blk_rq_unmap_user(bio);
fail:
rq->bio = NULL;
- return -EINVAL;
+ return ret;
}
EXPORT_SYMBOL(blk_rq_map_user_iov);
Patches currently in stable-queue which might be from dgilbert(a)interlog.com are
queue-4.15/blk_rq_map_user_iov-fix-error-override.patch
This is a note to let you know that I've just added the patch titled
xfrm: check id proto in validate_tmpl()
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:
xfrm-check-id-proto-in-validate_tmpl.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 6a53b7593233ab9e4f96873ebacc0f653a55c3e1 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Mon, 27 Nov 2017 11:15:16 -0800
Subject: xfrm: check id proto in validate_tmpl()
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit 6a53b7593233ab9e4f96873ebacc0f653a55c3e1 upstream.
syzbot reported a kernel warning in xfrm_state_fini(), which
indicates that we have entries left in the list
net->xfrm.state_all whose proto is zero. And
xfrm_id_proto_match() doesn't consider them as a match with
IPSEC_PROTO_ANY in this case.
Proto with value 0 is probably not a valid value, at least
verify_newsa_info() doesn't consider it valid either.
This patch fixes it by checking the proto value in
validate_tmpl() and rejecting invalid ones, like what iproute2
does in xfrm_xfrmproto_getbyname().
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Cc: Steffen Klassert <steffen.klassert(a)secunet.com>
Cc: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_user.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1402,6 +1402,21 @@ static int validate_tmpl(int nr, struct
default:
return -EINVAL;
}
+
+ switch (ut[i].id.proto) {
+ case IPPROTO_AH:
+ case IPPROTO_ESP:
+ case IPPROTO_COMP:
+#if IS_ENABLED(CONFIG_IPV6)
+ case IPPROTO_ROUTING:
+ case IPPROTO_DSTOPTS:
+#endif
+ case IPSEC_PROTO_ANY:
+ break;
+ default:
+ return -EINVAL;
+ }
+
}
return 0;
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.4/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
queue-4.4/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
xfrm: Fix stack-out-of-bounds read on socket policy lookup.
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:
xfrm-fix-stack-out-of-bounds-read-on-socket-policy-lookup.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 ddc47e4404b58f03e98345398fb12d38fe291512 Mon Sep 17 00:00:00 2001
From: Steffen Klassert <steffen.klassert(a)secunet.com>
Date: Wed, 29 Nov 2017 06:53:55 +0100
Subject: xfrm: Fix stack-out-of-bounds read on socket policy lookup.
From: Steffen Klassert <steffen.klassert(a)secunet.com>
commit ddc47e4404b58f03e98345398fb12d38fe291512 upstream.
When we do tunnel or beet mode, we pass saddr and daddr from the
template to xfrm_state_find(), this is ok. On transport mode,
we pass the addresses from the flowi, assuming that the IP
addresses (and address family) don't change during transformation.
This assumption is wrong in the IPv4 mapped IPv6 case, packet
is IPv4 and template is IPv6.
Fix this by catching address family missmatches of the policy
and the flow already before we do the lookup.
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_policy.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1225,9 +1225,15 @@ static struct xfrm_policy *xfrm_sk_polic
read_lock_bh(&net->xfrm.xfrm_policy_lock);
pol = rcu_dereference(sk->sk_policy[dir]);
if (pol != NULL) {
- bool match = xfrm_selector_match(&pol->selector, fl, family);
+ bool match;
int err = 0;
+ if (pol->family != family) {
+ pol = NULL;
+ goto out;
+ }
+
+ match = xfrm_selector_match(&pol->selector, fl, family);
if (match) {
if ((sk->sk_mark & pol->mark.m) != pol->mark.v) {
pol = NULL;
Patches currently in stable-queue which might be from steffen.klassert(a)secunet.com are
queue-4.4/xfrm-fix-stack-out-of-bounds-read-on-socket-policy-lookup.patch
queue-4.4/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
staging: android: ion: Add __GFP_NOWARN for system contig heap
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:
staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.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 0c75f10312a35b149b2cebb1832316b35c2337ca Mon Sep 17 00:00:00 2001
From: Laura Abbott <labbott(a)redhat.com>
Date: Fri, 5 Jan 2018 11:14:08 -0800
Subject: staging: android: ion: Add __GFP_NOWARN for system contig heap
From: Laura Abbott <labbott(a)redhat.com>
commit 0c75f10312a35b149b2cebb1832316b35c2337ca upstream.
syzbot reported a warning from Ion:
WARNING: CPU: 1 PID: 3485 at mm/page_alloc.c:3926
...
__alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252
alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036
alloc_pages include/linux/gfp.h:492 [inline]
ion_system_contig_heap_allocate+0x40/0x2c0
drivers/staging/android/ion/ion_system_heap.c:374
ion_buffer_create drivers/staging/android/ion/ion.c:93 [inline]
ion_alloc+0x2c1/0x9e0 drivers/staging/android/ion/ion.c:420
ion_ioctl+0x26d/0x380 drivers/staging/android/ion/ion-ioctl.c:84
vfs_ioctl fs/ioctl.c:46 [inline]
do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
SYSC_ioctl fs/ioctl.c:701 [inline]
SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
This is a warning about attempting to allocate order > MAX_ORDER. This
is coming from a userspace Ion allocation request. Since userspace is
free to request however much memory it wants (and the kernel is free to
deny its allocation), silence the allocation attempt with __GFP_NOWARN
in case it fails.
Reported-by: syzbot+76e7efc4748495855a4d(a)syzkaller.appspotmail.com
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Laura Abbott <labbott(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ion/ion_system_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -336,7 +336,7 @@ static int ion_system_contig_heap_alloca
if (align > (PAGE_SIZE << order))
return -EINVAL;
- page = alloc_pages(low_order_gfp_flags, order);
+ page = alloc_pages(low_order_gfp_flags | __GFP_NOWARN, order);
if (!page)
return -ENOMEM;
Patches currently in stable-queue which might be from labbott(a)redhat.com are
queue-4.4/staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.patch
This is a note to let you know that I've just added the patch titled
selinux: skip bounded transition processing if the policy isn't loaded
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:
selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.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 4b14752ec4e0d87126e636384cf37c8dd9df157c Mon Sep 17 00:00:00 2001
From: Paul Moore <paul(a)paul-moore.com>
Date: Tue, 5 Dec 2017 17:17:43 -0500
Subject: selinux: skip bounded transition processing if the policy isn't loaded
From: Paul Moore <paul(a)paul-moore.com>
commit 4b14752ec4e0d87126e636384cf37c8dd9df157c upstream.
We can't do anything reasonable in security_bounded_transition() if we
don't have a policy loaded, and in fact we could run into problems
with some of the code inside expecting a policy. Fix these problems
like we do many others in security/selinux/ss/services.c by checking
to see if the policy is loaded (ss_initialized) and returning quickly
if it isn't.
Reported-by: syzbot <syzkaller-bugs(a)googlegroups.com>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Acked-by: Stephen Smalley <sds(a)tycho.nsa.gov>
Reviewed-by: James Morris <james.l.morris(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/selinux/ss/services.c | 3 +++
1 file changed, 3 insertions(+)
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -860,6 +860,9 @@ int security_bounded_transition(u32 old_
int index;
int rc;
+ if (!ss_initialized)
+ return 0;
+
read_lock(&policy_rwlock);
rc = -EINVAL;
Patches currently in stable-queue which might be from paul(a)paul-moore.com are
queue-4.4/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch
queue-4.4/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch
This is a note to let you know that I've just added the patch titled
selinux: ensure the context is NUL terminated in security_context_to_sid_core()
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:
selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.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 ef28df55ac27e1e5cd122e19fa311d886d47a756 Mon Sep 17 00:00:00 2001
From: Paul Moore <paul(a)paul-moore.com>
Date: Tue, 28 Nov 2017 18:51:12 -0500
Subject: selinux: ensure the context is NUL terminated in security_context_to_sid_core()
From: Paul Moore <paul(a)paul-moore.com>
commit ef28df55ac27e1e5cd122e19fa311d886d47a756 upstream.
The syzbot/syzkaller automated tests found a problem in
security_context_to_sid_core() during early boot (before we load the
SELinux policy) where we could potentially feed context strings without
NUL terminators into the strcmp() function.
We already guard against this during normal operation (after the SELinux
policy has been loaded) by making a copy of the context strings and
explicitly adding a NUL terminator to the end. The patch extends this
protection to the early boot case (no loaded policy) by moving the context
copy earlier in security_context_to_sid_core().
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Reviewed-By: William Roberts <william.c.roberts(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/selinux/ss/services.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -1406,27 +1406,25 @@ static int security_context_to_sid_core(
if (!scontext_len)
return -EINVAL;
+ /* Copy the string to allow changes and ensure a NUL terminator */
+ scontext2 = kmemdup_nul(scontext, scontext_len, gfp_flags);
+ if (!scontext2)
+ return -ENOMEM;
+
if (!ss_initialized) {
int i;
for (i = 1; i < SECINITSID_NUM; i++) {
- if (!strcmp(initial_sid_to_string[i], scontext)) {
+ if (!strcmp(initial_sid_to_string[i], scontext2)) {
*sid = i;
- return 0;
+ goto out;
}
}
*sid = SECINITSID_KERNEL;
- return 0;
+ goto out;
}
*sid = SECSID_NULL;
- /* Copy the string so that we can modify the copy as we parse it. */
- scontext2 = kmalloc(scontext_len + 1, gfp_flags);
- if (!scontext2)
- return -ENOMEM;
- memcpy(scontext2, scontext, scontext_len);
- scontext2[scontext_len] = 0;
-
if (force) {
/* Save another copy for storing in uninterpreted form */
rc = -ENOMEM;
Patches currently in stable-queue which might be from paul(a)paul-moore.com are
queue-4.4/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch
queue-4.4/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch
This is a note to let you know that I've just added the patch titled
Provide a function to create a NUL-terminated string from unterminated data
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:
provide-a-function-to-create-a-nul-terminated-string-from-unterminated-data.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 f35157417215ec138c920320c746fdb3e04ef1d5 Mon Sep 17 00:00:00 2001
From: David Howells <dhowells(a)redhat.com>
Date: Tue, 4 Jul 2017 17:25:02 +0100
Subject: Provide a function to create a NUL-terminated string from unterminated data
From: David Howells <dhowells(a)redhat.com>
commit f35157417215ec138c920320c746fdb3e04ef1d5 upstream.
Provide a function, kmemdup_nul(), that will create a NUL-terminated string
from an unterminated character array where the length is known in advance.
This is better than kstrndup() in situations where we already know the
string length as the strnlen() in kstrndup() is superfluous.
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/string.h | 1 +
mm/util.c | 24 ++++++++++++++++++++++++
2 files changed, 25 insertions(+)
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -122,6 +122,7 @@ extern char *kstrdup(const char *s, gfp_
extern const char *kstrdup_const(const char *s, gfp_t gfp);
extern char *kstrndup(const char *s, size_t len, gfp_t gfp);
extern void *kmemdup(const void *src, size_t len, gfp_t gfp);
+extern char *kmemdup_nul(const char *s, size_t len, gfp_t gfp);
extern char **argv_split(gfp_t gfp, const char *str, int *argcp);
extern void argv_free(char **argv);
--- a/mm/util.c
+++ b/mm/util.c
@@ -80,6 +80,8 @@ EXPORT_SYMBOL(kstrdup_const);
* @s: the string to duplicate
* @max: read at most @max chars from @s
* @gfp: the GFP mask used in the kmalloc() call when allocating memory
+ *
+ * Note: Use kmemdup_nul() instead if the size is known exactly.
*/
char *kstrndup(const char *s, size_t max, gfp_t gfp)
{
@@ -118,6 +120,28 @@ void *kmemdup(const void *src, size_t le
EXPORT_SYMBOL(kmemdup);
/**
+ * kmemdup_nul - Create a NUL-terminated string from unterminated data
+ * @s: The data to stringify
+ * @len: The size of the data
+ * @gfp: the GFP mask used in the kmalloc() call when allocating memory
+ */
+char *kmemdup_nul(const char *s, size_t len, gfp_t gfp)
+{
+ char *buf;
+
+ if (!s)
+ return NULL;
+
+ buf = kmalloc_track_caller(len + 1, gfp);
+ if (buf) {
+ memcpy(buf, s, len);
+ buf[len] = '\0';
+ }
+ return buf;
+}
+EXPORT_SYMBOL(kmemdup_nul);
+
+/**
* memdup_user - duplicate memory region from user space
*
* @src: source address in user space
Patches currently in stable-queue which might be from dhowells(a)redhat.com are
queue-4.4/provide-a-function-to-create-a-nul-terminated-string-from-unterminated-data.patch
This is a note to let you know that I've just added the patch titled
netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
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:
netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.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 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Mon, 5 Feb 2018 14:41:45 -0800
Subject: netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 upstream.
rateest_hash is supposed to be protected by xt_rateest_mutex,
and, as suggested by Eric, lookup and insert should be atomic,
so we should acquire the xt_rateest_mutex once for both.
So introduce a non-locking helper for internal use and keep the
locking one for external.
Reported-by: <syzbot+5cb189720978275e4c75(a)syzkaller.appspotmail.com>
Fixes: 5859034d7eb8 ("[NETFILTER]: x_tables: add RATEEST target")
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Reviewed-by: Florian Westphal <fw(a)strlen.de>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/xt_RATEEST.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
--- a/net/netfilter/xt_RATEEST.c
+++ b/net/netfilter/xt_RATEEST.c
@@ -40,23 +40,31 @@ static void xt_rateest_hash_insert(struc
hlist_add_head(&est->list, &rateest_hash[h]);
}
-struct xt_rateest *xt_rateest_lookup(const char *name)
+static struct xt_rateest *__xt_rateest_lookup(const char *name)
{
struct xt_rateest *est;
unsigned int h;
h = xt_rateest_hash(name);
- mutex_lock(&xt_rateest_mutex);
hlist_for_each_entry(est, &rateest_hash[h], list) {
if (strcmp(est->name, name) == 0) {
est->refcnt++;
- mutex_unlock(&xt_rateest_mutex);
return est;
}
}
- mutex_unlock(&xt_rateest_mutex);
+
return NULL;
}
+
+struct xt_rateest *xt_rateest_lookup(const char *name)
+{
+ struct xt_rateest *est;
+
+ mutex_lock(&xt_rateest_mutex);
+ est = __xt_rateest_lookup(name);
+ mutex_unlock(&xt_rateest_mutex);
+ return est;
+}
EXPORT_SYMBOL_GPL(xt_rateest_lookup);
void xt_rateest_put(struct xt_rateest *est)
@@ -104,8 +112,10 @@ static int xt_rateest_tg_checkentry(cons
rnd_inited = true;
}
- est = xt_rateest_lookup(info->name);
+ mutex_lock(&xt_rateest_mutex);
+ est = __xt_rateest_lookup(info->name);
if (est) {
+ mutex_unlock(&xt_rateest_mutex);
/*
* If estimator parameters are specified, they must match the
* existing estimator.
@@ -143,11 +153,13 @@ static int xt_rateest_tg_checkentry(cons
info->est = est;
xt_rateest_hash_insert(est);
+ mutex_unlock(&xt_rateest_mutex);
return 0;
err2:
kfree(est);
err1:
+ mutex_unlock(&xt_rateest_mutex);
return ret;
}
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.4/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
queue-4.4/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
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:
netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.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 da17c73b6eb74aad3c3c0654394635675b623b3e Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 24 Jan 2018 17:16:09 -0800
Subject: netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
From: Eric Dumazet <edumazet(a)google.com>
commit da17c73b6eb74aad3c3c0654394635675b623b3e upstream.
It looks like syzbot found its way into netfilter territory.
Issue here is that @name comes from user space and might
not be null terminated.
Out-of-bound reads happen, KASAN is not happy.
v2 added similar fix for xt_request_find_target(),
as Florian advised.
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Acked-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/x_tables.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -206,6 +206,9 @@ xt_request_find_match(uint8_t nfproto, c
{
struct xt_match *match;
+ if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN)
+ return ERR_PTR(-EINVAL);
+
match = xt_find_match(nfproto, name, revision);
if (IS_ERR(match)) {
request_module("%st_%s", xt_prefix[nfproto], name);
@@ -248,6 +251,9 @@ struct xt_target *xt_request_find_target
{
struct xt_target *target;
+ if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN)
+ return ERR_PTR(-EINVAL);
+
target = xt_find_target(af, name, revision);
if (IS_ERR(target)) {
request_module("%st_%s", xt_prefix[af], name);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.4/netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch
queue-4.4/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: fix int overflow in xt_alloc_table_info()
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:
netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.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 889c604fd0b5f6d3b8694ade229ee44124de1127 Mon Sep 17 00:00:00 2001
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Thu, 28 Dec 2017 09:48:54 +0100
Subject: netfilter: x_tables: fix int overflow in xt_alloc_table_info()
From: Dmitry Vyukov <dvyukov(a)google.com>
commit 889c604fd0b5f6d3b8694ade229ee44124de1127 upstream.
syzkaller triggered OOM kills by passing ipt_replace.size = -1
to IPT_SO_SET_REPLACE. The root cause is that SMP_ALIGN() in
xt_alloc_table_info() causes int overflow and the size check passes
when it should not. SMP_ALIGN() is no longer needed leftover.
Remove SMP_ALIGN() call in xt_alloc_table_info().
Reported-by: syzbot+4396883fa8c4f64e0175(a)syzkaller.appspotmail.com
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/x_tables.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -38,8 +38,6 @@ MODULE_LICENSE("GPL");
MODULE_AUTHOR("Harald Welte <laforge(a)netfilter.org>");
MODULE_DESCRIPTION("{ip,ip6,arp,eb}_tables backend module");
-#define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1))
-
struct compat_delta {
unsigned int offset; /* offset in kernel */
int delta; /* delta in 32bit user land */
@@ -954,7 +952,7 @@ struct xt_table_info *xt_alloc_table_inf
return NULL;
/* Pedantry: prevent them from hitting BUG() in vmalloc.c --RR */
- if ((SMP_ALIGN(size) >> PAGE_SHIFT) + 2 > totalram_pages)
+ if ((size >> PAGE_SHIFT) + 2 > totalram_pages)
return NULL;
if (sz <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER))
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-4.4/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
queue-4.4/blktrace-fix-unlocked-registration-of-tracepoints.patch
queue-4.4/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
queue-4.4/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
This is a note to let you know that I've just added the patch titled
netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
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:
netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.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 1a38956cce5eabd7b74f94bab70265e4df83165e Mon Sep 17 00:00:00 2001
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Tue, 30 Jan 2018 15:21:34 +0100
Subject: netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
From: Dmitry Vyukov <dvyukov(a)google.com>
commit 1a38956cce5eabd7b74f94bab70265e4df83165e upstream.
Commit 136e92bbec0a switched local_nodes from an array to a bitmask
but did not add proper bounds checks. As the result
clusterip_config_init_nodelist() can both over-read
ipt_clusterip_tgt_info.local_nodes and over-write
clusterip_config.local_nodes.
Add bounds checks for both.
Fixes: 136e92bbec0a ("[NETFILTER] CLUSTERIP: use a bitmap to store node responsibility data")
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/netfilter/ipt_CLUSTERIP.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -365,7 +365,7 @@ static int clusterip_tg_check(const stru
struct ipt_clusterip_tgt_info *cipinfo = par->targinfo;
const struct ipt_entry *e = par->entryinfo;
struct clusterip_config *config;
- int ret;
+ int ret, i;
if (par->nft_compat) {
pr_err("cannot use CLUSTERIP target from nftables compat\n");
@@ -384,8 +384,18 @@ static int clusterip_tg_check(const stru
pr_info("Please specify destination IP\n");
return -EINVAL;
}
-
- /* FIXME: further sanity checks */
+ if (cipinfo->num_local_nodes > ARRAY_SIZE(cipinfo->local_nodes)) {
+ pr_info("bad num_local_nodes %u\n", cipinfo->num_local_nodes);
+ return -EINVAL;
+ }
+ for (i = 0; i < cipinfo->num_local_nodes; i++) {
+ if (cipinfo->local_nodes[i] - 1 >=
+ sizeof(config->local_nodes) * 8) {
+ pr_info("bad local_nodes[%d] %u\n",
+ i, cipinfo->local_nodes[i]);
+ return -EINVAL;
+ }
+ }
config = clusterip_config_find_get(par->net, e->ip.dst.s_addr, 1);
if (!config) {
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-4.4/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
queue-4.4/blktrace-fix-unlocked-registration-of-tracepoints.patch
queue-4.4/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
queue-4.4/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
This is a note to let you know that I've just added the patch titled
net: avoid skb_warn_bad_offload on IS_ERR
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:
net-avoid-skb_warn_bad_offload-on-is_err.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 8d74e9f88d65af8bb2e095aff506aa6eac755ada Mon Sep 17 00:00:00 2001
From: Willem de Bruijn <willemb(a)google.com>
Date: Tue, 12 Dec 2017 11:39:04 -0500
Subject: net: avoid skb_warn_bad_offload on IS_ERR
From: Willem de Bruijn <willemb(a)google.com>
commit 8d74e9f88d65af8bb2e095aff506aa6eac755ada upstream.
skb_warn_bad_offload warns when packets enter the GSO stack that
require skb_checksum_help or vice versa. Do not warn on arbitrary
bad packets. Packet sockets can craft many. Syzkaller was able to
demonstrate another one with eth_type games.
In particular, suppress the warning when segmentation returns an
error, which is for reasons other than checksum offload.
See also commit 36c92474498a ("net: WARN if skb_checksum_help() is
called on skb requiring segmentation") for context on this warning.
Signed-off-by: Willem de Bruijn <willemb(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2598,7 +2598,7 @@ struct sk_buff *__skb_gso_segment(struct
segs = skb_mac_gso_segment(skb, features);
- if (unlikely(skb_needs_check(skb, tx_path)))
+ if (unlikely(skb_needs_check(skb, tx_path) && !IS_ERR(segs)))
skb_warn_bad_offload(skb);
return segs;
Patches currently in stable-queue which might be from willemb(a)google.com are
queue-4.4/net-avoid-skb_warn_bad_offload-on-is_err.patch
This is a note to let you know that I've just added the patch titled
drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all
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:
drm-require-__gfp_nofail-for-the-legacy-drm_modeset_lock_all.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 d18d1a5ac811d12f7ebc1129230312b5f2c50cb8 Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Tue, 31 Oct 2017 11:55:35 +0000
Subject: drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Chris Wilson <chris(a)chris-wilson.co.uk>
commit d18d1a5ac811d12f7ebc1129230312b5f2c50cb8 upstream.
To acquire all modeset locks requires a ww_ctx to be allocated. As this
is the legacy path and the allocation small, to reduce the changes
required (and complex untested error handling) to the legacy drivers, we
simply assume that the allocation succeeds. At present, it relies on the
too-small-to-fail rule, but syzbot found that by injecting a failure
here we would hit the WARN. Document that this allocation must succeed
with __GFP_NOFAIL.
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031115535.15166-1-chris@…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/drm_modeset_lock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -69,7 +69,7 @@ void drm_modeset_lock_all(struct drm_dev
struct drm_modeset_acquire_ctx *ctx;
int ret;
- ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL | __GFP_NOFAIL);
if (WARN_ON(!ctx))
return;
Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are
queue-4.4/drm-require-__gfp_nofail-for-the-legacy-drm_modeset_lock_all.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: fix escape of guest dr6 to the host
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:
kvm-x86-fix-escape-of-guest-dr6-to-the-host.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 efdab992813fb2ed825745625b83c05032e9cda2 Mon Sep 17 00:00:00 2001
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
Date: Wed, 13 Dec 2017 10:46:40 +0100
Subject: KVM: x86: fix escape of guest dr6 to the host
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
commit efdab992813fb2ed825745625b83c05032e9cda2 upstream.
syzkaller reported:
WARNING: CPU: 0 PID: 12927 at arch/x86/kernel/traps.c:780 do_debug+0x222/0x250
CPU: 0 PID: 12927 Comm: syz-executor Tainted: G OE 4.15.0-rc2+ #16
RIP: 0010:do_debug+0x222/0x250
Call Trace:
<#DB>
debug+0x3e/0x70
RIP: 0010:copy_user_enhanced_fast_string+0x10/0x20
</#DB>
_copy_from_user+0x5b/0x90
SyS_timer_create+0x33/0x80
entry_SYSCALL_64_fastpath+0x23/0x9a
The testcase sets a watchpoint (with perf_event_open) on a buffer that is
passed to timer_create() as the struct sigevent argument. In timer_create(),
copy_from_user()'s rep movsb triggers the BP. The testcase also sets
the debug registers for the guest.
However, KVM only restores host debug registers when the host has active
watchpoints, which triggers a race condition when running the testcase with
multiple threads. The guest's DR6.BS bit can escape to the host before
another thread invokes timer_create(), and do_debug() complains.
The fix is to respect do_debug()'s dr6 invariant when leaving KVM.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Cc: David Hildenbrand <david(a)redhat.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/x86.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2755,6 +2755,12 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *
kvm_x86_ops->vcpu_put(vcpu);
kvm_put_guest_fpu(vcpu);
vcpu->arch.last_host_tsc = rdtsc();
+ /*
+ * If userspace has set any breakpoints or watchpoints, dr6 is restored
+ * on every vmexit, but if not, we might have a stale dr6 from the
+ * guest. do_debug expects dr6 to be cleared after it runs, do the same.
+ */
+ set_debugreg(0, 6);
}
static int kvm_vcpu_ioctl_get_lapic(struct kvm_vcpu *vcpu,
Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are
queue-4.4/kvm-x86-fix-escape-of-guest-dr6-to-the-host.patch
This is a note to let you know that I've just added the patch titled
cfg80211: check dev_set_name() return value
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:
cfg80211-check-dev_set_name-return-value.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 59b179b48ce2a6076448a44531242ac2b3f6cef2 Mon Sep 17 00:00:00 2001
From: Johannes Berg <johannes.berg(a)intel.com>
Date: Mon, 15 Jan 2018 09:58:27 +0100
Subject: cfg80211: check dev_set_name() return value
From: Johannes Berg <johannes.berg(a)intel.com>
commit 59b179b48ce2a6076448a44531242ac2b3f6cef2 upstream.
syzbot reported a warning from rfkill_alloc(), and after a while
I think that the reason is that it was doing fault injection and
the dev_set_name() failed, leaving the name NULL, and we didn't
check the return value and got to rfkill_alloc() with a NULL name.
Since we really don't want a NULL name, we ought to check the
return value.
Fixes: fb28ad35906a ("net: struct device - replace bus_id with dev_name(), dev_set_name()")
Reported-by: syzbot+1ddfb3357e1d7bb5b5d3(a)syzkaller.appspotmail.com
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/wireless/core.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -390,6 +390,8 @@ struct wiphy *wiphy_new_nm(const struct
if (rv)
goto use_default_name;
} else {
+ int rv;
+
use_default_name:
/* NOTE: This is *probably* safe w/out holding rtnl because of
* the restrictions on phy names. Probably this call could
@@ -397,7 +399,11 @@ use_default_name:
* phyX. But, might should add some locking and check return
* value, and use a different name if this one exists?
*/
- dev_set_name(&rdev->wiphy.dev, PHY_NAME "%d", rdev->wiphy_idx);
+ rv = dev_set_name(&rdev->wiphy.dev, PHY_NAME "%d", rdev->wiphy_idx);
+ if (rv < 0) {
+ kfree(rdev);
+ return NULL;
+ }
}
INIT_LIST_HEAD(&rdev->wdev_list);
Patches currently in stable-queue which might be from johannes.berg(a)intel.com are
queue-4.4/cfg80211-check-dev_set_name-return-value.patch
This is a note to let you know that I've just added the patch titled
xfrm: check id proto in validate_tmpl()
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-check-id-proto-in-validate_tmpl.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 6a53b7593233ab9e4f96873ebacc0f653a55c3e1 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Mon, 27 Nov 2017 11:15:16 -0800
Subject: xfrm: check id proto in validate_tmpl()
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit 6a53b7593233ab9e4f96873ebacc0f653a55c3e1 upstream.
syzbot reported a kernel warning in xfrm_state_fini(), which
indicates that we have entries left in the list
net->xfrm.state_all whose proto is zero. And
xfrm_id_proto_match() doesn't consider them as a match with
IPSEC_PROTO_ANY in this case.
Proto with value 0 is probably not a valid value, at least
verify_newsa_info() doesn't consider it valid either.
This patch fixes it by checking the proto value in
validate_tmpl() and rejecting invalid ones, like what iproute2
does in xfrm_xfrmproto_getbyname().
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Cc: Steffen Klassert <steffen.klassert(a)secunet.com>
Cc: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_user.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1375,6 +1375,21 @@ static int validate_tmpl(int nr, struct
default:
return -EINVAL;
}
+
+ switch (ut[i].id.proto) {
+ case IPPROTO_AH:
+ case IPPROTO_ESP:
+ case IPPROTO_COMP:
+#if IS_ENABLED(CONFIG_IPV6)
+ case IPPROTO_ROUTING:
+ case IPPROTO_DSTOPTS:
+#endif
+ case IPSEC_PROTO_ANY:
+ break;
+ default:
+ return -EINVAL;
+ }
+
}
return 0;
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-3.18/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
queue-3.18/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
staging: android: ion: Add __GFP_NOWARN for system contig heap
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:
staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.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 0c75f10312a35b149b2cebb1832316b35c2337ca Mon Sep 17 00:00:00 2001
From: Laura Abbott <labbott(a)redhat.com>
Date: Fri, 5 Jan 2018 11:14:08 -0800
Subject: staging: android: ion: Add __GFP_NOWARN for system contig heap
From: Laura Abbott <labbott(a)redhat.com>
commit 0c75f10312a35b149b2cebb1832316b35c2337ca upstream.
syzbot reported a warning from Ion:
WARNING: CPU: 1 PID: 3485 at mm/page_alloc.c:3926
...
__alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252
alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036
alloc_pages include/linux/gfp.h:492 [inline]
ion_system_contig_heap_allocate+0x40/0x2c0
drivers/staging/android/ion/ion_system_heap.c:374
ion_buffer_create drivers/staging/android/ion/ion.c:93 [inline]
ion_alloc+0x2c1/0x9e0 drivers/staging/android/ion/ion.c:420
ion_ioctl+0x26d/0x380 drivers/staging/android/ion/ion-ioctl.c:84
vfs_ioctl fs/ioctl.c:46 [inline]
do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
SYSC_ioctl fs/ioctl.c:701 [inline]
SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
This is a warning about attempting to allocate order > MAX_ORDER. This
is coming from a userspace Ion allocation request. Since userspace is
free to request however much memory it wants (and the kernel is free to
deny its allocation), silence the allocation attempt with __GFP_NOWARN
in case it fails.
Reported-by: syzbot+76e7efc4748495855a4d(a)syzkaller.appspotmail.com
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Laura Abbott <labbott(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ion/ion_system_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -321,7 +321,7 @@ static int ion_system_contig_heap_alloca
if (align > (PAGE_SIZE << order))
return -EINVAL;
- page = alloc_pages(low_order_gfp_flags, order);
+ page = alloc_pages(low_order_gfp_flags | __GFP_NOWARN, order);
if (!page)
return -ENOMEM;
Patches currently in stable-queue which might be from labbott(a)redhat.com are
queue-3.18/staging-android-ion-add-__gfp_nowarn-for-system-contig-heap.patch
This is a note to let you know that I've just added the patch titled
selinux: skip bounded transition processing if the policy isn't loaded
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:
selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.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 4b14752ec4e0d87126e636384cf37c8dd9df157c Mon Sep 17 00:00:00 2001
From: Paul Moore <paul(a)paul-moore.com>
Date: Tue, 5 Dec 2017 17:17:43 -0500
Subject: selinux: skip bounded transition processing if the policy isn't loaded
From: Paul Moore <paul(a)paul-moore.com>
commit 4b14752ec4e0d87126e636384cf37c8dd9df157c upstream.
We can't do anything reasonable in security_bounded_transition() if we
don't have a policy loaded, and in fact we could run into problems
with some of the code inside expecting a policy. Fix these problems
like we do many others in security/selinux/ss/services.c by checking
to see if the policy is loaded (ss_initialized) and returning quickly
if it isn't.
Reported-by: syzbot <syzkaller-bugs(a)googlegroups.com>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Acked-by: Stephen Smalley <sds(a)tycho.nsa.gov>
Reviewed-by: James Morris <james.l.morris(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/selinux/ss/services.c | 3 +++
1 file changed, 3 insertions(+)
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -823,6 +823,9 @@ int security_bounded_transition(u32 old_
int index;
int rc;
+ if (!ss_initialized)
+ return 0;
+
read_lock(&policy_rwlock);
rc = -EINVAL;
Patches currently in stable-queue which might be from paul(a)paul-moore.com are
queue-3.18/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch
queue-3.18/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch
This is a note to let you know that I've just added the patch titled
selinux: ensure the context is NUL terminated in security_context_to_sid_core()
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:
selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.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 ef28df55ac27e1e5cd122e19fa311d886d47a756 Mon Sep 17 00:00:00 2001
From: Paul Moore <paul(a)paul-moore.com>
Date: Tue, 28 Nov 2017 18:51:12 -0500
Subject: selinux: ensure the context is NUL terminated in security_context_to_sid_core()
From: Paul Moore <paul(a)paul-moore.com>
commit ef28df55ac27e1e5cd122e19fa311d886d47a756 upstream.
The syzbot/syzkaller automated tests found a problem in
security_context_to_sid_core() during early boot (before we load the
SELinux policy) where we could potentially feed context strings without
NUL terminators into the strcmp() function.
We already guard against this during normal operation (after the SELinux
policy has been loaded) by making a copy of the context strings and
explicitly adding a NUL terminator to the end. The patch extends this
protection to the early boot case (no loaded policy) by moving the context
copy earlier in security_context_to_sid_core().
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Paul Moore <paul(a)paul-moore.com>
Reviewed-By: William Roberts <william.c.roberts(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/selinux/ss/services.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -1239,27 +1239,25 @@ static int security_context_to_sid_core(
if (!scontext_len)
return -EINVAL;
+ /* Copy the string to allow changes and ensure a NUL terminator */
+ scontext2 = kmemdup_nul(scontext, scontext_len, gfp_flags);
+ if (!scontext2)
+ return -ENOMEM;
+
if (!ss_initialized) {
int i;
for (i = 1; i < SECINITSID_NUM; i++) {
- if (!strcmp(initial_sid_to_string[i], scontext)) {
+ if (!strcmp(initial_sid_to_string[i], scontext2)) {
*sid = i;
- return 0;
+ goto out;
}
}
*sid = SECINITSID_KERNEL;
- return 0;
+ goto out;
}
*sid = SECSID_NULL;
- /* Copy the string so that we can modify the copy as we parse it. */
- scontext2 = kmalloc(scontext_len + 1, gfp_flags);
- if (!scontext2)
- return -ENOMEM;
- memcpy(scontext2, scontext, scontext_len);
- scontext2[scontext_len] = 0;
-
if (force) {
/* Save another copy for storing in uninterpreted form */
rc = -ENOMEM;
Patches currently in stable-queue which might be from paul(a)paul-moore.com are
queue-3.18/selinux-skip-bounded-transition-processing-if-the-policy-isn-t-loaded.patch
queue-3.18/selinux-ensure-the-context-is-nul-terminated-in-security_context_to_sid_core.patch
This is a note to let you know that I've just added the patch titled
Provide a function to create a NUL-terminated string from unterminated 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:
provide-a-function-to-create-a-nul-terminated-string-from-unterminated-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 f35157417215ec138c920320c746fdb3e04ef1d5 Mon Sep 17 00:00:00 2001
From: David Howells <dhowells(a)redhat.com>
Date: Tue, 4 Jul 2017 17:25:02 +0100
Subject: Provide a function to create a NUL-terminated string from unterminated data
From: David Howells <dhowells(a)redhat.com>
commit f35157417215ec138c920320c746fdb3e04ef1d5 upstream.
Provide a function, kmemdup_nul(), that will create a NUL-terminated string
from an unterminated character array where the length is known in advance.
This is better than kstrndup() in situations where we already know the
string length as the strnlen() in kstrndup() is superfluous.
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/string.h | 1 +
mm/util.c | 24 ++++++++++++++++++++++++
2 files changed, 25 insertions(+)
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -121,6 +121,7 @@ void *memchr_inv(const void *s, int c, s
extern char *kstrdup(const char *s, gfp_t gfp);
extern char *kstrndup(const char *s, size_t len, gfp_t gfp);
extern void *kmemdup(const void *src, size_t len, gfp_t gfp);
+extern char *kmemdup_nul(const char *s, size_t len, gfp_t gfp);
extern char **argv_split(gfp_t gfp, const char *str, int *argcp);
extern void argv_free(char **argv);
--- a/mm/util.c
+++ b/mm/util.c
@@ -42,6 +42,8 @@ EXPORT_SYMBOL(kstrdup);
* @s: the string to duplicate
* @max: read at most @max chars from @s
* @gfp: the GFP mask used in the kmalloc() call when allocating memory
+ *
+ * Note: Use kmemdup_nul() instead if the size is known exactly.
*/
char *kstrndup(const char *s, size_t max, gfp_t gfp)
{
@@ -80,6 +82,28 @@ void *kmemdup(const void *src, size_t le
EXPORT_SYMBOL(kmemdup);
/**
+ * kmemdup_nul - Create a NUL-terminated string from unterminated data
+ * @s: The data to stringify
+ * @len: The size of the data
+ * @gfp: the GFP mask used in the kmalloc() call when allocating memory
+ */
+char *kmemdup_nul(const char *s, size_t len, gfp_t gfp)
+{
+ char *buf;
+
+ if (!s)
+ return NULL;
+
+ buf = kmalloc_track_caller(len + 1, gfp);
+ if (buf) {
+ memcpy(buf, s, len);
+ buf[len] = '\0';
+ }
+ return buf;
+}
+EXPORT_SYMBOL(kmemdup_nul);
+
+/**
* memdup_user - duplicate memory region from user space
*
* @src: source address in user space
Patches currently in stable-queue which might be from dhowells(a)redhat.com are
queue-3.18/provide-a-function-to-create-a-nul-terminated-string-from-unterminated-data.patch
This is a note to let you know that I've just added the patch titled
netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
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:
netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.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 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Mon, 5 Feb 2018 14:41:45 -0800
Subject: netfilter: xt_RATEEST: acquire xt_rateest_mutex for hash insert
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit 7dc68e98757a8eccf8ca7a53a29b896f1eef1f76 upstream.
rateest_hash is supposed to be protected by xt_rateest_mutex,
and, as suggested by Eric, lookup and insert should be atomic,
so we should acquire the xt_rateest_mutex once for both.
So introduce a non-locking helper for internal use and keep the
locking one for external.
Reported-by: <syzbot+5cb189720978275e4c75(a)syzkaller.appspotmail.com>
Fixes: 5859034d7eb8 ("[NETFILTER]: x_tables: add RATEEST target")
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Reviewed-by: Florian Westphal <fw(a)strlen.de>
Reviewed-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/xt_RATEEST.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
--- a/net/netfilter/xt_RATEEST.c
+++ b/net/netfilter/xt_RATEEST.c
@@ -40,23 +40,31 @@ static void xt_rateest_hash_insert(struc
hlist_add_head(&est->list, &rateest_hash[h]);
}
-struct xt_rateest *xt_rateest_lookup(const char *name)
+static struct xt_rateest *__xt_rateest_lookup(const char *name)
{
struct xt_rateest *est;
unsigned int h;
h = xt_rateest_hash(name);
- mutex_lock(&xt_rateest_mutex);
hlist_for_each_entry(est, &rateest_hash[h], list) {
if (strcmp(est->name, name) == 0) {
est->refcnt++;
- mutex_unlock(&xt_rateest_mutex);
return est;
}
}
- mutex_unlock(&xt_rateest_mutex);
+
return NULL;
}
+
+struct xt_rateest *xt_rateest_lookup(const char *name)
+{
+ struct xt_rateest *est;
+
+ mutex_lock(&xt_rateest_mutex);
+ est = __xt_rateest_lookup(name);
+ mutex_unlock(&xt_rateest_mutex);
+ return est;
+}
EXPORT_SYMBOL_GPL(xt_rateest_lookup);
void xt_rateest_put(struct xt_rateest *est)
@@ -104,8 +112,10 @@ static int xt_rateest_tg_checkentry(cons
rnd_inited = true;
}
- est = xt_rateest_lookup(info->name);
+ mutex_lock(&xt_rateest_mutex);
+ est = __xt_rateest_lookup(info->name);
if (est) {
+ mutex_unlock(&xt_rateest_mutex);
/*
* If estimator parameters are specified, they must match the
* existing estimator.
@@ -143,11 +153,13 @@ static int xt_rateest_tg_checkentry(cons
info->est = est;
xt_rateest_hash_insert(est);
+ mutex_unlock(&xt_rateest_mutex);
return 0;
err2:
kfree(est);
err1:
+ mutex_unlock(&xt_rateest_mutex);
return ret;
}
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-3.18/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
queue-3.18/xfrm-check-id-proto-in-validate_tmpl.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: fix int overflow in xt_alloc_table_info()
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:
netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.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 889c604fd0b5f6d3b8694ade229ee44124de1127 Mon Sep 17 00:00:00 2001
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Thu, 28 Dec 2017 09:48:54 +0100
Subject: netfilter: x_tables: fix int overflow in xt_alloc_table_info()
From: Dmitry Vyukov <dvyukov(a)google.com>
commit 889c604fd0b5f6d3b8694ade229ee44124de1127 upstream.
syzkaller triggered OOM kills by passing ipt_replace.size = -1
to IPT_SO_SET_REPLACE. The root cause is that SMP_ALIGN() in
xt_alloc_table_info() causes int overflow and the size check passes
when it should not. SMP_ALIGN() is no longer needed leftover.
Remove SMP_ALIGN() call in xt_alloc_table_info().
Reported-by: syzbot+4396883fa8c4f64e0175(a)syzkaller.appspotmail.com
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/x_tables.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -38,8 +38,6 @@ MODULE_LICENSE("GPL");
MODULE_AUTHOR("Harald Welte <laforge(a)netfilter.org>");
MODULE_DESCRIPTION("{ip,ip6,arp,eb}_tables backend module");
-#define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1))
-
struct compat_delta {
unsigned int offset; /* offset in kernel */
int delta; /* delta in 32bit user land */
@@ -951,7 +949,7 @@ struct xt_table_info *xt_alloc_table_inf
int cpu;
/* Pedantry: prevent them from hitting BUG() in vmalloc.c --RR */
- if ((SMP_ALIGN(size) >> PAGE_SHIFT) + 2 > totalram_pages)
+ if ((size >> PAGE_SHIFT) + 2 > totalram_pages)
return NULL;
newinfo = kzalloc(XT_TABLE_INFO_SZ, GFP_KERNEL);
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-3.18/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
queue-3.18/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
This is a note to let you know that I've just added the patch titled
netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
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:
netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.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 da17c73b6eb74aad3c3c0654394635675b623b3e Mon Sep 17 00:00:00 2001
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 24 Jan 2018 17:16:09 -0800
Subject: netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_{match|target}
From: Eric Dumazet <edumazet(a)google.com>
commit da17c73b6eb74aad3c3c0654394635675b623b3e upstream.
It looks like syzbot found its way into netfilter territory.
Issue here is that @name comes from user space and might
not be null terminated.
Out-of-bound reads happen, KASAN is not happy.
v2 added similar fix for xt_request_find_target(),
as Florian advised.
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Acked-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/x_tables.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -209,6 +209,9 @@ xt_request_find_match(uint8_t nfproto, c
{
struct xt_match *match;
+ if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN)
+ return ERR_PTR(-EINVAL);
+
match = xt_find_match(nfproto, name, revision);
if (IS_ERR(match)) {
request_module("%st_%s", xt_prefix[nfproto], name);
@@ -251,6 +254,9 @@ struct xt_target *xt_request_find_target
{
struct xt_target *target;
+ if (strnlen(name, XT_EXTENSION_MAXNAMELEN) == XT_EXTENSION_MAXNAMELEN)
+ return ERR_PTR(-EINVAL);
+
target = xt_find_target(af, name, revision);
if (IS_ERR(target)) {
request_module("%st_%s", xt_prefix[af], name);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-3.18/netfilter-x_tables-avoid-out-of-bounds-reads-in-xt_request_find_-match-target.patch
queue-3.18/netfilter-xt_rateest-acquire-xt_rateest_mutex-for-hash-insert.patch
This is a note to let you know that I've just added the patch titled
netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
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:
netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.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 1a38956cce5eabd7b74f94bab70265e4df83165e Mon Sep 17 00:00:00 2001
From: Dmitry Vyukov <dvyukov(a)google.com>
Date: Tue, 30 Jan 2018 15:21:34 +0100
Subject: netfilter: ipt_CLUSTERIP: fix out-of-bounds accesses in clusterip_tg_check()
From: Dmitry Vyukov <dvyukov(a)google.com>
commit 1a38956cce5eabd7b74f94bab70265e4df83165e upstream.
Commit 136e92bbec0a switched local_nodes from an array to a bitmask
but did not add proper bounds checks. As the result
clusterip_config_init_nodelist() can both over-read
ipt_clusterip_tgt_info.local_nodes and over-write
clusterip_config.local_nodes.
Add bounds checks for both.
Fixes: 136e92bbec0a ("[NETFILTER] CLUSTERIP: use a bitmap to store node responsibility data")
Signed-off-by: Dmitry Vyukov <dvyukov(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/netfilter/ipt_CLUSTERIP.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -365,7 +365,7 @@ static int clusterip_tg_check(const stru
struct ipt_clusterip_tgt_info *cipinfo = par->targinfo;
const struct ipt_entry *e = par->entryinfo;
struct clusterip_config *config;
- int ret;
+ int ret, i;
if (cipinfo->hash_mode != CLUSTERIP_HASHMODE_SIP &&
cipinfo->hash_mode != CLUSTERIP_HASHMODE_SIP_SPT &&
@@ -379,8 +379,18 @@ static int clusterip_tg_check(const stru
pr_info("Please specify destination IP\n");
return -EINVAL;
}
-
- /* FIXME: further sanity checks */
+ if (cipinfo->num_local_nodes > ARRAY_SIZE(cipinfo->local_nodes)) {
+ pr_info("bad num_local_nodes %u\n", cipinfo->num_local_nodes);
+ return -EINVAL;
+ }
+ for (i = 0; i < cipinfo->num_local_nodes; i++) {
+ if (cipinfo->local_nodes[i] - 1 >=
+ sizeof(config->local_nodes) * 8) {
+ pr_info("bad local_nodes[%d] %u\n",
+ i, cipinfo->local_nodes[i]);
+ return -EINVAL;
+ }
+ }
config = clusterip_config_find_get(par->net, e->ip.dst.s_addr, 1);
if (!config) {
Patches currently in stable-queue which might be from dvyukov(a)google.com are
queue-3.18/netfilter-x_tables-fix-int-overflow-in-xt_alloc_table_info.patch
queue-3.18/netfilter-ipt_clusterip-fix-out-of-bounds-accesses-in-clusterip_tg_check.patch
This is a note to let you know that I've just added the patch titled
net: avoid skb_warn_bad_offload on IS_ERR
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:
net-avoid-skb_warn_bad_offload-on-is_err.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 8d74e9f88d65af8bb2e095aff506aa6eac755ada Mon Sep 17 00:00:00 2001
From: Willem de Bruijn <willemb(a)google.com>
Date: Tue, 12 Dec 2017 11:39:04 -0500
Subject: net: avoid skb_warn_bad_offload on IS_ERR
From: Willem de Bruijn <willemb(a)google.com>
commit 8d74e9f88d65af8bb2e095aff506aa6eac755ada upstream.
skb_warn_bad_offload warns when packets enter the GSO stack that
require skb_checksum_help or vice versa. Do not warn on arbitrary
bad packets. Packet sockets can craft many. Syzkaller was able to
demonstrate another one with eth_type games.
In particular, suppress the warning when segmentation returns an
error, which is for reasons other than checksum offload.
See also commit 36c92474498a ("net: WARN if skb_checksum_help() is
called on skb requiring segmentation") for context on this warning.
Signed-off-by: Willem de Bruijn <willemb(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2478,7 +2478,7 @@ struct sk_buff *__skb_gso_segment(struct
segs = skb_mac_gso_segment(skb, features);
- if (unlikely(skb_needs_check(skb, tx_path)))
+ if (unlikely(skb_needs_check(skb, tx_path) && !IS_ERR(segs)))
skb_warn_bad_offload(skb);
return segs;
Patches currently in stable-queue which might be from willemb(a)google.com are
queue-3.18/net-avoid-skb_warn_bad_offload-on-is_err.patch
A section type mismatch warning shows up when building with LTO,
since orion_ge00_mvmdio_bus_name was put in __initconst but not marked
const itself:
include/linux/of.h: In function 'spear_setup_of_timer':
arch/arm/mach-spear/time.c:207:34: error: 'timer_of_match' causes a section type conflict with 'orion_ge00_mvmdio_bus_name'
static const struct of_device_id timer_of_match[] __initconst = {
^
arch/arm/plat-orion/common.c:475:32: note: 'orion_ge00_mvmdio_bus_name' was declared here
static __initconst const char *orion_ge00_mvmdio_bus_name = "orion-mii";
^
As pointed out by Andrew Lunn, it should in fact be 'const' but not
'__initconst' because the string is never copied but may be accessed
after the init sections are freed. To fix that, I get rid of the
extra symbol and rewrite the initialization in a simpler way that
assigns both the bus_id and modalias statically.
I spotted another theoretical bug in the same place, where d->netdev[i]
may be an out of bounds access, this can be fixed by moving the device
assignment into the loop.
Cc: stable(a)vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
v2: complete rewrite
---
arch/arm/plat-orion/common.c | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index aff6994950ba..a2399fd66e97 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -472,28 +472,27 @@ void __init orion_ge11_init(struct mv643xx_eth_platform_data *eth_data,
/*****************************************************************************
* Ethernet switch
****************************************************************************/
-static __initconst const char *orion_ge00_mvmdio_bus_name = "orion-mii";
-static __initdata struct mdio_board_info
- orion_ge00_switch_board_info;
+static __initdata struct mdio_board_info orion_ge00_switch_board_info = {
+ .bus_id = "orion-mii",
+ .modalias = "mv88e6085",
+};
void __init orion_ge00_switch_init(struct dsa_chip_data *d)
{
- struct mdio_board_info *bd;
unsigned int i;
if (!IS_BUILTIN(CONFIG_PHYLIB))
return;
- for (i = 0; i < ARRAY_SIZE(d->port_names); i++)
- if (!strcmp(d->port_names[i], "cpu"))
+ for (i = 0; i < ARRAY_SIZE(d->port_names); i++) {
+ if (!strcmp(d->port_names[i], "cpu")) {
+ d->netdev[i] = &orion_ge00.dev;
break;
+ }
+ }
- bd = &orion_ge00_switch_board_info;
- bd->bus_id = orion_ge00_mvmdio_bus_name;
- bd->mdio_addr = d->sw_addr;
- d->netdev[i] = &orion_ge00.dev;
- strcpy(bd->modalias, "mv88e6085");
- bd->platform_data = d;
+ orion_ge00_switch_board_info.mdio_addr = d->sw_addr;
+ orion_ge00_switch_board_info.platform_data = d;
mdiobus_register_board_info(&orion_ge00_switch_board_info, 1);
}
--
2.9.0
gcc-8 has a new warning that detects overlapping input and output arguments
in memcpy(). It triggers for sit_init_net() calling ipip6_tunnel_clone_6rd(),
which is actually correct:
net/ipv6/sit.c: In function 'sit_init_net':
net/ipv6/sit.c:192:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
The problem here is that the logic detecting the memcpy() arguments finds them
to be the same, but the conditional that tests for the input and output of
ipip6_tunnel_clone_6rd() to be identical is not a compile-time constant.
We know that netdev_priv(t->dev) is the same as t for a tunnel device,
and comparing "dev" directly here lets the compiler figure out as well
that 'dev == sitn->fb_tunnel_dev' when called from sit_init_net(), so
it no longer warns.
This code is old, so Cc stable to make sure that we don't get the warning
for older kernels built with new gcc.
Cc: stable(a)vger.kernel.org
Cc: Martin Sebor <msebor(a)gmail.com>
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83456
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
net/ipv6/sit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 3873d3877135..3a1775a62973 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -182,7 +182,7 @@ static void ipip6_tunnel_clone_6rd(struct net_device *dev, struct sit_net *sitn)
#ifdef CONFIG_IPV6_SIT_6RD
struct ip_tunnel *t = netdev_priv(dev);
- if (t->dev == sitn->fb_tunnel_dev) {
+ if (dev == sitn->fb_tunnel_dev) {
ipv6_addr_set(&t->ip6rd.prefix, htonl(0x20020000), 0, 0, 0);
t->ip6rd.relay_prefix = 0;
t->ip6rd.prefixlen = 16;
--
2.9.0
This is the start of the stable review cycle for the 4.4.117 release.
There are 33 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 Fri Feb 23 12:43:54 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.117-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.4.117-rc1
Arnd Bergmann <arnd(a)arndb.de>
media: r820t: fix r820t_write_reg for KASAN
Arnd Bergmann <arnd(a)arndb.de>
ARM: dts: s5pv210: add interrupt-parent for ohci
Arnd Bergmann <arnd(a)arndb.de>
ARM: pxa/tosa-bt: add MODULE_LICENSE tag
Linus Torvalds <torvalds(a)linux-foundation.org>
vfs: don't do RCU lookup of empty pathnames
Arnd Bergmann <arnd(a)arndb.de>
x86: fix build warnign with 32-bit PAE
NeilBrown <neilb(a)suse.com>
dm: correctly handle chained bios in dec_pending()
Mikulas Patocka <mpatocka(a)redhat.com>
mvpp2: fix multicast address filter
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Fix racy pool initializations
Lassi Ylikojola <lassi.ylikojola(a)gmail.com>
ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204
Jan-Marek Glogowski <glogow(a)fbihome.de>
ALSA: hda/realtek: PCI quirk for Fujitsu U7x7
Kirill Marinushkin <k.marinushkin(a)gmail.com>
ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute
Hui Wang <hui.wang(a)canonical.com>
ALSA: hda - Fix headset mic detection problem for two Dell machines
Liu Bo <bo.li.liu(a)oracle.com>
Btrfs: fix unexpected -EEXIST when creating new inode
Liu Bo <bo.li.liu(a)oracle.com>
Btrfs: fix crash due to not cleaning up tree log block's dirty bits
Liu Bo <bo.li.liu(a)oracle.com>
Btrfs: fix deadlock in run_delalloc_nocow
Larry Finger <Larry.Finger(a)lwfinger.net>
rtlwifi: rtl8821ae: Fix connection lost problem correctly
Nicolas Pitre <nicolas.pitre(a)linaro.org>
console/dummy: leave .con_font_get set to NULL
Johan Hovold <johan(a)kernel.org>
video: fbdev: atmel_lcdfb: fix display-timings lookup
Arnd Bergmann <arnd(a)arndb.de>
mm: hide a #warning for COMPILE_TEST
Ernesto A. Fernández <ernesto.mnd.fernandez(a)gmail.com>
ext4: correct documentation for grpid mount option
Zhouyi Zhou <zhouzhouyi(a)gmail.com>
ext4: save error to disk in __ext4_grp_locked_error()
Stewart Smith <stewart(a)linux.vnet.ibm.com>
rtc-opal: Fix handling of firmware error codes, prevent busy loops
Julia Lawall <Julia.Lawall(a)lip6.fr>
drm/radeon: adjust tested variable
Gustavo A. R. Silva <garsilva(a)embeddedor.com>
x86/cpu: Change type of x86_cache_size variable to unsigned int
David Woodhouse <dwmw(a)amazon.co.uk>
KVM/x86: Reduce retpoline performance impact in slot_handle_level_range(), by always inlining iterator helper methods
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Fix regression by incorrect ioctl_mutex usages
Viresh Kumar <viresh.kumar(a)linaro.org>
arm: spear13xx: Fix spics gpio controller's warning
Viresh Kumar <viresh.kumar(a)linaro.org>
arm: spear13xx: Fix dmas cells
Viresh Kumar <viresh.kumar(a)linaro.org>
arm: spear600: Add missing interrupt-parent of rtc
Patrice Chotard <patrice.chotard(a)st.com>
ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property
Eugene Syromiatnikov <esyr(a)redhat.com>
s390: fix handling of -1 in set{,fs}[gu]id16 syscalls
Bjorn Andersson <bjorn.andersson(a)linaro.org>
PM / devfreq: Propagate error from devfreq_add_device()
Jack Morgenstein <jackm(a)dev.mellanox.co.il>
IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH ports
-------------
Diffstat:
Documentation/devicetree/bindings/dma/snps-dma.txt | 2 +-
Documentation/filesystems/ext4.txt | 2 +-
Makefile | 4 ++--
arch/arm/boot/dts/s5pv210.dtsi | 1 +
arch/arm/boot/dts/spear1310-evb.dts | 2 +-
arch/arm/boot/dts/spear1340.dtsi | 4 ++--
arch/arm/boot/dts/spear13xx.dtsi | 6 ++---
arch/arm/boot/dts/spear600.dtsi | 1 +
arch/arm/boot/dts/stih407.dtsi | 3 ++-
arch/arm/boot/dts/stih410.dtsi | 3 ++-
arch/arm/mach-pxa/tosa-bt.c | 4 ++++
arch/s390/kernel/compat_linux.c | 8 +++----
arch/x86/include/asm/processor.h | 2 +-
arch/x86/kernel/cpu/common.c | 2 +-
arch/x86/kernel/cpu/microcode/intel.c | 2 +-
arch/x86/kernel/cpu/proc.c | 4 ++--
arch/x86/kvm/mmu.c | 10 ++++----
drivers/devfreq/devfreq.c | 2 +-
drivers/gpu/drm/radeon/radeon_uvd.c | 2 +-
drivers/infiniband/hw/mlx4/main.c | 13 ++++------
drivers/md/dm.c | 3 ++-
drivers/media/tuners/r820t.c | 13 ++++++----
drivers/net/ethernet/marvell/mvpp2.c | 11 ++++++---
drivers/net/ethernet/mellanox/mlx4/qp.c | 3 +++
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 ++--
drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 +
drivers/rtc/rtc-opal.c | 12 ++++++++--
drivers/video/console/dummycon.c | 1 -
drivers/video/fbdev/atmel_lcdfb.c | 8 ++++++-
fs/btrfs/inode.c | 5 +++-
fs/btrfs/tree-log.c | 27 +++++++++++++++++++++
fs/ext4/super.c | 1 +
fs/namei.c | 3 +++
include/linux/kaiser.h | 2 +-
mm/memory.c | 2 +-
sound/core/seq/seq_clientmgr.c | 23 ++++++++++--------
sound/pci/hda/patch_realtek.c | 28 ++++++++++++++++++++++
sound/usb/mixer.c | 18 ++++++++------
sound/usb/pcm.c | 9 +++++++
39 files changed, 181 insertions(+), 71 deletions(-)
Yves-Alexis Perez <corsac(a)debian.org> writes:
> On Thu, 2018-02-22 at 12:01 +1100, Michael Ellerman wrote:
>> So I guess this patch is OK for now, but we do need a full back port of
>> 222f20f to 4.9.
>
> Hi,
>
> in the light of this, do you know the full status of protections against
> Meltdown on powerpc/ppc64el architecures on 4.9?
With the patches I just sent, for pseries and powernv, the mitigation
should be in place. On machines with updated firmware we'll use the
hardware-assisted L1 flush, otherwise we fallback to doing it in
software.
cheers
On some boards setting power_save to a non 0 value leads to clicking /
popping sounds when ever we enter/leave powersaving mode. Ideally we would
figure out how to avoid these sounds, but that is not always feasible.
This commit adds a blacklist for devices where powersaving is known to
cause problems and disables it on these devices.
Note I tried to put this blacklist in userspace first:
https://github.com/systemd/systemd/pull/8128
But the systemd maintainers rightfully pointed out that it would be
impossible to then later remove entries once we actually find a way to
make power-saving work on listed boards without issues. Having this list
in the kernel will allow removal of the blacklist entry in the same commit
which fixes the clicks / plops.
The blacklist only applies to the default power_save module-option value,
if an user explicitly sets the module-option then the blacklist is not
used.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1525104
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198611
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
Changes in RFC v2:
-Only use the blacklist if the power_save module-option is not explicitly
set by the user
---
sound/pci/hda/hda_intel.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index c71dcacea807..7c588b0d6c96 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -181,7 +181,7 @@ static const struct kernel_param_ops param_ops_xint = {
};
#define param_check_xint param_check_int
-static int power_save = CONFIG_SND_HDA_POWER_SAVE_DEFAULT;
+static int power_save = -1;
module_param(power_save, xint, 0644);
MODULE_PARM_DESC(power_save, "Automatic power-saving timeout "
"(in second, 0 = disable).");
@@ -2186,6 +2186,22 @@ static int azx_probe(struct pci_dev *pci,
return err;
}
+/* On some boards setting power_save to a non 0 value leads to clicking /
+ * popping sounds when ever we enter/leave powersaving mode. Ideally we would
+ * figure out how to avoid these sounds, but that is not always feasible.
+ * So we keep a list of devices where we disable powersaving as its known
+ * to causes problems on these devices.
+ */
+static struct snd_pci_quirk power_save_blacklist[] = {
+ /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
+ SND_PCI_QUIRK(0x1849, 0x0c0c, "Asrock B85M-ITX", 0),
+ /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
+ SND_PCI_QUIRK(0x1043, 0x8733, "Asus Prime X370-Pro", 0),
+ /* https://bugzilla.kernel.org/show_bug.cgi?id=198611 */
+ SND_PCI_QUIRK(0x17aa, 0x2227, "Lenovo X1 Carbon 3rd Gen", 0),
+ {}
+};
+
/* number of codec slots for each chipset: 0 = default slots (i.e. 4) */
static unsigned int azx_max_codecs[AZX_NUM_DRIVERS] = {
[AZX_DRIVER_NVIDIA] = 8,
@@ -2197,6 +2213,7 @@ static int azx_probe_continue(struct azx *chip)
struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
struct hdac_bus *bus = azx_bus(chip);
struct pci_dev *pci = chip->pci;
+ const struct snd_pci_quirk *q;
int dev = chip->dev_index;
int err;
@@ -2278,6 +2295,16 @@ static int azx_probe_continue(struct azx *chip)
chip->running = 1;
azx_add_card_list(chip);
+
+ if (power_save == -1) {
+ power_save = CONFIG_SND_HDA_POWER_SAVE_DEFAULT;
+ q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist);
+ if (q && power_save) {
+ dev_info(chip->card->dev, "device %04x:%04x is on the power_save blacklist, forcing power_save to 0\n",
+ q->subvendor, q->subdevice);
+ power_save = 0;
+ }
+ }
snd_hda_set_power_save(&chip->bus, power_save * 1000);
if (azx_has_pm_runtime(chip) || hda->use_vga_switcheroo)
pm_runtime_put_autosuspend(&pci->dev);
--
2.14.3
This is a note to let you know that I've just added the patch titled
mei: me: add cannon point device ids
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-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 f8f4aa68a8ae98ed79c8fee3488c38a2f5d2de8c Mon Sep 17 00:00:00 2001
From: Alexander Usyskin <alexander.usyskin(a)intel.com>
Date: Sun, 18 Feb 2018 11:05:15 +0200
Subject: mei: me: add cannon point device ids
Add CNP LP and CNP H device ids for cannon lake
and coffee lake platforms.
Cc: <stable(a)vger.kernel.org> 4.14+
Signed-off-by: Alexander Usyskin <alexander.usyskin(a)intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/mei/hw-me-regs.h | 3 +++
drivers/misc/mei/pci-me.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-regs.h
index 0ccccbaf530d..bda3bd8f3141 100644
--- a/drivers/misc/mei/hw-me-regs.h
+++ b/drivers/misc/mei/hw-me-regs.h
@@ -132,6 +132,9 @@
#define MEI_DEV_ID_KBP 0xA2BA /* Kaby Point */
#define MEI_DEV_ID_KBP_2 0xA2BB /* Kaby Point 2 */
+#define MEI_DEV_ID_CNP_LP 0x9DE0 /* Cannon Point LP */
+#define MEI_DEV_ID_CNP_H 0xA360 /* Cannon Point H */
+
/*
* MEI HW Section
*/
diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
index 4a0ccda4d04b..f915000e5bf9 100644
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -98,6 +98,9 @@ static const struct pci_device_id mei_me_pci_tbl[] = {
{MEI_PCI_DEVICE(MEI_DEV_ID_KBP, MEI_ME_PCH8_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_KBP_2, MEI_ME_PCH8_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP, MEI_ME_PCH8_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H, MEI_ME_PCH8_CFG)},
+
/* required last entry */
{0, }
};
--
2.16.2
This is a note to let you know that I've just added the patch titled
mei: me: add cannon point device ids for 4th device
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-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 2a4ac172c2f257d28c47b90c9e381bec31edcc44 Mon Sep 17 00:00:00 2001
From: Tomas Winkler <tomas.winkler(a)intel.com>
Date: Sun, 18 Feb 2018 11:05:16 +0200
Subject: mei: me: add cannon point device ids for 4th device
Add cannon point device ids for 4th (itouch) device.
Cc: <stable(a)vger.kernel.org> 4.14+
Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/mei/hw-me-regs.h | 2 ++
drivers/misc/mei/pci-me.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-regs.h
index bda3bd8f3141..e4b10b2d1a08 100644
--- a/drivers/misc/mei/hw-me-regs.h
+++ b/drivers/misc/mei/hw-me-regs.h
@@ -133,7 +133,9 @@
#define MEI_DEV_ID_KBP_2 0xA2BB /* Kaby Point 2 */
#define MEI_DEV_ID_CNP_LP 0x9DE0 /* Cannon Point LP */
+#define MEI_DEV_ID_CNP_LP_4 0x9DE4 /* Cannon Point LP 4 (iTouch) */
#define MEI_DEV_ID_CNP_H 0xA360 /* Cannon Point H */
+#define MEI_DEV_ID_CNP_H_4 0xA364 /* Cannon Point H 4 (iTouch) */
/*
* MEI HW Section
diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
index f915000e5bf9..ea4e152270a3 100644
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -99,7 +99,9 @@ static const struct pci_device_id mei_me_pci_tbl[] = {
{MEI_PCI_DEVICE(MEI_DEV_ID_KBP_2, MEI_ME_PCH8_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP, MEI_ME_PCH8_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP_4, MEI_ME_PCH8_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H, MEI_ME_PCH8_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H_4, MEI_ME_PCH8_CFG)},
/* required last entry */
{0, }
--
2.16.2
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 eac56aa3bc8af3d9b9850345d0f2da9d83529134 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Fri, 17 Nov 2017 14:38:31 +0100
Subject: [PATCH] PCI: keystone: Fix interrupt-controller-node lookup
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>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
[lorenzo.pieralisi(a)arm.com: updated commit subject]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
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;
On Thu, Feb 22, 2018 at 10:33:50AM +0100, Yves-Alexis Perez wrote:
> On Thu, 2018-02-22 at 12:01 +1100, Michael Ellerman wrote:
> > So I guess this patch is OK for now, but we do need a full back port of
> > 222f20f to 4.9.
>
> Hi,
>
> in the light of this, do you know the full status of protections against
> Meltdown on powerpc/ppc64el architecures on 4.9?
Did you look at /sys/devices/system/cpu/vulnerabilities/ to see what the
files there say?
thanks,
greg k-h
On some boards setting power_save to a non 0 value leads to clicking /
popping sounds when ever we enter/leave powersaving mode. Ideally we would
figure out how to avoid these sounds, but that is not always feasible.
This commit adds a blacklist for devices where powersaving is known to
cause problems and disables it on these devices.
Note I tried to put this blacklist in userspace first:
https://github.com/systemd/systemd/pull/8128
But the systemd maintainers rightfully pointed out that it would be
impossible to then later remove entries once we actually find a way to
make power-saving work on listed boards without issues. Having this list
in the kernel will allow removal of the blacklist entry in the same commit
which fixes the clicks / plops.
I've chosen to also apply the blacklist to changes made through
/sys/module/snd_hda_intel/parameters/power_save, since tools such as
powertop and TLP do this automatically.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1525104
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1533858
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
About the choice to also apply this to changes made through
/sys/module/snd_hda_intel/parameters/power_save, one could argue that this
will get in the way of users who want the power-saving anyways and are
willing to live with the clicks/plops. An alternative approach would be to
only apply this to the value of the module-parameter at boot and then only
when it matches CONFIG_SND_HDA_POWER_SAVE_DEFAULT. I'm open to changing this
for v2.
---
sound/pci/hda/hda_intel.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index c71dcacea807..ea612aeb1663 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -936,6 +936,34 @@ static unsigned int azx_get_pos_skl(struct azx *chip, struct azx_dev *azx_dev)
return azx_get_pos_posbuf(chip, azx_dev);
}
+/* On some boards setting power_save to a non 0 value leads to clicking /
+ * popping sounds when ever we enter/leave powersaving mode. Ideally we would
+ * figure out how to avoid these sounds, but that is not always feasible.
+ * So we keep a list of devices where we disable powersaving as its known to
+ * causes problems on these devices.
+ */
+static struct snd_pci_quirk power_save_blacklist[] = {
+ /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
+ SND_PCI_QUIRK(0x1849, 0x0c0c, "Asrock B85M-ITX", 0),
+ /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
+ SND_PCI_QUIRK(0x1043, 0x8733, "Asus Prime X370-Pro", 0),
+ /* https://bugzilla.redhat.com/show_bug.cgi?id=1533858 */
+ SND_PCI_QUIRK(0x17aa, 0x2227, "Lenovo X1 Carbon 3rd Gen", 0),
+ {}
+};
+
+static void check_power_save_blacklist(struct azx *chip)
+{
+ const struct snd_pci_quirk *q;
+
+ q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist);
+ if (q && power_save) {
+ dev_info(chip->card->dev, "device %04x:%04x is on the power_save blacklist, forcing power_save to 0\n",
+ q->subvendor, q->subdevice);
+ power_save = 0;
+ }
+}
+
#ifdef CONFIG_PM
static DEFINE_MUTEX(card_list_lock);
static LIST_HEAD(card_list);
@@ -972,6 +1000,7 @@ static int param_set_xint(const char *val, const struct kernel_param *kp)
chip = &hda->chip;
if (!hda->probe_continued || chip->disabled)
continue;
+ check_power_save_blacklist(chip);
snd_hda_set_power_save(&chip->bus, power_save * 1000);
}
mutex_unlock(&card_list_lock);
@@ -2278,6 +2307,7 @@ static int azx_probe_continue(struct azx *chip)
chip->running = 1;
azx_add_card_list(chip);
+ check_power_save_blacklist(chip);
snd_hda_set_power_save(&chip->bus, power_save * 1000);
if (azx_has_pm_runtime(chip) || hda->use_vga_switcheroo)
pm_runtime_put_autosuspend(&pci->dev);
--
2.14.3
On Tue, Mar 28, 2017 at 02:30:56PM +0200, Greg Kroah-Hartman wrote:
> 4.10-stable review patch. If anyone has any objections, please let me know.
> + if (!(auditd_test_task(current) ||
> + (current == __mutex_owner(&audit_cmd_mutex)))) {
> + long stime = audit_backlog_wait_time;
Since I cannot find the original email on lkml, NAK on this.
__mutex_owner() is not a general purpose helper function.
From: Michal Hocko <mhocko(a)suse.com>
Subject: vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems
Kai Heng Feng has noticed that BUG_ON(PageHighMem(pg)) triggers in
drivers/media/common/saa7146/saa7146_core.c since 19809c2da28a ("mm,
vmalloc: use __GFP_HIGHMEM implicitly"). saa7146_vmalloc_build_pgtable
uses vmalloc_32 and it is reasonable to expect that the resulting page is
not in highmem. The above commit aimed to add __GFP_HIGHMEM only for
those requests which do not specify any zone modifier gfp flag.
vmalloc_32 relies on GFP_VMALLOC32 which should do the right thing.
Except it has been missed that GFP_VMALLOC32 is an alias for GFP_KERNEL on
32b architectures. Thanks to Matthew to notice this.
Fix the problem by unconditionally setting GFP_DMA32 in GFP_VMALLOC32 for
!64b arches (as a bailout). This should do the right thing and use
ZONE_NORMAL which should be always below 4G on 32b systems.
Debugged by Matthew Wilcox.
[akpm(a)linux-foundation.org: coding-style fixes]
Link: http://lkml.kernel.org/r/20180212095019.GX21609@dhcp22.suse.cz
Fixes: 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly”)
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: Kai Heng Feng <kai.heng.feng(a)canonical.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Laura Abbott <labbott(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/vmalloc.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff -puN mm/vmalloc.c~vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems mm/vmalloc.c
--- a/mm/vmalloc.c~vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems
+++ a/mm/vmalloc.c
@@ -1943,11 +1943,15 @@ void *vmalloc_exec(unsigned long size)
}
#if defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA32)
-#define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL
+#define GFP_VMALLOC32 (GFP_DMA32 | GFP_KERNEL)
#elif defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA)
-#define GFP_VMALLOC32 GFP_DMA | GFP_KERNEL
+#define GFP_VMALLOC32 (GFP_DMA | GFP_KERNEL)
#else
-#define GFP_VMALLOC32 GFP_KERNEL
+/*
+ * 64b systems should always have either DMA or DMA32 zones. For others
+ * GFP_DMA32 should do the right thing and use the normal zone.
+ */
+#define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL
#endif
/**
_
From: Huang Ying <huang.ying.caritas(a)gmail.com>
Subject: mm, swap, frontswap: fix THP swap if frontswap enabled
It was reported by Sergey Senozhatsky that if THP (Transparent Huge Page)
and frontswap (via zswap) are both enabled, when memory goes low so that
swap is triggered, segfault and memory corruption will occur in random
user space applications as follow,
kernel: urxvt[338]: segfault at 20 ip 00007fc08889ae0d sp 00007ffc73a7fc40 error 6 in libc-2.26.so[7fc08881a000+1ae000]
#0 0x00007fc08889ae0d _int_malloc (libc.so.6)
#1 0x00007fc08889c2f3 malloc (libc.so.6)
#2 0x0000560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
#3 0x0000560e6005e75c n/a (urxvt)
#4 0x0000560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez (urxvt)
#5 0x0000560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
#6 0x0000560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
#7 0x0000560e6005c10f _Z17ev_invoke_pendingv (urxvt)
#8 0x0000560e6005cb55 ev_run (urxvt)
#9 0x0000560e6003b9b9 main (urxvt)
#10 0x00007fc08883af4a __libc_start_main (libc.so.6)
#11 0x0000560e6003f9da _start (urxvt)
After bisection, it was found the first bad commit is bd4c82c22c367e068
("mm, THP, swap: delay splitting THP after swapped out").
The root cause is as follows:
When the pages are written to swap device during swapping out in
swap_writepage(), zswap (fontswap) is tried to compress the pages to
improve performance. But zswap (frontswap) will treat THP as a normal
page, so only the head page is saved. After swapping in, tail pages will
not be restored to their original contents, causing memory corruption in
the applications.
This is fixed by refusing to save page in the frontswap store functions if
the page is a THP. So that the THP will be swapped out to swap device.
Another choice is to split THP if frontswap is enabled. But it is found
that the frontswap enabling isn't flexible. For example, if
CONFIG_ZSWAP=y (cannot be module), frontswap will be enabled even if zswap
itself isn't enabled.
Frontswap has multiple backends, to make it easy for one backend to enable
THP support, the THP checking is put in backend frontswap store functions
instead of the general interfaces.
Link: http://lkml.kernel.org/r/20180209084947.22749-1-ying.huang@intel.com
Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped out")
Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com>
Reported-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Tested-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Suggested-by: Minchan Kim <minchan(a)kernel.org> [put THP checking in backend]
Cc: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Cc: Dan Streetman <ddstreet(a)ieee.org>
Cc: Seth Jennings <sjenning(a)redhat.com>
Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Cc: Shaohua Li <shli(a)kernel.org>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Shakeel Butt <shakeelb(a)google.com>
Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Cc: Juergen Gross <jgross(a)suse.com>
Cc: <stable(a)vger.kernel.org> [4.14]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
drivers/xen/tmem.c | 4 ++++
mm/zswap.c | 6 ++++++
2 files changed, 10 insertions(+)
diff -puN drivers/xen/tmem.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3 drivers/xen/tmem.c
--- a/drivers/xen/tmem.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3
+++ a/drivers/xen/tmem.c
@@ -284,6 +284,10 @@ static int tmem_frontswap_store(unsigned
int pool = tmem_frontswap_poolid;
int ret;
+ /* THP isn't supported */
+ if (PageTransHuge(page))
+ return -1;
+
if (pool < 0)
return -1;
if (ind64 != ind)
diff -puN mm/zswap.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3 mm/zswap.c
--- a/mm/zswap.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3
+++ a/mm/zswap.c
@@ -1007,6 +1007,12 @@ static int zswap_frontswap_store(unsigne
u8 *src, *dst;
struct zswap_header zhdr = { .swpentry = swp_entry(type, offset) };
+ /* THP isn't supported */
+ if (PageTransHuge(page)) {
+ ret = -EINVAL;
+ goto reject;
+ }
+
if (!zswap_enabled || !tree) {
ret = -ENODEV;
goto reject;
_
From: Arnd Bergmann <arnd(a)arndb.de>
Subject: Kbuild: always define endianess in kconfig.h
Build testing with LTO found a couple of files that get compiled
differently depending on whether asm/byteorder.h gets included early
enough or not. In particular, include/asm-generic/qrwlock_types.h is
affected by this, but there are probably others as well.
The symptom is a series of LTO link time warnings, including these:
net/netlabel/netlabel_unlabeled.h:223: error: type of 'netlbl_unlhsh_add' does not match original declaration [-Werror=lto-type-mismatch]
int netlbl_unlhsh_add(struct net *net,
net/netlabel/netlabel_unlabeled.c:377: note: 'netlbl_unlhsh_add' was previously declared here
include/net/ipv6.h:360: error: type of 'ipv6_renew_options_kern' does not match original declaration [-Werror=lto-type-mismatch]
ipv6_renew_options_kern(struct sock *sk,
net/ipv6/exthdrs.c:1162: note: 'ipv6_renew_options_kern' was previously declared here
net/core/dev.c:761: note: 'dev_get_by_name_rcu' was previously declared here
struct net_device *dev_get_by_name_rcu(struct net *net, const char *name)
net/core/dev.c:761: note: code may be misoptimized unless -fno-strict-aliasing is used
drivers/gpu/drm/i915/i915_drv.h:3377: error: type of 'i915_gem_object_set_to_wc_domain' does not match original declaration [-Werror=lto-type-mismatch]
i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write);
drivers/gpu/drm/i915/i915_gem.c:3639: note: 'i915_gem_object_set_to_wc_domain' was previously declared here
include/linux/debugfs.h:92:9: error: type of 'debugfs_attr_read' does not match original declaration [-Werror=lto-type-mismatch]
ssize_t debugfs_attr_read(struct file *file, char __user *buf,
fs/debugfs/file.c:318: note: 'debugfs_attr_read' was previously declared here
include/linux/rwlock_api_smp.h:30: error: type of '_raw_read_unlock' does not match original declaration [-Werror=lto-type-mismatch]
void __lockfunc _raw_read_unlock(rwlock_t *lock) __releases(lock);
kernel/locking/spinlock.c:246:26: note: '_raw_read_unlock' was previously declared here
include/linux/fs.h:3308:5: error: type of 'simple_attr_open' does not match original declaration [-Werror=lto-type-mismatch]
int simple_attr_open(struct inode *inode, struct file *file,
fs/libfs.c:795: note: 'simple_attr_open' was previously declared here
All of the above are caused by include/asm-generic/qrwlock_types.h failing
to include asm/byteorder.h after commit e0d02285f16e ("locking/qrwlock:
Use 'struct qrwlock' instead of 'struct __qrwlock'") in linux-4.15.
Similar bugs may or may not exist in older kernels as well, but there is
no easy way to test those with link-time optimizations, and kernels before
4.14 are harder to fix because they don't have Babu's patch series
We had similar issues with CONFIG_ symbols in the past and ended up always
including the configuration headers though linux/kconfig.h. This works
around the issue through that same file, defining either __BIG_ENDIAN or
__LITTLE_ENDIAN depending on CONFIG_CPU_BIG_ENDIAN, which is now always
set on all architectures since commit 4c97a0c8fee3 ("arch: define
CPU_BIG_ENDIAN for all fixed big endian archs").
Link: http://lkml.kernel.org/r/20180202154104.1522809-2-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Babu Moger <babu.moger(a)amd.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Cc: Nicolas Pitre <nico(a)linaro.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/kconfig.h | 6 ++++++
1 file changed, 6 insertions(+)
diff -puN include/linux/kconfig.h~kbuild-always-define-endianess-in-kconfigh include/linux/kconfig.h
--- a/include/linux/kconfig.h~kbuild-always-define-endianess-in-kconfigh
+++ a/include/linux/kconfig.h
@@ -4,6 +4,12 @@
#include <generated/autoconf.h>
+#ifdef CONFIG_CPU_BIG_ENDIAN
+#define __BIG_ENDIAN 4321
+#else
+#define __LITTLE_ENDIAN 1234
+#endif
+
#define __ARG_PLACEHOLDER_1 0,
#define __take_second_arg(__ignored, val, ...) val
_
In randconfig testing, we sometimes get this warning:
drivers/gpu/drm/radeon/radeon_object.c: In function 'radeon_bo_create':
drivers/gpu/drm/radeon/radeon_object.c:242:2: error: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [-Werror=cpp]
#warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \
This is rather annoying since almost all other code produces no build-time
output unless we have found a real bug. We already fixed this in the
amdgpu driver in commit 31bb90f1cd08 ("drm/amdgpu: shut up #warning for
compile testing") by adding a CONFIG_COMPILE_TEST check last year and
agreed to do the same here, but both Michel and I then forgot about it
until I came across the issue again now.
For stable kernels, as this is one of very few remaining randconfig
warnings in 4.14.
Cc: stable(a)vger.kernel.org
Link: https://patchwork.kernel.org/patch/9550009/
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
drivers/gpu/drm/radeon/radeon_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
index 093594976126..54c2b4fc5ead 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -238,9 +238,10 @@ int radeon_bo_create(struct radeon_device *rdev,
* may be slow
* See https://bugs.freedesktop.org/show_bug.cgi?id=88758
*/
-
+#ifndef CONFIG_COMPILE_TEST
#warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \
thanks to write-combining
+#endif
if (bo->flags & RADEON_GEM_GTT_WC)
DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT for "
--
2.9.0
This is a note to let you know that I've just added the patch titled
mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb
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:
mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.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 f2bc600008bd6f7f5d0b6b56238d14f95cd454d2 Mon Sep 17 00:00:00 2001
From: "yinbo.zhu" <yinbo.zhu(a)nxp.com>
Date: Fri, 1 Dec 2017 15:09:34 +0800
Subject: mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb
From: yinbo.zhu <yinbo.zhu(a)nxp.com>
commit f2bc600008bd6f7f5d0b6b56238d14f95cd454d2 upstream.
When system wakes up from sleep on ls1046ardb, the SD operation fails
with mmc error messages since ESDHC_TB_EN bit couldn't be cleaned by
eSDHC_SYSCTL[RSTA]. It's proper to clean this bit in esdhc_reset()
rather than in probe.
Signed-off-by: yinbo.zhu <yinbo.zhu(a)nxp.com>
Acked-by: Yangbo Lu <yangbo.lu(a)nxp.com>
Acked-by: Adrian Hunter <adrian.hunter(a)intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Cc: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/sdhci-of-esdhc.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -489,10 +489,18 @@ static void esdhc_pltfm_set_bus_width(st
static void esdhc_reset(struct sdhci_host *host, u8 mask)
{
+ u32 val;
+
sdhci_reset(host, mask);
sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
+
+ if (mask & SDHCI_RESET_ALL) {
+ val = sdhci_readl(host, ESDHC_TBCTL);
+ val &= ~ESDHC_TB_EN;
+ sdhci_writel(host, val, ESDHC_TBCTL);
+ }
}
#ifdef CONFIG_PM_SLEEP
@@ -584,10 +592,6 @@ static void esdhc_init(struct platform_d
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
- val = sdhci_readl(host, ESDHC_TBCTL);
- val &= ~ESDHC_TB_EN;
- sdhci_writel(host, val, ESDHC_TBCTL);
-
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
Patches currently in stable-queue which might be from yinbo.zhu(a)nxp.com are
queue-4.9/mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch
queue-4.9/mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch
This is a note to let you know that I've just added the patch titled
mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec
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:
mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.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 97618aca1440b5addc5c3d78659d3e176be23b80 Mon Sep 17 00:00:00 2001
From: "yinbo.zhu" <yinbo.zhu(a)nxp.com>
Date: Wed, 8 Nov 2017 17:09:50 +0800
Subject: mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec
From: yinbo.zhu <yinbo.zhu(a)nxp.com>
commit 97618aca1440b5addc5c3d78659d3e176be23b80 upstream.
The bit eSDHC_TBCTL[TB_EN] couldn't be reset by eSDHC_SYSCTL[RSTA] which is
used to reset for all. The driver should make sure it's cleared before card
initialization, otherwise the initialization would fail.
Signed-off-by: yinbo.zhu <yinbo.zhu(a)nxp.com>
Acked-by: Adrian Hunter <adrian.hunter(a)intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Cc: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/sdhci-of-esdhc.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -584,6 +584,10 @@ static void esdhc_init(struct platform_d
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
+ val = sdhci_readl(host, ESDHC_TBCTL);
+ val &= ~ESDHC_TB_EN;
+ sdhci_writel(host, val, ESDHC_TBCTL);
+
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
Patches currently in stable-queue which might be from yinbo.zhu(a)nxp.com are
queue-4.9/mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch
queue-4.9/mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch
This is a note to let you know that I've just added the patch titled
media: r820t: fix r820t_write_reg for KASAN
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:
media-r820t-fix-r820t_write_reg-for-kasan.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 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 30 Nov 2017 06:08:05 -0500
Subject: media: r820t: fix r820t_write_reg for KASAN
From: Arnd Bergmann <arnd(a)arndb.de>
commit 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 upstream.
With CONFIG_KASAN, we get an overly long stack frame due to inlining
the register access functions:
drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
This is caused by a gcc bug that has now been fixed in gcc-8.
To work around the problem, we can pass the register data
through a local variable that older gcc versions can optimize
out as well.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/tuners/r820t.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -396,9 +396,11 @@ static int r820t_write(struct r820t_priv
return 0;
}
-static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
+static inline int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
{
- return r820t_write(priv, reg, &val, 1);
+ u8 tmp = val; /* work around GCC PR81715 with asan-stack=1 */
+
+ return r820t_write(priv, reg, &tmp, 1);
}
static int r820t_read_cache_reg(struct r820t_priv *priv, int reg)
@@ -411,17 +413,18 @@ static int r820t_read_cache_reg(struct r
return -EINVAL;
}
-static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
+static inline int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
u8 bit_mask)
{
+ u8 tmp = val;
int rc = r820t_read_cache_reg(priv, reg);
if (rc < 0)
return rc;
- val = (rc & ~bit_mask) | (val & bit_mask);
+ tmp = (rc & ~bit_mask) | (tmp & bit_mask);
- return r820t_write(priv, reg, &val, 1);
+ return r820t_write(priv, reg, &tmp, 1);
}
static int r820t_read(struct r820t_priv *priv, u8 reg, u8 *val, int len)
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.9/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.9/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.9/kselftest-fix-oom-in-memory-compaction-test.patch
queue-4.9/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.9/x86-fix-build-warnign-with-32-bit-pae.patch
queue-4.9/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.9/mm-hide-a-warning-for-compile_test.patch
queue-4.9/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.9/arm-lpc3250-fix-uda1380-gpio-numbers.patch
queue-4.9/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.9/arm-spear13xx-fix-dmas-cells.patch
queue-4.9/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch
queue-4.9/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
arm64: dts: msm8916: Add missing #phy-cells
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:
arm64-dts-msm8916-add-missing-phy-cells.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 b0ab681285aa66064f2de5b74191c0cabba381ff Mon Sep 17 00:00:00 2001
From: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Date: Tue, 7 Nov 2017 19:45:01 -0800
Subject: arm64: dts: msm8916: Add missing #phy-cells
From: Bjorn Andersson <bjorn.andersson(a)linaro.org>
commit b0ab681285aa66064f2de5b74191c0cabba381ff upstream.
Add a missing #phy-cells to the dsi-phy, to silence dtc warning.
Cc: Archit Taneja <architt(a)codeaurora.org>
Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support")
Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Reviewed-by: Archit Taneja <architt(a)codeaurora.org>
Signed-off-by: Andy Gross <andy.gross(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -796,6 +796,7 @@
"dsi_phy_regulator";
#clock-cells = <1>;
+ #phy-cells = <0>;
clocks = <&gcc GCC_MDSS_AHB_CLK>;
clock-names = "iface_clk";
Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are
queue-4.9/pm-devfreq-propagate-error-from-devfreq_add_device.patch
queue-4.9/arm64-dts-msm8916-add-missing-phy-cells.patch
queue-4.9/arm64-dts-msm8916-correct-ipc-references-for-smsm.patch
This is a note to let you know that I've just added the patch titled
ARM: pxa/tosa-bt: add MODULE_LICENSE tag
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:
arm-pxa-tosa-bt-add-module_license-tag.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 3343647813fdf0f2409fbf5816ee3e0622168079 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 10 Jan 2018 15:40:37 +0100
Subject: ARM: pxa/tosa-bt: add MODULE_LICENSE tag
From: Arnd Bergmann <arnd(a)arndb.de>
commit 3343647813fdf0f2409fbf5816ee3e0622168079 upstream.
Without this tag, we get a build warning:
WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o
For completeness, I'm also adding author and description fields.
Acked-by: Robert Jarzmik <robert.jarzmik(a)free.fr>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-pxa/tosa-bt.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/arm/mach-pxa/tosa-bt.c
+++ b/arch/arm/mach-pxa/tosa-bt.c
@@ -132,3 +132,7 @@ static struct platform_driver tosa_bt_dr
},
};
module_platform_driver(tosa_bt_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Dmitry Baryshkov");
+MODULE_DESCRIPTION("Bluetooth built-in chip control");
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.9/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.9/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.9/kselftest-fix-oom-in-memory-compaction-test.patch
queue-4.9/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.9/x86-fix-build-warnign-with-32-bit-pae.patch
queue-4.9/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.9/mm-hide-a-warning-for-compile_test.patch
queue-4.9/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.9/arm-lpc3250-fix-uda1380-gpio-numbers.patch
queue-4.9/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.9/arm-spear13xx-fix-dmas-cells.patch
queue-4.9/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch
queue-4.9/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: s5pv210: add interrupt-parent for ohci
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:
arm-dts-s5pv210-add-interrupt-parent-for-ohci.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 5c1037196b9ee75897c211972de370ed1336ec8f Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 10 Jan 2018 17:10:11 +0100
Subject: ARM: dts: s5pv210: add interrupt-parent for ohci
From: Arnd Bergmann <arnd(a)arndb.de>
commit 5c1037196b9ee75897c211972de370ed1336ec8f upstream.
The ohci-hcd node has an interrupt number but no interrupt-parent,
leading to a warning with current dtc versions:
arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
As seen from the related exynos dts files, the ohci and ehci controllers
always share one interrupt number, and the number is the same here as
well, so setting the same interrupt-parent is the reasonable solution
here.
Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/s5pv210.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -463,6 +463,7 @@
compatible = "samsung,exynos4210-ohci";
reg = <0xec300000 0x100>;
interrupts = <23>;
+ interrupt-parent = <&vic1>;
clocks = <&clocks CLK_USB_HOST>;
clock-names = "usbhost";
#address-cells = <1>;
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.9/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.9/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.9/kselftest-fix-oom-in-memory-compaction-test.patch
queue-4.9/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.9/x86-fix-build-warnign-with-32-bit-pae.patch
queue-4.9/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.9/mm-hide-a-warning-for-compile_test.patch
queue-4.9/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.9/arm-lpc3250-fix-uda1380-gpio-numbers.patch
queue-4.9/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.9/arm-spear13xx-fix-dmas-cells.patch
queue-4.9/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch
queue-4.9/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: exynos: fix RTC interrupt for exynos5410
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:
arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.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 5628a8ca14149ba4226e3bdce3a04c3b688435ad Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 21 Dec 2017 22:30:07 +0100
Subject: ARM: dts: exynos: fix RTC interrupt for exynos5410
From: Arnd Bergmann <arnd(a)arndb.de>
commit 5628a8ca14149ba4226e3bdce3a04c3b688435ad upstream.
According to the comment added to exynos_dt_pmu_match[] in commit
8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains"),
the RTC is not able to wake up the system through the PMU on Exynos5410,
unlike Exynos5420.
However, when the RTC DT node got added, it was a straight copy of
the Exynos5420 node, which now causes a warning from dtc.
This removes the incorrect interrupt-parent, which should get the
interrupt working and avoid the warning.
Fixes: e1e146b1b062 ("ARM: dts: exynos: Add RTC and I2C to Exynos5410")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/exynos5410.dtsi | 1 -
1 file changed, 1 deletion(-)
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -274,7 +274,6 @@
&rtc {
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
- interrupt-parent = <&pmu_system_controller>;
status = "disabled";
};
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.9/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.9/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.9/kselftest-fix-oom-in-memory-compaction-test.patch
queue-4.9/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.9/x86-fix-build-warnign-with-32-bit-pae.patch
queue-4.9/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.9/mm-hide-a-warning-for-compile_test.patch
queue-4.9/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.9/arm-lpc3250-fix-uda1380-gpio-numbers.patch
queue-4.9/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.9/arm-spear13xx-fix-dmas-cells.patch
queue-4.9/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch
queue-4.9/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
arm: dts: mt2701: Add reset-cells
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:
arm-dts-mt2701-add-reset-cells.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 ae72e95b5e4ded145bfc6926ad9457b74e3af41a Mon Sep 17 00:00:00 2001
From: Matthias Brugger <matthias.bgg(a)gmail.com>
Date: Fri, 1 Dec 2017 13:07:08 +0100
Subject: arm: dts: mt2701: Add reset-cells
From: Matthias Brugger <matthias.bgg(a)gmail.com>
commit ae72e95b5e4ded145bfc6926ad9457b74e3af41a upstream.
The hifsys and ethsys needs the definition of the reset-cells
property. Fix this.
Reviewed-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/mt2701.dtsi | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -197,12 +197,14 @@
compatible = "mediatek,mt2701-hifsys", "syscon";
reg = <0 0x1a000000 0 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
ethsys: syscon@1b000000 {
compatible = "mediatek,mt2701-ethsys", "syscon";
reg = <0 0x1b000000 0 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
bdpsys: syscon@1c000000 {
Patches currently in stable-queue which might be from matthias.bgg(a)gmail.com are
queue-4.9/arm-dts-mt2701-add-reset-cells.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: Delete bogus reference to the charlcd
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:
arm-dts-delete-bogus-reference-to-the-charlcd.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 586b2a4befad88cd87b372a1cea01e58c6811ea9 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Tue, 2 Jan 2018 08:57:17 +0100
Subject: ARM: dts: Delete bogus reference to the charlcd
From: Linus Walleij <linus.walleij(a)linaro.org>
commit 586b2a4befad88cd87b372a1cea01e58c6811ea9 upstream.
The EB MP board probably has a character LCD but the board manual does
not really state which IRQ it has assigned to this device. The invalid
assignment was a mistake by me during submission of the DTSI where I was
looking for the reference, didn't find it and didn't fill it in.
Delete this for now: it can probably be fixed but that requires access
to the actual board for some trial-and-error experiments.
Reported-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Olof Johansson <olof(a)lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/arm-realview-eb-mp.dtsi | 5 -----
1 file changed, 5 deletions(-)
--- a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
+++ b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
@@ -150,11 +150,6 @@
interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
};
-&charlcd {
- interrupt-parent = <&intc>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
-};
-
&serial0 {
interrupt-parent = <&intc>;
interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.9/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.9/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb
to the 4.15-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-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch
and it can be found in the queue-4.15 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 f2bc600008bd6f7f5d0b6b56238d14f95cd454d2 Mon Sep 17 00:00:00 2001
From: "yinbo.zhu" <yinbo.zhu(a)nxp.com>
Date: Fri, 1 Dec 2017 15:09:34 +0800
Subject: mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb
From: yinbo.zhu <yinbo.zhu(a)nxp.com>
commit f2bc600008bd6f7f5d0b6b56238d14f95cd454d2 upstream.
When system wakes up from sleep on ls1046ardb, the SD operation fails
with mmc error messages since ESDHC_TB_EN bit couldn't be cleaned by
eSDHC_SYSCTL[RSTA]. It's proper to clean this bit in esdhc_reset()
rather than in probe.
Signed-off-by: yinbo.zhu <yinbo.zhu(a)nxp.com>
Acked-by: Yangbo Lu <yangbo.lu(a)nxp.com>
Acked-by: Adrian Hunter <adrian.hunter(a)intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Cc: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/sdhci-of-esdhc.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -589,10 +589,18 @@ static void esdhc_pltfm_set_bus_width(st
static void esdhc_reset(struct sdhci_host *host, u8 mask)
{
+ u32 val;
+
sdhci_reset(host, mask);
sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
+
+ if (mask & SDHCI_RESET_ALL) {
+ val = sdhci_readl(host, ESDHC_TBCTL);
+ val &= ~ESDHC_TB_EN;
+ sdhci_writel(host, val, ESDHC_TBCTL);
+ }
}
/* The SCFG, Supplemental Configuration Unit, provides SoC specific
@@ -785,10 +793,6 @@ static void esdhc_init(struct platform_d
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
- val = sdhci_readl(host, ESDHC_TBCTL);
- val &= ~ESDHC_TB_EN;
- sdhci_writel(host, val, ESDHC_TBCTL);
-
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
Patches currently in stable-queue which might be from yinbo.zhu(a)nxp.com are
queue-4.15/mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch
queue-4.15/mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch
This is a note to let you know that I've just added the patch titled
mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec
to the 4.15-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-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch
and it can be found in the queue-4.15 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 97618aca1440b5addc5c3d78659d3e176be23b80 Mon Sep 17 00:00:00 2001
From: "yinbo.zhu" <yinbo.zhu(a)nxp.com>
Date: Wed, 8 Nov 2017 17:09:50 +0800
Subject: mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec
From: yinbo.zhu <yinbo.zhu(a)nxp.com>
commit 97618aca1440b5addc5c3d78659d3e176be23b80 upstream.
The bit eSDHC_TBCTL[TB_EN] couldn't be reset by eSDHC_SYSCTL[RSTA] which is
used to reset for all. The driver should make sure it's cleared before card
initialization, otherwise the initialization would fail.
Signed-off-by: yinbo.zhu <yinbo.zhu(a)nxp.com>
Acked-by: Adrian Hunter <adrian.hunter(a)intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Cc: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/sdhci-of-esdhc.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -785,6 +785,10 @@ static void esdhc_init(struct platform_d
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
+ val = sdhci_readl(host, ESDHC_TBCTL);
+ val &= ~ESDHC_TB_EN;
+ sdhci_writel(host, val, ESDHC_TBCTL);
+
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
Patches currently in stable-queue which might be from yinbo.zhu(a)nxp.com are
queue-4.15/mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch
queue-4.15/mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch
This is a note to let you know that I've just added the patch titled
media: r820t: fix r820t_write_reg for KASAN
to the 4.15-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-r820t-fix-r820t_write_reg-for-kasan.patch
and it can be found in the queue-4.15 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 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 30 Nov 2017 06:08:05 -0500
Subject: media: r820t: fix r820t_write_reg for KASAN
From: Arnd Bergmann <arnd(a)arndb.de>
commit 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 upstream.
With CONFIG_KASAN, we get an overly long stack frame due to inlining
the register access functions:
drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
This is caused by a gcc bug that has now been fixed in gcc-8.
To work around the problem, we can pass the register data
through a local variable that older gcc versions can optimize
out as well.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/tuners/r820t.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -396,9 +396,11 @@ static int r820t_write(struct r820t_priv
return 0;
}
-static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
+static inline int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
{
- return r820t_write(priv, reg, &val, 1);
+ u8 tmp = val; /* work around GCC PR81715 with asan-stack=1 */
+
+ return r820t_write(priv, reg, &tmp, 1);
}
static int r820t_read_cache_reg(struct r820t_priv *priv, int reg)
@@ -411,17 +413,18 @@ static int r820t_read_cache_reg(struct r
return -EINVAL;
}
-static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
+static inline int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
u8 bit_mask)
{
+ u8 tmp = val;
int rc = r820t_read_cache_reg(priv, reg);
if (rc < 0)
return rc;
- val = (rc & ~bit_mask) | (val & bit_mask);
+ tmp = (rc & ~bit_mask) | (tmp & bit_mask);
- return r820t_write(priv, reg, &val, 1);
+ return r820t_write(priv, reg, &tmp, 1);
}
static int r820t_read(struct r820t_priv *priv, u8 reg, u8 *val, int len)
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.15/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.15/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.15/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.15/kselftest-fix-oom-in-memory-compaction-test.patch
queue-4.15/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.15/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.15/mm-hide-a-warning-for-compile_test.patch
queue-4.15/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.15/arm-lpc3250-fix-uda1380-gpio-numbers.patch
queue-4.15/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.15/arm-spear13xx-fix-dmas-cells.patch
queue-4.15/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch
queue-4.15/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
arm64: dts: msm8916: Add missing #phy-cells
to the 4.15-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-dts-msm8916-add-missing-phy-cells.patch
and it can be found in the queue-4.15 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 b0ab681285aa66064f2de5b74191c0cabba381ff Mon Sep 17 00:00:00 2001
From: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Date: Tue, 7 Nov 2017 19:45:01 -0800
Subject: arm64: dts: msm8916: Add missing #phy-cells
From: Bjorn Andersson <bjorn.andersson(a)linaro.org>
commit b0ab681285aa66064f2de5b74191c0cabba381ff upstream.
Add a missing #phy-cells to the dsi-phy, to silence dtc warning.
Cc: Archit Taneja <architt(a)codeaurora.org>
Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support")
Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Reviewed-by: Archit Taneja <architt(a)codeaurora.org>
Signed-off-by: Andy Gross <andy.gross(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -906,6 +906,7 @@
"dsi_phy_regulator";
#clock-cells = <1>;
+ #phy-cells = <0>;
clocks = <&gcc GCC_MDSS_AHB_CLK>;
clock-names = "iface_clk";
Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are
queue-4.15/pm-devfreq-propagate-error-from-devfreq_add_device.patch
queue-4.15/arm64-dts-msm8916-add-missing-phy-cells.patch
queue-4.15/arm64-dts-msm8916-correct-ipc-references-for-smsm.patch
This is a note to let you know that I've just added the patch titled
ARM: pxa/tosa-bt: add MODULE_LICENSE tag
to the 4.15-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-pxa-tosa-bt-add-module_license-tag.patch
and it can be found in the queue-4.15 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 3343647813fdf0f2409fbf5816ee3e0622168079 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 10 Jan 2018 15:40:37 +0100
Subject: ARM: pxa/tosa-bt: add MODULE_LICENSE tag
From: Arnd Bergmann <arnd(a)arndb.de>
commit 3343647813fdf0f2409fbf5816ee3e0622168079 upstream.
Without this tag, we get a build warning:
WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o
For completeness, I'm also adding author and description fields.
Acked-by: Robert Jarzmik <robert.jarzmik(a)free.fr>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-pxa/tosa-bt.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/arm/mach-pxa/tosa-bt.c
+++ b/arch/arm/mach-pxa/tosa-bt.c
@@ -132,3 +132,7 @@ static struct platform_driver tosa_bt_dr
},
};
module_platform_driver(tosa_bt_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Dmitry Baryshkov");
+MODULE_DESCRIPTION("Bluetooth built-in chip control");
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.15/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.15/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.15/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.15/kselftest-fix-oom-in-memory-compaction-test.patch
queue-4.15/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.15/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.15/mm-hide-a-warning-for-compile_test.patch
queue-4.15/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.15/arm-lpc3250-fix-uda1380-gpio-numbers.patch
queue-4.15/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.15/arm-spear13xx-fix-dmas-cells.patch
queue-4.15/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch
queue-4.15/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: s5pv210: add interrupt-parent for ohci
to the 4.15-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-dts-s5pv210-add-interrupt-parent-for-ohci.patch
and it can be found in the queue-4.15 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 5c1037196b9ee75897c211972de370ed1336ec8f Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 10 Jan 2018 17:10:11 +0100
Subject: ARM: dts: s5pv210: add interrupt-parent for ohci
From: Arnd Bergmann <arnd(a)arndb.de>
commit 5c1037196b9ee75897c211972de370ed1336ec8f upstream.
The ohci-hcd node has an interrupt number but no interrupt-parent,
leading to a warning with current dtc versions:
arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
As seen from the related exynos dts files, the ohci and ehci controllers
always share one interrupt number, and the number is the same here as
well, so setting the same interrupt-parent is the reasonable solution
here.
Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/s5pv210.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -463,6 +463,7 @@
compatible = "samsung,exynos4210-ohci";
reg = <0xec300000 0x100>;
interrupts = <23>;
+ interrupt-parent = <&vic1>;
clocks = <&clocks CLK_USB_HOST>;
clock-names = "usbhost";
#address-cells = <1>;
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.15/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.15/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.15/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.15/kselftest-fix-oom-in-memory-compaction-test.patch
queue-4.15/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.15/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.15/mm-hide-a-warning-for-compile_test.patch
queue-4.15/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.15/arm-lpc3250-fix-uda1380-gpio-numbers.patch
queue-4.15/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.15/arm-spear13xx-fix-dmas-cells.patch
queue-4.15/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch
queue-4.15/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
arm: dts: mt7623: Update ethsys binding
to the 4.15-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-dts-mt7623-update-ethsys-binding.patch
and it can be found in the queue-4.15 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 76a09ce214addb8ddc0f6d50dc1106a5f829e713 Mon Sep 17 00:00:00 2001
From: Matthias Brugger <matthias.bgg(a)gmail.com>
Date: Fri, 1 Dec 2017 13:07:07 +0100
Subject: arm: dts: mt7623: Update ethsys binding
From: Matthias Brugger <matthias.bgg(a)gmail.com>
commit 76a09ce214addb8ddc0f6d50dc1106a5f829e713 upstream.
The ethsys binding misses the reset-cells, this patch
adds this property.
Reviewed-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/mt7623.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -758,6 +758,7 @@
"syscon";
reg = <0 0x1b000000 0 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
eth: ethernet@1b100000 {
Patches currently in stable-queue which might be from matthias.bgg(a)gmail.com are
queue-4.15/arm-dts-mt7623-update-ethsys-binding.patch
queue-4.15/arm-dts-mt2701-add-reset-cells.patch
queue-4.15/arm-dts-mt7623-fix-card-detection-issue-on-bananapi-r2.patch
This is a note to let you know that I've just added the patch titled
arm: dts: mt2701: Add reset-cells
to the 4.15-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-dts-mt2701-add-reset-cells.patch
and it can be found in the queue-4.15 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 ae72e95b5e4ded145bfc6926ad9457b74e3af41a Mon Sep 17 00:00:00 2001
From: Matthias Brugger <matthias.bgg(a)gmail.com>
Date: Fri, 1 Dec 2017 13:07:08 +0100
Subject: arm: dts: mt2701: Add reset-cells
From: Matthias Brugger <matthias.bgg(a)gmail.com>
commit ae72e95b5e4ded145bfc6926ad9457b74e3af41a upstream.
The hifsys and ethsys needs the definition of the reset-cells
property. Fix this.
Reviewed-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/mt2701.dtsi | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -604,6 +604,7 @@
compatible = "mediatek,mt2701-hifsys", "syscon";
reg = <0 0x1a000000 0 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
usb0: usb@1a1c0000 {
@@ -688,6 +689,7 @@
compatible = "mediatek,mt2701-ethsys", "syscon";
reg = <0 0x1b000000 0 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
eth: ethernet@1b100000 {
Patches currently in stable-queue which might be from matthias.bgg(a)gmail.com are
queue-4.15/arm-dts-mt7623-update-ethsys-binding.patch
queue-4.15/arm-dts-mt2701-add-reset-cells.patch
queue-4.15/arm-dts-mt7623-fix-card-detection-issue-on-bananapi-r2.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: exynos: fix RTC interrupt for exynos5410
to the 4.15-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-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch
and it can be found in the queue-4.15 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 5628a8ca14149ba4226e3bdce3a04c3b688435ad Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 21 Dec 2017 22:30:07 +0100
Subject: ARM: dts: exynos: fix RTC interrupt for exynos5410
From: Arnd Bergmann <arnd(a)arndb.de>
commit 5628a8ca14149ba4226e3bdce3a04c3b688435ad upstream.
According to the comment added to exynos_dt_pmu_match[] in commit
8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains"),
the RTC is not able to wake up the system through the PMU on Exynos5410,
unlike Exynos5420.
However, when the RTC DT node got added, it was a straight copy of
the Exynos5420 node, which now causes a warning from dtc.
This removes the incorrect interrupt-parent, which should get the
interrupt working and avoid the warning.
Fixes: e1e146b1b062 ("ARM: dts: exynos: Add RTC and I2C to Exynos5410")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/exynos5410.dtsi | 1 -
1 file changed, 1 deletion(-)
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -333,7 +333,6 @@
&rtc {
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
- interrupt-parent = <&pmu_system_controller>;
status = "disabled";
};
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.15/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.15/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.15/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.15/kselftest-fix-oom-in-memory-compaction-test.patch
queue-4.15/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.15/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.15/mm-hide-a-warning-for-compile_test.patch
queue-4.15/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.15/arm-lpc3250-fix-uda1380-gpio-numbers.patch
queue-4.15/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.15/arm-spear13xx-fix-dmas-cells.patch
queue-4.15/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch
queue-4.15/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: Delete bogus reference to the charlcd
to the 4.15-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-dts-delete-bogus-reference-to-the-charlcd.patch
and it can be found in the queue-4.15 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 586b2a4befad88cd87b372a1cea01e58c6811ea9 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Tue, 2 Jan 2018 08:57:17 +0100
Subject: ARM: dts: Delete bogus reference to the charlcd
From: Linus Walleij <linus.walleij(a)linaro.org>
commit 586b2a4befad88cd87b372a1cea01e58c6811ea9 upstream.
The EB MP board probably has a character LCD but the board manual does
not really state which IRQ it has assigned to this device. The invalid
assignment was a mistake by me during submission of the DTSI where I was
looking for the reference, didn't find it and didn't fill it in.
Delete this for now: it can probably be fixed but that requires access
to the actual board for some trial-and-error experiments.
Reported-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Olof Johansson <olof(a)lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/arm-realview-eb-mp.dtsi | 5 -----
1 file changed, 5 deletions(-)
--- a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
+++ b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
@@ -150,11 +150,6 @@
interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
};
-&charlcd {
- interrupt-parent = <&intc>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
-};
-
&serial0 {
interrupt-parent = <&intc>;
interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.15/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.15/mmc-sdhci-implement-an-sdhci-specific-bounce-buffer.patch
queue-4.15/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
scsi: core: check for device state in __scsi_remove_target()
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-check-for-device-state-in-__scsi_remove_target.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 81b6c999897919d5a16fedc018fe375dbab091c5 Mon Sep 17 00:00:00 2001
From: Hannes Reinecke <hare(a)suse.de>
Date: Wed, 13 Dec 2017 14:21:37 +0100
Subject: scsi: core: check for device state in __scsi_remove_target()
From: Hannes Reinecke <hare(a)suse.de>
commit 81b6c999897919d5a16fedc018fe375dbab091c5 upstream.
As it turned out device_get() doesn't use kref_get_unless_zero(), so we
will be always getting a device pointer. Consequently, we need to check
for the device state in __scsi_remove_target() to avoid tripping over
deleted objects.
Fixes: fbce4d97fd43 ("scsi: fixup kernel warning during rmmod()")
Reported-by: Jason Yan <yanaijie(a)huawei.com>
Signed-off-by: Hannes Reinecke <hare(a)suse.com>
Reviewed-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Reviewed-by: Ewan D. Milne <emilne(a)redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Cc: Max Ivanov <ivanov.maxim(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/scsi_sysfs.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1383,7 +1383,10 @@ static void __scsi_remove_target(struct
* check.
*/
if (sdev->channel != starget->channel ||
- sdev->id != starget->id ||
+ sdev->id != starget->id)
+ continue;
+ if (sdev->sdev_state == SDEV_DEL ||
+ sdev->sdev_state == SDEV_CANCEL ||
!get_device(&sdev->sdev_gendev))
continue;
spin_unlock_irqrestore(shost->host_lock, flags);
Patches currently in stable-queue which might be from hare(a)suse.de are
queue-4.14/scsi-core-check-for-device-state-in-__scsi_remove_target.patch
This is a note to let you know that I've just added the patch titled
ovl: hash directory inodes for fsnotify
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-hash-directory-inodes-for-fsnotify.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 31747eda41ef3c30c09c5c096b380bf54013746a Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Sun, 14 Jan 2018 18:35:40 +0200
Subject: ovl: hash directory inodes for fsnotify
From: Amir Goldstein <amir73il(a)gmail.com>
commit 31747eda41ef3c30c09c5c096b380bf54013746a upstream.
fsnotify pins a watched directory inode in cache, but if directory dentry
is released, new lookup will allocate a new dentry and a new inode.
Directory events will be notified on the new inode, while fsnotify listener
is watching the old pinned inode.
Hash all directory inodes to reuse the pinned inode on lookup. Pure upper
dirs are hashes by real upper inode, merge and lower dirs are hashed by
real lower inode.
The reference to lower inode was being held by the lower dentry object
in the overlay dentry (oe->lowerstack[0]). Releasing the overlay dentry
may drop lower inode refcount to zero. Add a refcount on behalf of the
overlay inode to prevent that.
As a by-product, hashing directory inodes also detects multiple
redirected dirs to the same lower dir and uncovered redirected dir
target on and returns -ESTALE on lookup.
The reported issue dates back to initial version of overlayfs, but this
patch depends on ovl_inode code that was introduced in kernel v4.13.
Cc: <stable(a)vger.kernel.org> #v4.13
Reported-by: Niklas Cassel <niklas.cassel(a)axis.com>
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Tested-by: Niklas Cassel <niklas.cassel(a)axis.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/overlayfs/inode.c | 37 +++++++++++++++++++++++++++----------
fs/overlayfs/super.c | 1 +
fs/overlayfs/util.c | 4 ++--
3 files changed, 30 insertions(+), 12 deletions(-)
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -579,6 +579,16 @@ static int ovl_inode_set(struct inode *i
static bool ovl_verify_inode(struct inode *inode, struct dentry *lowerdentry,
struct dentry *upperdentry)
{
+ if (S_ISDIR(inode->i_mode)) {
+ /* Real lower dir moved to upper layer under us? */
+ if (!lowerdentry && ovl_inode_lower(inode))
+ return false;
+
+ /* Lookup of an uncovered redirect origin? */
+ if (!upperdentry && ovl_inode_upper(inode))
+ return false;
+ }
+
/*
* Allow non-NULL lower inode in ovl_inode even if lowerdentry is NULL.
* This happens when finding a copied up overlay inode for a renamed
@@ -606,6 +616,8 @@ struct inode *ovl_get_inode(struct dentr
struct inode *inode;
/* Already indexed or could be indexed on copy up? */
bool indexed = (index || (ovl_indexdir(dentry->d_sb) && !upperdentry));
+ struct dentry *origin = indexed ? lowerdentry : NULL;
+ bool is_dir;
if (WARN_ON(upperdentry && indexed && !lowerdentry))
return ERR_PTR(-EIO);
@@ -614,15 +626,19 @@ struct inode *ovl_get_inode(struct dentr
realinode = d_inode(lowerdentry);
/*
- * Copy up origin (lower) may exist for non-indexed upper, but we must
- * not use lower as hash key in that case.
- * Hash inodes that are or could be indexed by origin inode and
- * non-indexed upper inodes that could be hard linked by upper inode.
+ * Copy up origin (lower) may exist for non-indexed non-dir upper, but
+ * we must not use lower as hash key in that case.
+ * Hash non-dir that is or could be indexed by origin inode.
+ * Hash dir that is or could be merged by origin inode.
+ * Hash pure upper and non-indexed non-dir by upper inode.
*/
- if (!S_ISDIR(realinode->i_mode) && (upperdentry || indexed)) {
- struct inode *key = d_inode(indexed ? lowerdentry :
- upperdentry);
- unsigned int nlink;
+ is_dir = S_ISDIR(realinode->i_mode);
+ if (is_dir)
+ origin = lowerdentry;
+
+ if (upperdentry || origin) {
+ struct inode *key = d_inode(origin ?: upperdentry);
+ unsigned int nlink = is_dir ? 1 : realinode->i_nlink;
inode = iget5_locked(dentry->d_sb, (unsigned long) key,
ovl_inode_test, ovl_inode_set, key);
@@ -643,8 +659,9 @@ struct inode *ovl_get_inode(struct dentr
goto out;
}
- nlink = ovl_get_nlink(lowerdentry, upperdentry,
- realinode->i_nlink);
+ /* Recalculate nlink for non-dir due to indexing */
+ if (!is_dir)
+ nlink = ovl_get_nlink(lowerdentry, upperdentry, nlink);
set_nlink(inode, nlink);
} else {
inode = new_inode(dentry->d_sb);
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -200,6 +200,7 @@ static void ovl_destroy_inode(struct ino
struct ovl_inode *oi = OVL_I(inode);
dput(oi->__upperdentry);
+ iput(oi->lower);
kfree(oi->redirect);
ovl_dir_cache_free(inode);
mutex_destroy(&oi->lock);
--- a/fs/overlayfs/util.c
+++ b/fs/overlayfs/util.c
@@ -253,7 +253,7 @@ void ovl_inode_init(struct inode *inode,
if (upperdentry)
OVL_I(inode)->__upperdentry = upperdentry;
if (lowerdentry)
- OVL_I(inode)->lower = d_inode(lowerdentry);
+ OVL_I(inode)->lower = igrab(d_inode(lowerdentry));
ovl_copyattr(d_inode(upperdentry ?: lowerdentry), inode);
}
@@ -269,7 +269,7 @@ void ovl_inode_update(struct inode *inod
*/
smp_wmb();
OVL_I(inode)->__upperdentry = upperdentry;
- if (!S_ISDIR(upperinode->i_mode) && inode_unhashed(inode)) {
+ if (inode_unhashed(inode)) {
inode->i_private = upperinode;
__insert_inode_hash(inode, (unsigned long) upperinode);
}
Patches currently in stable-queue which might be from amir73il(a)gmail.com are
queue-4.14/ovl-hash-directory-inodes-for-fsnotify.patch
This is a note to let you know that I've just added the patch titled
mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb
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-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.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 f2bc600008bd6f7f5d0b6b56238d14f95cd454d2 Mon Sep 17 00:00:00 2001
From: "yinbo.zhu" <yinbo.zhu(a)nxp.com>
Date: Fri, 1 Dec 2017 15:09:34 +0800
Subject: mmc: sdhci-of-esdhc: fix the mmc error after sleep on ls1046ardb
From: yinbo.zhu <yinbo.zhu(a)nxp.com>
commit f2bc600008bd6f7f5d0b6b56238d14f95cd454d2 upstream.
When system wakes up from sleep on ls1046ardb, the SD operation fails
with mmc error messages since ESDHC_TB_EN bit couldn't be cleaned by
eSDHC_SYSCTL[RSTA]. It's proper to clean this bit in esdhc_reset()
rather than in probe.
Signed-off-by: yinbo.zhu <yinbo.zhu(a)nxp.com>
Acked-by: Yangbo Lu <yangbo.lu(a)nxp.com>
Acked-by: Adrian Hunter <adrian.hunter(a)intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Cc: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/sdhci-of-esdhc.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -589,10 +589,18 @@ static void esdhc_pltfm_set_bus_width(st
static void esdhc_reset(struct sdhci_host *host, u8 mask)
{
+ u32 val;
+
sdhci_reset(host, mask);
sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
+
+ if (mask & SDHCI_RESET_ALL) {
+ val = sdhci_readl(host, ESDHC_TBCTL);
+ val &= ~ESDHC_TB_EN;
+ sdhci_writel(host, val, ESDHC_TBCTL);
+ }
}
/* The SCFG, Supplemental Configuration Unit, provides SoC specific
@@ -785,10 +793,6 @@ static void esdhc_init(struct platform_d
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
- val = sdhci_readl(host, ESDHC_TBCTL);
- val &= ~ESDHC_TB_EN;
- sdhci_writel(host, val, ESDHC_TBCTL);
-
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
Patches currently in stable-queue which might be from yinbo.zhu(a)nxp.com are
queue-4.14/mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch
queue-4.14/mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch
This is a note to let you know that I've just added the patch titled
mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec
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-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.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 97618aca1440b5addc5c3d78659d3e176be23b80 Mon Sep 17 00:00:00 2001
From: "yinbo.zhu" <yinbo.zhu(a)nxp.com>
Date: Wed, 8 Nov 2017 17:09:50 +0800
Subject: mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec
From: yinbo.zhu <yinbo.zhu(a)nxp.com>
commit 97618aca1440b5addc5c3d78659d3e176be23b80 upstream.
The bit eSDHC_TBCTL[TB_EN] couldn't be reset by eSDHC_SYSCTL[RSTA] which is
used to reset for all. The driver should make sure it's cleared before card
initialization, otherwise the initialization would fail.
Signed-off-by: yinbo.zhu <yinbo.zhu(a)nxp.com>
Acked-by: Adrian Hunter <adrian.hunter(a)intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Cc: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/sdhci-of-esdhc.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -785,6 +785,10 @@ static void esdhc_init(struct platform_d
pltfm_host = sdhci_priv(host);
esdhc = sdhci_pltfm_priv(pltfm_host);
+ val = sdhci_readl(host, ESDHC_TBCTL);
+ val &= ~ESDHC_TB_EN;
+ sdhci_writel(host, val, ESDHC_TBCTL);
+
host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
SDHCI_VENDOR_VER_SHIFT;
Patches currently in stable-queue which might be from yinbo.zhu(a)nxp.com are
queue-4.14/mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch
queue-4.14/mmc-sdhci-of-esdhc-fix-emmc-couldn-t-work-after-kexec.patch
This is a note to let you know that I've just added the patch titled
mmc: sdhci-of-esdhc: disable SD clock for clock value 0
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-sdhci-of-esdhc-disable-sd-clock-for-clock-value-0.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 dd3f6983b4a468efca9e8caa0e2b4aa20946d801 Mon Sep 17 00:00:00 2001
From: yangbo lu <yangbo.lu(a)nxp.com>
Date: Thu, 21 Sep 2017 16:43:31 +0800
Subject: mmc: sdhci-of-esdhc: disable SD clock for clock value 0
From: yangbo lu <yangbo.lu(a)nxp.com>
commit dd3f6983b4a468efca9e8caa0e2b4aa20946d801 upstream.
SD clock should be disabled for clock value 0. It's not
right to just return. This may cause failure of signal
voltage switching.
Signed-off-by: Yangbo Lu <yangbo.lu(a)nxp.com>
Acked-by: Adrian Hunter <adrian.hunter(a)intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Cc: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/sdhci-of-esdhc.c | 58 +++++++++++++++++++-------------------
1 file changed, 30 insertions(+), 28 deletions(-)
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -458,6 +458,33 @@ static unsigned int esdhc_of_get_min_clo
return clock / 256 / 16;
}
+static void esdhc_clock_enable(struct sdhci_host *host, bool enable)
+{
+ u32 val;
+ ktime_t timeout;
+
+ val = sdhci_readl(host, ESDHC_SYSTEM_CONTROL);
+
+ if (enable)
+ val |= ESDHC_CLOCK_SDCLKEN;
+ else
+ val &= ~ESDHC_CLOCK_SDCLKEN;
+
+ sdhci_writel(host, val, ESDHC_SYSTEM_CONTROL);
+
+ /* Wait max 20 ms */
+ timeout = ktime_add_ms(ktime_get(), 20);
+ val = ESDHC_CLOCK_STABLE;
+ while (!(sdhci_readl(host, ESDHC_PRSSTAT) & val)) {
+ if (ktime_after(ktime_get(), timeout)) {
+ pr_err("%s: Internal clock never stabilised.\n",
+ mmc_hostname(host->mmc));
+ break;
+ }
+ udelay(10);
+ }
+}
+
static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock)
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -469,8 +496,10 @@ static void esdhc_of_set_clock(struct sd
host->mmc->actual_clock = 0;
- if (clock == 0)
+ if (clock == 0) {
+ esdhc_clock_enable(host, false);
return;
+ }
/* Workaround to start pre_div at 2 for VNN < VENDOR_V_23 */
if (esdhc->vendor_ver < VENDOR_V_23)
@@ -558,33 +587,6 @@ static void esdhc_pltfm_set_bus_width(st
sdhci_writel(host, ctrl, ESDHC_PROCTL);
}
-static void esdhc_clock_enable(struct sdhci_host *host, bool enable)
-{
- u32 val;
- ktime_t timeout;
-
- val = sdhci_readl(host, ESDHC_SYSTEM_CONTROL);
-
- if (enable)
- val |= ESDHC_CLOCK_SDCLKEN;
- else
- val &= ~ESDHC_CLOCK_SDCLKEN;
-
- sdhci_writel(host, val, ESDHC_SYSTEM_CONTROL);
-
- /* Wait max 20 ms */
- timeout = ktime_add_ms(ktime_get(), 20);
- val = ESDHC_CLOCK_STABLE;
- while (!(sdhci_readl(host, ESDHC_PRSSTAT) & val)) {
- if (ktime_after(ktime_get(), timeout)) {
- pr_err("%s: Internal clock never stabilised.\n",
- mmc_hostname(host->mmc));
- break;
- }
- udelay(10);
- }
-}
-
static void esdhc_reset(struct sdhci_host *host, u8 mask)
{
sdhci_reset(host, mask);
Patches currently in stable-queue which might be from yangbo.lu(a)nxp.com are
queue-4.14/mmc-sdhci-of-esdhc-fix-the-mmc-error-after-sleep-on-ls1046ardb.patch
queue-4.14/mmc-sdhci-of-esdhc-disable-sd-clock-for-clock-value-0.patch
This is a note to let you know that I've just added the patch titled
media: r820t: fix r820t_write_reg for KASAN
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-r820t-fix-r820t_write_reg-for-kasan.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 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 30 Nov 2017 06:08:05 -0500
Subject: media: r820t: fix r820t_write_reg for KASAN
From: Arnd Bergmann <arnd(a)arndb.de>
commit 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 upstream.
With CONFIG_KASAN, we get an overly long stack frame due to inlining
the register access functions:
drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
This is caused by a gcc bug that has now been fixed in gcc-8.
To work around the problem, we can pass the register data
through a local variable that older gcc versions can optimize
out as well.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/tuners/r820t.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -396,9 +396,11 @@ static int r820t_write(struct r820t_priv
return 0;
}
-static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
+static inline int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
{
- return r820t_write(priv, reg, &val, 1);
+ u8 tmp = val; /* work around GCC PR81715 with asan-stack=1 */
+
+ return r820t_write(priv, reg, &tmp, 1);
}
static int r820t_read_cache_reg(struct r820t_priv *priv, int reg)
@@ -411,17 +413,18 @@ static int r820t_read_cache_reg(struct r
return -EINVAL;
}
-static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
+static inline int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
u8 bit_mask)
{
+ u8 tmp = val;
int rc = r820t_read_cache_reg(priv, reg);
if (rc < 0)
return rc;
- val = (rc & ~bit_mask) | (val & bit_mask);
+ tmp = (rc & ~bit_mask) | (tmp & bit_mask);
- return r820t_write(priv, reg, &val, 1);
+ return r820t_write(priv, reg, &tmp, 1);
}
static int r820t_read(struct r820t_priv *priv, u8 reg, u8 *val, int len)
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.14/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.14/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.14/kselftest-fix-oom-in-memory-compaction-test.patch
queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.14/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.14/mm-hide-a-warning-for-compile_test.patch
queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch
queue-4.14/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.14/arm-lpc3250-fix-uda1380-gpio-numbers.patch
queue-4.14/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.14/bluetooth-bt_hciuart-now-depends-on-serial_dev_bus.patch
queue-4.14/arm-spear13xx-fix-dmas-cells.patch
queue-4.14/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch
queue-4.14/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: BT_HCIUART now depends on SERIAL_DEV_BUS
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:
bluetooth-bt_hciuart-now-depends-on-serial_dev_bus.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 05e89fb576f580ac95e7a5d00bdb34830b09671a Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 11 Oct 2017 15:47:54 +0200
Subject: Bluetooth: BT_HCIUART now depends on SERIAL_DEV_BUS
From: Arnd Bergmann <arnd(a)arndb.de>
commit 05e89fb576f580ac95e7a5d00bdb34830b09671a upstream.
It is no longer possible to build BT_HCIUART into the kernel
when SERIAL_DEV_BUS is a loadable module, even if none of the
SERIAL_DEV_BUS based implementations are selected:
drivers/bluetooth/hci_ldisc.o: In function `hci_uart_set_flow_control':
hci_ldisc.c:(.text+0xb40): undefined reference to `serdev_device_set_flow_control'
hci_ldisc.c:(.text+0xb5c): undefined reference to `serdev_device_set_tiocm'
This adds a dependency to avoid the broken configuration.
Fixes: 7841d554809b ("Bluetooth: hci_uart_set_flow_control: Fix NULL deref when using serdev")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -66,6 +66,7 @@ config BT_HCIBTSDIO
config BT_HCIUART
tristate "HCI UART driver"
+ depends on SERIAL_DEV_BUS || !SERIAL_DEV_BUS
depends on TTY
help
Bluetooth HCI UART driver.
@@ -80,7 +81,6 @@ config BT_HCIUART
config BT_HCIUART_SERDEV
bool
depends on SERIAL_DEV_BUS && BT_HCIUART
- depends on SERIAL_DEV_BUS=y || SERIAL_DEV_BUS=BT_HCIUART
default y
config BT_HCIUART_H4
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.14/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.14/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.14/kselftest-fix-oom-in-memory-compaction-test.patch
queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.14/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.14/mm-hide-a-warning-for-compile_test.patch
queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch
queue-4.14/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.14/arm-lpc3250-fix-uda1380-gpio-numbers.patch
queue-4.14/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.14/bluetooth-bt_hciuart-now-depends-on-serial_dev_bus.patch
queue-4.14/arm-spear13xx-fix-dmas-cells.patch
queue-4.14/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch
queue-4.14/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
ASoC: acpi: fix machine driver selection based on quirk
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:
asoc-acpi-fix-machine-driver-selection-based-on-quirk.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 5c256045b87b8aa8e5bc9d2e2fdc0802351c1f99 Mon Sep 17 00:00:00 2001
From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>
Date: Fri, 5 Jan 2018 14:55:33 -0600
Subject: ASoC: acpi: fix machine driver selection based on quirk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>
commit 5c256045b87b8aa8e5bc9d2e2fdc0802351c1f99 upstream.
The ACPI/machine-driver code refactoring introduced in 4.13 introduced
a regression for cases where we need a DMI-based quirk to select the
machine driver (the BIOS reports an invalid HID). The fix is just to
make sure the results of the quirk are actually used.
Fixes: 54746dabf770 ('ASoC: Improve machine driver selection based on quirk data')
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96691
Tested-by: Nicole Færber <nicole.faerber(a)dpin.de>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/intel/common/sst-match-acpi.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/sound/soc/intel/common/sst-match-acpi.c
+++ b/sound/soc/intel/common/sst-match-acpi.c
@@ -83,11 +83,9 @@ struct sst_acpi_mach *sst_acpi_find_mach
for (mach = machines; mach->id[0]; mach++) {
if (sst_acpi_check_hid(mach->id) == true) {
- if (mach->machine_quirk == NULL)
- return mach;
-
- if (mach->machine_quirk(mach) != NULL)
- return mach;
+ if (mach->machine_quirk)
+ mach = mach->machine_quirk(mach);
+ return mach;
}
}
return NULL;
Patches currently in stable-queue which might be from pierre-louis.bossart(a)linux.intel.com are
queue-4.14/asoc-acpi-fix-machine-driver-selection-based-on-quirk.patch
This is a note to let you know that I've just added the patch titled
arm64: dts: msm8916: Add missing #phy-cells
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-dts-msm8916-add-missing-phy-cells.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 b0ab681285aa66064f2de5b74191c0cabba381ff Mon Sep 17 00:00:00 2001
From: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Date: Tue, 7 Nov 2017 19:45:01 -0800
Subject: arm64: dts: msm8916: Add missing #phy-cells
From: Bjorn Andersson <bjorn.andersson(a)linaro.org>
commit b0ab681285aa66064f2de5b74191c0cabba381ff upstream.
Add a missing #phy-cells to the dsi-phy, to silence dtc warning.
Cc: Archit Taneja <architt(a)codeaurora.org>
Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support")
Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Reviewed-by: Archit Taneja <architt(a)codeaurora.org>
Signed-off-by: Andy Gross <andy.gross(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -901,6 +901,7 @@
"dsi_phy_regulator";
#clock-cells = <1>;
+ #phy-cells = <0>;
clocks = <&gcc GCC_MDSS_AHB_CLK>;
clock-names = "iface_clk";
Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are
queue-4.14/pm-devfreq-propagate-error-from-devfreq_add_device.patch
queue-4.14/arm64-dts-msm8916-add-missing-phy-cells.patch
queue-4.14/arm64-dts-msm8916-correct-ipc-references-for-smsm.patch
This is a note to let you know that I've just added the patch titled
ARM: pxa/tosa-bt: add MODULE_LICENSE tag
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:
arm-pxa-tosa-bt-add-module_license-tag.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 3343647813fdf0f2409fbf5816ee3e0622168079 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 10 Jan 2018 15:40:37 +0100
Subject: ARM: pxa/tosa-bt: add MODULE_LICENSE tag
From: Arnd Bergmann <arnd(a)arndb.de>
commit 3343647813fdf0f2409fbf5816ee3e0622168079 upstream.
Without this tag, we get a build warning:
WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o
For completeness, I'm also adding author and description fields.
Acked-by: Robert Jarzmik <robert.jarzmik(a)free.fr>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-pxa/tosa-bt.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/arm/mach-pxa/tosa-bt.c
+++ b/arch/arm/mach-pxa/tosa-bt.c
@@ -132,3 +132,7 @@ static struct platform_driver tosa_bt_dr
},
};
module_platform_driver(tosa_bt_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Dmitry Baryshkov");
+MODULE_DESCRIPTION("Bluetooth built-in chip control");
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.14/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.14/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.14/kselftest-fix-oom-in-memory-compaction-test.patch
queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.14/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.14/mm-hide-a-warning-for-compile_test.patch
queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch
queue-4.14/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.14/arm-lpc3250-fix-uda1380-gpio-numbers.patch
queue-4.14/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.14/bluetooth-bt_hciuart-now-depends-on-serial_dev_bus.patch
queue-4.14/arm-spear13xx-fix-dmas-cells.patch
queue-4.14/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch
queue-4.14/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: s5pv210: add interrupt-parent for ohci
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:
arm-dts-s5pv210-add-interrupt-parent-for-ohci.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 5c1037196b9ee75897c211972de370ed1336ec8f Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 10 Jan 2018 17:10:11 +0100
Subject: ARM: dts: s5pv210: add interrupt-parent for ohci
From: Arnd Bergmann <arnd(a)arndb.de>
commit 5c1037196b9ee75897c211972de370ed1336ec8f upstream.
The ohci-hcd node has an interrupt number but no interrupt-parent,
leading to a warning with current dtc versions:
arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
As seen from the related exynos dts files, the ohci and ehci controllers
always share one interrupt number, and the number is the same here as
well, so setting the same interrupt-parent is the reasonable solution
here.
Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/s5pv210.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -463,6 +463,7 @@
compatible = "samsung,exynos4210-ohci";
reg = <0xec300000 0x100>;
interrupts = <23>;
+ interrupt-parent = <&vic1>;
clocks = <&clocks CLK_USB_HOST>;
clock-names = "usbhost";
#address-cells = <1>;
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.14/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.14/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.14/kselftest-fix-oom-in-memory-compaction-test.patch
queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.14/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.14/mm-hide-a-warning-for-compile_test.patch
queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch
queue-4.14/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.14/arm-lpc3250-fix-uda1380-gpio-numbers.patch
queue-4.14/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.14/bluetooth-bt_hciuart-now-depends-on-serial_dev_bus.patch
queue-4.14/arm-spear13xx-fix-dmas-cells.patch
queue-4.14/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch
queue-4.14/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
arm: dts: mt7623: Update ethsys binding
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:
arm-dts-mt7623-update-ethsys-binding.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 76a09ce214addb8ddc0f6d50dc1106a5f829e713 Mon Sep 17 00:00:00 2001
From: Matthias Brugger <matthias.bgg(a)gmail.com>
Date: Fri, 1 Dec 2017 13:07:07 +0100
Subject: arm: dts: mt7623: Update ethsys binding
From: Matthias Brugger <matthias.bgg(a)gmail.com>
commit 76a09ce214addb8ddc0f6d50dc1106a5f829e713 upstream.
The ethsys binding misses the reset-cells, this patch
adds this property.
Reviewed-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/mt7623.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -753,6 +753,7 @@
"syscon";
reg = <0 0x1b000000 0 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
eth: ethernet@1b100000 {
Patches currently in stable-queue which might be from matthias.bgg(a)gmail.com are
queue-4.14/arm-dts-mt7623-update-ethsys-binding.patch
queue-4.14/arm-dts-mt2701-add-reset-cells.patch
queue-4.14/arm-dts-mt7623-fix-card-detection-issue-on-bananapi-r2.patch
This is a note to let you know that I've just added the patch titled
arm: dts: mt2701: Add reset-cells
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:
arm-dts-mt2701-add-reset-cells.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 ae72e95b5e4ded145bfc6926ad9457b74e3af41a Mon Sep 17 00:00:00 2001
From: Matthias Brugger <matthias.bgg(a)gmail.com>
Date: Fri, 1 Dec 2017 13:07:08 +0100
Subject: arm: dts: mt2701: Add reset-cells
From: Matthias Brugger <matthias.bgg(a)gmail.com>
commit ae72e95b5e4ded145bfc6926ad9457b74e3af41a upstream.
The hifsys and ethsys needs the definition of the reset-cells
property. Fix this.
Reviewed-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Matthias Brugger <matthias.bgg(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/mt2701.dtsi | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -593,6 +593,7 @@
compatible = "mediatek,mt2701-hifsys", "syscon";
reg = <0 0x1a000000 0 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
usb0: usb@1a1c0000 {
@@ -677,6 +678,7 @@
compatible = "mediatek,mt2701-ethsys", "syscon";
reg = <0 0x1b000000 0 0x1000>;
#clock-cells = <1>;
+ #reset-cells = <1>;
};
eth: ethernet@1b100000 {
Patches currently in stable-queue which might be from matthias.bgg(a)gmail.com are
queue-4.14/arm-dts-mt7623-update-ethsys-binding.patch
queue-4.14/arm-dts-mt2701-add-reset-cells.patch
queue-4.14/arm-dts-mt7623-fix-card-detection-issue-on-bananapi-r2.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: exynos: fix RTC interrupt for exynos5410
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:
arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.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 5628a8ca14149ba4226e3bdce3a04c3b688435ad Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 21 Dec 2017 22:30:07 +0100
Subject: ARM: dts: exynos: fix RTC interrupt for exynos5410
From: Arnd Bergmann <arnd(a)arndb.de>
commit 5628a8ca14149ba4226e3bdce3a04c3b688435ad upstream.
According to the comment added to exynos_dt_pmu_match[] in commit
8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains"),
the RTC is not able to wake up the system through the PMU on Exynos5410,
unlike Exynos5420.
However, when the RTC DT node got added, it was a straight copy of
the Exynos5420 node, which now causes a warning from dtc.
This removes the incorrect interrupt-parent, which should get the
interrupt working and avoid the warning.
Fixes: e1e146b1b062 ("ARM: dts: exynos: Add RTC and I2C to Exynos5410")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/exynos5410.dtsi | 1 -
1 file changed, 1 deletion(-)
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -333,7 +333,6 @@
&rtc {
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
- interrupt-parent = <&pmu_system_controller>;
status = "disabled";
};
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.14/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.14/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.14/kselftest-fix-oom-in-memory-compaction-test.patch
queue-4.14/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.14/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.14/mm-hide-a-warning-for-compile_test.patch
queue-4.14/tracing-prevent-profile_all_branches-when-fortify_source-y.patch
queue-4.14/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.14/arm-lpc3250-fix-uda1380-gpio-numbers.patch
queue-4.14/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.14/bluetooth-bt_hciuart-now-depends-on-serial_dev_bus.patch
queue-4.14/arm-spear13xx-fix-dmas-cells.patch
queue-4.14/arm-dts-exynos-fix-rtc-interrupt-for-exynos5410.patch
queue-4.14/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: Delete bogus reference to the charlcd
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:
arm-dts-delete-bogus-reference-to-the-charlcd.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 586b2a4befad88cd87b372a1cea01e58c6811ea9 Mon Sep 17 00:00:00 2001
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Tue, 2 Jan 2018 08:57:17 +0100
Subject: ARM: dts: Delete bogus reference to the charlcd
From: Linus Walleij <linus.walleij(a)linaro.org>
commit 586b2a4befad88cd87b372a1cea01e58c6811ea9 upstream.
The EB MP board probably has a character LCD but the board manual does
not really state which IRQ it has assigned to this device. The invalid
assignment was a mistake by me during submission of the DTSI where I was
looking for the reference, didn't find it and didn't fill it in.
Delete this for now: it can probably be fixed but that requires access
to the actual board for some trial-and-error experiments.
Reported-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Olof Johansson <olof(a)lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/arm-realview-eb-mp.dtsi | 5 -----
1 file changed, 5 deletions(-)
--- a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
+++ b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
@@ -150,11 +150,6 @@
interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
};
-&charlcd {
- interrupt-parent = <&intc>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
-};
-
&serial0 {
interrupt-parent = <&intc>;
interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-4.14/arm-dts-delete-bogus-reference-to-the-charlcd.patch
queue-4.14/mmc-sdhci-implement-an-sdhci-specific-bounce-buffer.patch
queue-4.14/arm-dts-nomadik-add-interrupt-parent-for-clcd.patch
This is a note to let you know that I've just added the patch titled
ARM: pxa/tosa-bt: add MODULE_LICENSE tag
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-pxa-tosa-bt-add-module_license-tag.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 3343647813fdf0f2409fbf5816ee3e0622168079 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 10 Jan 2018 15:40:37 +0100
Subject: ARM: pxa/tosa-bt: add MODULE_LICENSE tag
From: Arnd Bergmann <arnd(a)arndb.de>
commit 3343647813fdf0f2409fbf5816ee3e0622168079 upstream.
Without this tag, we get a build warning:
WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o
For completeness, I'm also adding author and description fields.
Acked-by: Robert Jarzmik <robert.jarzmik(a)free.fr>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/mach-pxa/tosa-bt.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/arm/mach-pxa/tosa-bt.c
+++ b/arch/arm/mach-pxa/tosa-bt.c
@@ -132,3 +132,7 @@ static struct platform_driver tosa_bt_dr
},
};
module_platform_driver(tosa_bt_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Dmitry Baryshkov");
+MODULE_DESCRIPTION("Bluetooth built-in chip control");
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.4/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.4/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.4/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.4/x86-fix-build-warnign-with-32-bit-pae.patch
queue-4.4/mm-hide-a-warning-for-compile_test.patch
queue-4.4/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.4/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.4/arm-spear13xx-fix-dmas-cells.patch
This is a note to let you know that I've just added the patch titled
media: r820t: fix r820t_write_reg for KASAN
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:
media-r820t-fix-r820t_write_reg-for-kasan.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 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 30 Nov 2017 06:08:05 -0500
Subject: media: r820t: fix r820t_write_reg for KASAN
From: Arnd Bergmann <arnd(a)arndb.de>
commit 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 upstream.
With CONFIG_KASAN, we get an overly long stack frame due to inlining
the register access functions:
drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
This is caused by a gcc bug that has now been fixed in gcc-8.
To work around the problem, we can pass the register data
through a local variable that older gcc versions can optimize
out as well.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/tuners/r820t.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -410,9 +410,11 @@ static int r820t_write(struct r820t_priv
return 0;
}
-static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
+static inline int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
{
- return r820t_write(priv, reg, &val, 1);
+ u8 tmp = val; /* work around GCC PR81715 with asan-stack=1 */
+
+ return r820t_write(priv, reg, &tmp, 1);
}
static int r820t_read_cache_reg(struct r820t_priv *priv, int reg)
@@ -425,17 +427,18 @@ static int r820t_read_cache_reg(struct r
return -EINVAL;
}
-static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
+static inline int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
u8 bit_mask)
{
+ u8 tmp = val;
int rc = r820t_read_cache_reg(priv, reg);
if (rc < 0)
return rc;
- val = (rc & ~bit_mask) | (val & bit_mask);
+ tmp = (rc & ~bit_mask) | (tmp & bit_mask);
- return r820t_write(priv, reg, &val, 1);
+ return r820t_write(priv, reg, &tmp, 1);
}
static int r820t_read(struct r820t_priv *priv, u8 reg, u8 *val, int len)
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.4/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.4/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.4/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.4/x86-fix-build-warnign-with-32-bit-pae.patch
queue-4.4/mm-hide-a-warning-for-compile_test.patch
queue-4.4/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.4/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.4/arm-spear13xx-fix-dmas-cells.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: s5pv210: add interrupt-parent for ohci
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-dts-s5pv210-add-interrupt-parent-for-ohci.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 5c1037196b9ee75897c211972de370ed1336ec8f Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 10 Jan 2018 17:10:11 +0100
Subject: ARM: dts: s5pv210: add interrupt-parent for ohci
From: Arnd Bergmann <arnd(a)arndb.de>
commit 5c1037196b9ee75897c211972de370ed1336ec8f upstream.
The ohci-hcd node has an interrupt number but no interrupt-parent,
leading to a warning with current dtc versions:
arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
As seen from the related exynos dts files, the ohci and ehci controllers
always share one interrupt number, and the number is the same here as
well, so setting the same interrupt-parent is the reasonable solution
here.
Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/s5pv210.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -461,6 +461,7 @@
compatible = "samsung,exynos4210-ohci";
reg = <0xec300000 0x100>;
interrupts = <23>;
+ interrupt-parent = <&vic1>;
clocks = <&clocks CLK_USB_HOST>;
clock-names = "usbhost";
#address-cells = <1>;
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-4.4/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-4.4/arm-dts-sti-add-gpio-polarity-for-hdmi-hpd-gpio-property.patch
queue-4.4/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-4.4/x86-fix-build-warnign-with-32-bit-pae.patch
queue-4.4/mm-hide-a-warning-for-compile_test.patch
queue-4.4/arm-pxa-tosa-bt-add-module_license-tag.patch
queue-4.4/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-4.4/arm-spear13xx-fix-dmas-cells.patch
This is a note to let you know that I've just added the patch titled
media: r820t: fix r820t_write_reg for KASAN
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:
media-r820t-fix-r820t_write_reg-for-kasan.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 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 30 Nov 2017 06:08:05 -0500
Subject: media: r820t: fix r820t_write_reg for KASAN
From: Arnd Bergmann <arnd(a)arndb.de>
commit 16c3ada89cff9a8c2a0eea34ffa1aa20af3f6008 upstream.
With CONFIG_KASAN, we get an overly long stack frame due to inlining
the register access functions:
drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7':
drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
This is caused by a gcc bug that has now been fixed in gcc-8.
To work around the problem, we can pass the register data
through a local variable that older gcc versions can optimize
out as well.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/tuners/r820t.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -410,9 +410,11 @@ static int r820t_write(struct r820t_priv
return 0;
}
-static int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
+static inline int r820t_write_reg(struct r820t_priv *priv, u8 reg, u8 val)
{
- return r820t_write(priv, reg, &val, 1);
+ u8 tmp = val; /* work around GCC PR81715 with asan-stack=1 */
+
+ return r820t_write(priv, reg, &tmp, 1);
}
static int r820t_read_cache_reg(struct r820t_priv *priv, int reg)
@@ -425,17 +427,18 @@ static int r820t_read_cache_reg(struct r
return -EINVAL;
}
-static int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
+static inline int r820t_write_reg_mask(struct r820t_priv *priv, u8 reg, u8 val,
u8 bit_mask)
{
+ u8 tmp = val;
int rc = r820t_read_cache_reg(priv, reg);
if (rc < 0)
return rc;
- val = (rc & ~bit_mask) | (val & bit_mask);
+ tmp = (rc & ~bit_mask) | (tmp & bit_mask);
- return r820t_write(priv, reg, &val, 1);
+ return r820t_write(priv, reg, &tmp, 1);
}
static int r820t_read(struct r820t_priv *priv, u8 reg, u8 *val, int len)
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-3.18/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-3.18/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-3.18/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-3.18/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-3.18/arm-spear13xx-fix-dmas-cells.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: s5pv210: add interrupt-parent for ohci
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-dts-s5pv210-add-interrupt-parent-for-ohci.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 5c1037196b9ee75897c211972de370ed1336ec8f Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 10 Jan 2018 17:10:11 +0100
Subject: ARM: dts: s5pv210: add interrupt-parent for ohci
From: Arnd Bergmann <arnd(a)arndb.de>
commit 5c1037196b9ee75897c211972de370ed1336ec8f upstream.
The ohci-hcd node has an interrupt number but no interrupt-parent,
leading to a warning with current dtc versions:
arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
As seen from the related exynos dts files, the ohci and ehci controllers
always share one interrupt number, and the number is the same here as
well, so setting the same interrupt-parent is the reasonable solution
here.
Reviewed-by: Krzysztof Kozlowski <krzk(a)kernel.org>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/s5pv210.dtsi | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -461,6 +461,7 @@
compatible = "samsung,exynos4210-ohci";
reg = <0xec300000 0x100>;
interrupts = <23>;
+ interrupt-parent = <&vic1>;
clocks = <&clocks CLK_USB_HOST>;
clock-names = "usbhost";
#address-cells = <1>;
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-3.18/arm-spear600-add-missing-interrupt-parent-of-rtc.patch
queue-3.18/media-r820t-fix-r820t_write_reg-for-kasan.patch
queue-3.18/arm-spear13xx-fix-spics-gpio-controller-s-warning.patch
queue-3.18/arm-dts-s5pv210-add-interrupt-parent-for-ohci.patch
queue-3.18/arm-spear13xx-fix-dmas-cells.patch
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 31747eda41ef3c30c09c5c096b380bf54013746a Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Sun, 14 Jan 2018 18:35:40 +0200
Subject: [PATCH] ovl: hash directory inodes for fsnotify
fsnotify pins a watched directory inode in cache, but if directory dentry
is released, new lookup will allocate a new dentry and a new inode.
Directory events will be notified on the new inode, while fsnotify listener
is watching the old pinned inode.
Hash all directory inodes to reuse the pinned inode on lookup. Pure upper
dirs are hashes by real upper inode, merge and lower dirs are hashed by
real lower inode.
The reference to lower inode was being held by the lower dentry object
in the overlay dentry (oe->lowerstack[0]). Releasing the overlay dentry
may drop lower inode refcount to zero. Add a refcount on behalf of the
overlay inode to prevent that.
As a by-product, hashing directory inodes also detects multiple
redirected dirs to the same lower dir and uncovered redirected dir
target on and returns -ESTALE on lookup.
The reported issue dates back to initial version of overlayfs, but this
patch depends on ovl_inode code that was introduced in kernel v4.13.
Cc: <stable(a)vger.kernel.org> #v4.13
Reported-by: Niklas Cassel <niklas.cassel(a)axis.com>
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Tested-by: Niklas Cassel <niklas.cassel(a)axis.com>
diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
index 00b6b294272a..94d2f8a8b779 100644
--- a/fs/overlayfs/inode.c
+++ b/fs/overlayfs/inode.c
@@ -606,6 +606,16 @@ static int ovl_inode_set(struct inode *inode, void *data)
static bool ovl_verify_inode(struct inode *inode, struct dentry *lowerdentry,
struct dentry *upperdentry)
{
+ if (S_ISDIR(inode->i_mode)) {
+ /* Real lower dir moved to upper layer under us? */
+ if (!lowerdentry && ovl_inode_lower(inode))
+ return false;
+
+ /* Lookup of an uncovered redirect origin? */
+ if (!upperdentry && ovl_inode_upper(inode))
+ return false;
+ }
+
/*
* Allow non-NULL lower inode in ovl_inode even if lowerdentry is NULL.
* This happens when finding a copied up overlay inode for a renamed
@@ -633,6 +643,8 @@ struct inode *ovl_get_inode(struct dentry *dentry, struct dentry *upperdentry,
struct inode *inode;
/* Already indexed or could be indexed on copy up? */
bool indexed = (index || (ovl_indexdir(dentry->d_sb) && !upperdentry));
+ struct dentry *origin = indexed ? lowerdentry : NULL;
+ bool is_dir;
if (WARN_ON(upperdentry && indexed && !lowerdentry))
return ERR_PTR(-EIO);
@@ -641,15 +653,19 @@ struct inode *ovl_get_inode(struct dentry *dentry, struct dentry *upperdentry,
realinode = d_inode(lowerdentry);
/*
- * Copy up origin (lower) may exist for non-indexed upper, but we must
- * not use lower as hash key in that case.
- * Hash inodes that are or could be indexed by origin inode and
- * non-indexed upper inodes that could be hard linked by upper inode.
+ * Copy up origin (lower) may exist for non-indexed non-dir upper, but
+ * we must not use lower as hash key in that case.
+ * Hash non-dir that is or could be indexed by origin inode.
+ * Hash dir that is or could be merged by origin inode.
+ * Hash pure upper and non-indexed non-dir by upper inode.
*/
- if (!S_ISDIR(realinode->i_mode) && (upperdentry || indexed)) {
- struct inode *key = d_inode(indexed ? lowerdentry :
- upperdentry);
- unsigned int nlink;
+ is_dir = S_ISDIR(realinode->i_mode);
+ if (is_dir)
+ origin = lowerdentry;
+
+ if (upperdentry || origin) {
+ struct inode *key = d_inode(origin ?: upperdentry);
+ unsigned int nlink = is_dir ? 1 : realinode->i_nlink;
inode = iget5_locked(dentry->d_sb, (unsigned long) key,
ovl_inode_test, ovl_inode_set, key);
@@ -670,8 +686,9 @@ struct inode *ovl_get_inode(struct dentry *dentry, struct dentry *upperdentry,
goto out;
}
- nlink = ovl_get_nlink(lowerdentry, upperdentry,
- realinode->i_nlink);
+ /* Recalculate nlink for non-dir due to indexing */
+ if (!is_dir)
+ nlink = ovl_get_nlink(lowerdentry, upperdentry, nlink);
set_nlink(inode, nlink);
} else {
inode = new_inode(dentry->d_sb);
@@ -685,7 +702,7 @@ struct inode *ovl_get_inode(struct dentry *dentry, struct dentry *upperdentry,
ovl_set_flag(OVL_IMPURE, inode);
/* Check for non-merge dir that may have whiteouts */
- if (S_ISDIR(realinode->i_mode)) {
+ if (is_dir) {
struct ovl_entry *oe = dentry->d_fsdata;
if (((upperdentry && lowerdentry) || oe->numlower > 1) ||
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 76440feb79f6..1a436fa92a04 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -211,6 +211,7 @@ static void ovl_destroy_inode(struct inode *inode)
struct ovl_inode *oi = OVL_I(inode);
dput(oi->__upperdentry);
+ iput(oi->lower);
kfree(oi->redirect);
ovl_dir_cache_free(inode);
mutex_destroy(&oi->lock);
diff --git a/fs/overlayfs/util.c b/fs/overlayfs/util.c
index d6bb1c9f5e7a..06119f34a69d 100644
--- a/fs/overlayfs/util.c
+++ b/fs/overlayfs/util.c
@@ -257,7 +257,7 @@ void ovl_inode_init(struct inode *inode, struct dentry *upperdentry,
if (upperdentry)
OVL_I(inode)->__upperdentry = upperdentry;
if (lowerdentry)
- OVL_I(inode)->lower = d_inode(lowerdentry);
+ OVL_I(inode)->lower = igrab(d_inode(lowerdentry));
ovl_copyattr(d_inode(upperdentry ?: lowerdentry), inode);
}
@@ -273,7 +273,7 @@ void ovl_inode_update(struct inode *inode, struct dentry *upperdentry)
*/
smp_wmb();
OVL_I(inode)->__upperdentry = upperdentry;
- if (!S_ISDIR(upperinode->i_mode) && inode_unhashed(inode)) {
+ if (inode_unhashed(inode)) {
inode->i_private = upperinode;
__insert_inode_hash(inode, (unsigned long) upperinode);
}
The ACPI/machine-driver code refactoring introduced in 4.13 introduced
a regression for cases where we need a DMI-based quirk to select the
machine driver (the BIOS reports an invalid HID). The fix is just to
make sure the results of the quirk are actually used.
back-ported to 4.14-stable from commit 5c256045b87b ("ASoC: acpi: fix
machine driver selection based on quirk") which did not apply cleanly.
Fixes: 54746dabf770 ('ASoC: Improve machine driver selection based on quirk data')
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96691
Tested-by: Nicole Færber <nicole.faerber(a)dpin.de>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
sound/soc/intel/common/sst-match-acpi.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/sound/soc/intel/common/sst-match-acpi.c b/sound/soc/intel/common/sst-match-acpi.c
index 56d26f36a3cb..b4a929562218 100644
--- a/sound/soc/intel/common/sst-match-acpi.c
+++ b/sound/soc/intel/common/sst-match-acpi.c
@@ -83,11 +83,9 @@ struct sst_acpi_mach *sst_acpi_find_machine(struct sst_acpi_mach *machines)
for (mach = machines; mach->id[0]; mach++) {
if (sst_acpi_check_hid(mach->id) == true) {
- if (mach->machine_quirk == NULL)
- return mach;
-
- if (mach->machine_quirk(mach) != NULL)
- return mach;
+ if (mach->machine_quirk)
+ mach = mach->machine_quirk(mach);
+ return mach;
}
}
return NULL;
--
2.14.1
Hi,
Please consider adding
dd3f6983b4a4 mmc: sdhci-of-esdhc: disable SD clock for clock value 0
97618aca1440 mmc: sdhci-of-esdhc: fix eMMC couldn't work after kexec
f2bc600008bd mmc: sdhci-of-esdhc: fix the mmc error after sleep on
ls1046ardb
(present in mainline since 4.15-rc1, 4.16-rc1 and 4.16-rc1,
respectively) to 4.14-stable.
The third removes all the code added by the second, but the clearing of
the ESDHC_TB_EN bit from esdhc_init() (whose sole user is esdhc_probe)
still happens during esdhc_probe() due to
esdhc_probe() ->
sdhci_add_host() ->
__sdhci_add_host() ->
sdhci_init(soft=0) ->
sdhci_do_reset(host, mask=SDHCI_RESET_ALL) ->
host->ops->reset(host, mask);
Presumably they could/should have been squashed, but I suppose -stable
prefers keeping a 1-1 correspondence with mainline when possible.
Thanks,
Rasmus
On Tue, Feb 20, 2018 at 1:47 PM, Olof's autobuilder <build(a)lixom.net> wrote:
> Warnings:
>
> arm64.allmodconfig:
> drivers/media/tuners/r820t.c:1334:1: warning: the frame size of 2896 bytes is larger than 2048 bytes [-Wframe-larger-than=]
Hi Greg,
please add
16c3ada89cff ("media: r820t: fix r820t_write_reg for KASAN")
This is an old bug, but hasn't shown up before as the stack warning
limit was turned off
in allmodconfig kernels. The fix is also on the backport lists I sent
for 4.9 and 4.4.
Arnd
On Mon, Feb 5, 2018 at 9:49 PM, kernelci.org bot <bot(a)kernelci.org> wrote:
>
> stable-rc/linux-4.15.y build: 185 builds: 0 failed, 185 passed, 46 warnings (v4.15.1-61-g7ab5513e4cbc)
Hi Greg,
FYI, the device tree compiler warnings are all fixed in
linux-4.16-rc1. These are basically fixes
that we ended up not submitting last minute for the release after one
of them (the USB PHY
one, if you remember) had blown up.
Anyway, I think the risk is rather low for any of them (they are
mostly platforms that
are not widely used, and the fixes make things work that didn't), so
to get a clean
build, feel free to pick up the remaining patches from mainline now or
after -rc1:
> Warnings Detected:
>
> Warnings summary:
> 2 arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Property 'dmas', cell 4 is not a phandle reference in /ahb/apb/serial@b4100000
> 2 arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Missing property '#dma-cells' in node /interrupt-controller@ec801000 or bad phandle (referred from /ahb/apb/serial@b4100000:dmas[4])
cdd104099141 ("arm: spear13xx: Fix dmas cells")
> 2 arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): Property 'cs-gpios', cell 6 is not a phandle reference in /ahb/apb/spi@e0100000
> 2 arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): Missing property '#gpio-cells' in node /interrupt-controller@ec801000 or bad phandle (referred from /ahb/apb/spi@e0100000:cs-gpios[6])
f8975cb1b8a3 ("arm: spear13xx: Fix spics gpio controller's warning")
> 2 arch/arm/boot/dts/exynos5410-smdk5410.dtb: Warning (interrupts_property): Missing interrupt-controller or interrupt-map property in /soc/system-controller@10040000
> 2 arch/arm/boot/dts/exynos5410-smdk5410.dtb: Warning (interrupts_property): Missing #interrupt-cells in interrupt-parent /soc/system-controller@10040000
> 2 arch/arm/boot/dts/exynos5410-odroidxu.dtb: Warning (interrupts_property): Missing interrupt-controller or interrupt-map property in /soc/system-controller@10040000
> 2 arch/arm/boot/dts/exynos5410-odroidxu.dtb: Warning (interrupts_property): Missing #interrupt-cells in interrupt-parent /soc/system-controller@10040000
5628a8ca1414 ("ARM: dts: exynos: fix RTC interrupt for exynos5410")
> 2 WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o
3343647813fd ("ARM: pxa/tosa-bt: add MODULE_LICENSE tag")
> 1 arch/arm64/boot/dts/qcom/msm8916-mtp.dtb: Warning (phys_property): Missing property '#phy-cells' in node /soc/mdss@1a00000/dsi-phy@1a98300 or bad phandle (referred from /soc/mdss@1a00000/dsi@1a98000:phys[0])
> 1 arch/arm64/boot/dts/qcom/apq8016-sbc.dtb: Warning (phys_property): Missing property '#phy-cells' in node /soc/mdss@1a00000/dsi-phy@1a98300 or bad phandle (referred from /soc/mdss@1a00000/dsi@1a98000:phys[0])
b0ab681285aa ("arm64: dts: msm8916: Add missing #phy-cells")
> 1 arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning (cooling_device_property): Missing property '#cooling-cells' in node /cpus/cpu@100 or bad phandle (referred from /thermal-zones/cpu_thermal/cooling-maps/map@1:cooling-device[0])
> 1 arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning (cooling_device_property): Missing property '#cooling-cells' in node /cpus/cpu@0 or bad phandle (referred from /thermal-zones/cpu_thermal/cooling-maps/map@0:cooling-device[0])
acbf76ee0506 ("arm64: dts: add #cooling-cells to CPU nodes")
> 1 arch/arm/boot/dts/stih410-b2260.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000
> 1 arch/arm/boot/dts/stih410-b2120.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000
> 1 arch/arm/boot/dts/stih407-b2120.dtb: Warning (gpios_property): hdmi,hpd-gpio property size (8) too small for cell size 2 in /soc/sti-display-subsystem/sti-hdmi@8d04000
7ac1f59c09a6 ("ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property")
> 1 arch/arm/boot/dts/ste-nomadik-s8815.dtb: Warning (interrupts_property): Missing interrupt-parent for /amba/clcd@10120000
> 1 arch/arm/boot/dts/ste-nomadik-nhk15.dtb: Warning (interrupts_property): Missing interrupt-parent for /amba/clcd@10120000
e8bfa0422469 ("ARM: dts: nomadik: add interrupt-parent for clcd")
> 1 arch/arm/boot/dts/spear600-evb.dtb: Warning (interrupts_property): Missing interrupt-parent for /ahb/apb/rtc@fc900000
6ffb5b4f248f ("arm: spear600: Add missing interrupt-parent of rtc")
> 1 arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
> 1 arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
> 1 arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
> 1 arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
> 1 arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property): Missing interrupt-parent for /soc/ohci@ec300000
5c1037196b9e ("ARM: dts: s5pv210: add interrupt-parent for ohci")
> 1 arch/arm/boot/dts/mt7623n-rfb-nand.dtb: Warning (resets_property): Missing property '#reset-cells' in node /syscon@1b000000 or bad phandle (referred from /ethernet@1b100000:resets[0])
> 1 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dtb: Warning (resets_property): Missing property '#reset-cells' in node /syscon@1b000000 or bad phandle (referred from /ethernet@1b100000:resets[0])
76a09ce214ad ("arm: dts: mt7623: Update ethsys binding")
> 1 arch/arm/boot/dts/mt2701-evb.dtb: Warning (resets_property): Missing property '#reset-cells' in node /syscon@1b000000 or bad phandle (referred from /ethernet@1b100000:resets[0])
ae72e95b5e4d ("arm: dts: mt2701: Add reset-cells")
> 1 arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property): reset-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18
> 1 arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property): power-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18
> 1 arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property): reset-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18
> 1 arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property): power-gpio property size (12) too small for cell size 3 in /ahb/apb/i2c@400A0000/uda1380@18
ca32e0c4bf9c ("ARM: lpc3250: fix uda1380 gpio numbers")
> 1 arch/arm/boot/dts/arm-realview-eb-a9mp.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd@10008000
> 1 arch/arm/boot/dts/arm-realview-eb-a9mp-bbrevd.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd@10008000
> 1 arch/arm/boot/dts/arm-realview-eb-11mp.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd@10008000
> 1 arch/arm/boot/dts/arm-realview-eb-11mp-ctrevb.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd@10008000
> 1 arch/arm/boot/dts/arm-realview-eb-11mp-bbrevd.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd@10008000
> 1 arch/arm/boot/dts/arm-realview-eb-11mp-bbrevd-ctrevb.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd@10008000
586b2a4befad ("ARM: dts: Delete bogus reference to the charlcd")
Arnd
When KMEMCHECK is enabled without UNWINDER_FRAME_POINTER, we get a
Kconfig warning, presumably harmless:
warning: (FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK && LOCKDEP && UNWINDER_FRAME_POINTER) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || SUPERH || BLACKFIN || MN10300 || METAG) || ARCH_WANT_FRAME_POINTERS || !UNWINDER_ORC && !UNWINDER_GUESS)
In newer mainline kernels, the KMEMCHECK option has been removed, so
this no longer happens. Adding the unwinder as a direct dependency
for KMEMCHECK works for 4.14-stable as well and documents the
dependency better.
Fixes: 81d387190039 ("x86/kconfig: Consolidate unwinders into multiple choice selection")
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 17de6acc0eab..3fc58c1a166b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -111,7 +111,7 @@ config X86
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_KASAN if X86_64
select HAVE_ARCH_KGDB
- select HAVE_ARCH_KMEMCHECK
+ select HAVE_ARCH_KMEMCHECK if !UNWINDER_ORC && !UNWINDER_GUESS
select HAVE_ARCH_MMAP_RND_BITS if MMU
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if MMU && COMPAT
select HAVE_ARCH_COMPAT_MMAP_BASES if MMU && COMPAT
--
2.9.0
> As already explained in the previous mail, there is a fixup for this in
> commit 81b6c9998979 ('scsi: core: check for device state in
> __scsi_remove_target()').
> Please check if this is applied, too.
I tested commit 81b6c9998979 cherry-picked on top of 4.14.20 and it
indeed solves the problem.
Can it be backported to 4.14 LTS, please?
This is a note to let you know that I've just added the patch titled
vfs: don't do RCU lookup of empty pathnames
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:
vfs-don-t-do-rcu-lookup-of-empty-pathnames.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 c0eb027e5aef70b71e5a38ee3e264dc0b497f343 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Sun, 2 Apr 2017 17:10:08 -0700
Subject: vfs: don't do RCU lookup of empty pathnames
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit c0eb027e5aef70b71e5a38ee3e264dc0b497f343 upstream.
Normal pathname lookup doesn't allow empty pathnames, but using
AT_EMPTY_PATH (with name_to_handle_at() or fstatat(), for example) you
can trigger an empty pathname lookup.
And not only is the RCU lookup in that case entirely unnecessary
(because we'll obviously immediately finalize the end result), it is
actively wrong.
Why? An empth path is a special case that will return the original
'dirfd' dentry - and that dentry may not actually be RCU-free'd,
resulting in a potential use-after-free if we were to initialize the
path lazily under the RCU read lock and depend on complete_walk()
finalizing the dentry.
Found by syzkaller and KASAN.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Reported-by: Vegard Nossum <vegard.nossum(a)gmail.com>
Acked-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Eric Biggers <ebiggers3(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/namei.c | 3 +++
1 file changed, 3 insertions(+)
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1851,6 +1851,9 @@ static int path_init(int dfd, const char
{
int retval = 0;
+ if (!*s)
+ flags &= ~LOOKUP_RCU;
+
nd->last_type = LAST_ROOT; /* if there are only slashes... */
nd->flags = flags | LOOKUP_JUMPED;
nd->depth = 0;
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-3.18/vfs-don-t-do-rcu-lookup-of-empty-pathnames.patch
Hi Greg, here's another one. When you have a chance can you please apply commit
c0eb027e5aef ("vfs: don't do RCU lookup of empty pathnames") to the stable
trees? I can reproduce the use-after-free on 4.4-stable and 4.9-stable, and it
is fixed by the patch. And I wasn't able to check 3.18 because KASAN isn't
available there, but I think the bug there as well. Thanks,
Eric
I ran into a 4.9 build regression in randconfig testing, starting with the
KAISER patches:
arch/x86/mm/kaiser.c: In function 'kaiser_init':
arch/x86/mm/kaiser.c:347:8: error: 'vsyscall_pgprot' undeclared (first use in this function); did you mean 'massage_pgprot'?
This is easy enough to fix, we just need to make the declaration visible
outside of the #ifdef. This works because the code using it is optimized
away when vsyscall_enabled() returns false at compile time.
Fixes: 9a0be5afbfbb ("vsyscall: Fix permissions for emulate mode with KAISER/PTI")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
arch/x86/include/asm/vsyscall.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscall.h
index 9ee85066f407..c98c21b7f4cd 100644
--- a/arch/x86/include/asm/vsyscall.h
+++ b/arch/x86/include/asm/vsyscall.h
@@ -13,7 +13,6 @@ extern void map_vsyscall(void);
*/
extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address);
extern bool vsyscall_enabled(void);
-extern unsigned long vsyscall_pgprot;
#else
static inline void map_vsyscall(void) {}
static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address)
@@ -23,4 +22,6 @@ static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address)
static inline bool vsyscall_enabled(void) { return false; }
#endif
+extern unsigned long vsyscall_pgprot;
+
#endif /* _ASM_X86_VSYSCALL_H */
--
2.9.0
This is a note to let you know that I've just added the patch titled
vfs: don't do RCU lookup of empty pathnames
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:
vfs-don-t-do-rcu-lookup-of-empty-pathnames.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 c0eb027e5aef70b71e5a38ee3e264dc0b497f343 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Sun, 2 Apr 2017 17:10:08 -0700
Subject: vfs: don't do RCU lookup of empty pathnames
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit c0eb027e5aef70b71e5a38ee3e264dc0b497f343 upstream.
Normal pathname lookup doesn't allow empty pathnames, but using
AT_EMPTY_PATH (with name_to_handle_at() or fstatat(), for example) you
can trigger an empty pathname lookup.
And not only is the RCU lookup in that case entirely unnecessary
(because we'll obviously immediately finalize the end result), it is
actively wrong.
Why? An empth path is a special case that will return the original
'dirfd' dentry - and that dentry may not actually be RCU-free'd,
resulting in a potential use-after-free if we were to initialize the
path lazily under the RCU read lock and depend on complete_walk()
finalizing the dentry.
Found by syzkaller and KASAN.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Reported-by: Vegard Nossum <vegard.nossum(a)gmail.com>
Acked-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Eric Biggers <ebiggers3(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/namei.c | 3 +++
1 file changed, 3 insertions(+)
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2138,6 +2138,9 @@ static const char *path_init(struct name
int retval = 0;
const char *s = nd->name->name;
+ if (!*s)
+ flags &= ~LOOKUP_RCU;
+
nd->last_type = LAST_ROOT; /* if there are only slashes... */
nd->flags = flags | LOOKUP_JUMPED | LOOKUP_PARENT;
nd->depth = 0;
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-4.9/x86-spectre-fix-an-error-message.patch
queue-4.9/nospec-move-array_index_nospec-parameter-checking-into-separate-macro.patch
queue-4.9/x86-nvmx-properly-set-spec_ctrl-and-pred_cmd-before-merging-msrs.patch
queue-4.9/x86-speculation-add-asm-msr-index.h-dependency.patch
queue-4.9/x86-cpu-rename-cpu_data.x86_mask-to-cpu_data.x86_stepping.patch
queue-4.9/x86-cpu-change-type-of-x86_cache_size-variable-to-unsigned-int.patch
queue-4.9/x86-speculation-update-speculation-control-microcode-blacklist.patch
queue-4.9/x86-speculation-correct-speculation-control-microcode-blacklist-again.patch
queue-4.9/ocfs2-try-a-blocking-lock-before-return-aop_truncated_page.patch
queue-4.9/selftests-x86-do-not-rely-on-int-0x80-in-single_step_syscall.c.patch
queue-4.9/selftests-x86-mpx-fix-incorrect-bounds-with-old-_sigfault.patch
queue-4.9/mm-hide-a-warning-for-compile_test.patch
queue-4.9/selftests-x86-pkeys-remove-unused-functions.patch
queue-4.9/vfs-don-t-do-rcu-lookup-of-empty-pathnames.patch
queue-4.9/x86-speculation-fix-up-array_index_nospec_mask-asm-constraint.patch
queue-4.9/kvm-x86-reduce-retpoline-performance-impact-in-slot_handle_level_range-by-always-inlining-iterator-helper-methods.patch
queue-4.9/selftests-x86-do-not-rely-on-int-0x80-in-test_mremap_vdso.c.patch
queue-4.9/x86-speculation-clean-up-various-spectre-related-details.patch
queue-4.9/x86-entry-64-compat-clear-registers-for-compat-syscalls-to-reduce-speculation-attack-surface.patch
This is a note to let you know that I've just added the patch titled
dm: correctly handle chained bios in dec_pending()
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:
dm-correctly-handle-chained-bios-in-dec_pending.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 8dd601fa8317243be887458c49f6c29c2f3d719f Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb(a)suse.com>
Date: Thu, 15 Feb 2018 20:00:15 +1100
Subject: dm: correctly handle chained bios in dec_pending()
From: NeilBrown <neilb(a)suse.com>
commit 8dd601fa8317243be887458c49f6c29c2f3d719f upstream.
dec_pending() is given an error status (possibly 0) to be recorded
against a bio. It can be called several times on the one 'struct
dm_io', and it is careful to only assign a non-zero error to
io->status. However when it then assigned io->status to bio->bi_status,
it is not careful and could overwrite a genuine error status with 0.
This can happen when chained bios are in use. If a bio is chained
beneath the bio that this dm_io is handling, the child bio might
complete and set bio->bi_status before the dm_io completes.
This has been possible since chained bios were introduced in 3.14, and
has become a lot easier to trigger with commit 18a25da84354 ("dm: ensure
bio submission follows a depth-first tree walk") as that commit caused
dm to start using chained bios itself.
A particular failure mode is that if a bio spans an 'error' target and a
working target, the 'error' fragment will complete instantly and set the
->bi_status, and the other fragment will normally complete a little
later, and will clear ->bi_status.
The fix is simply to only assign io_error to bio->bi_status when
io_error is not zero.
Reported-and-tested-by: Milan Broz <gmazyland(a)gmail.com>
Cc: stable(a)vger.kernel.org (v3.14+)
Signed-off-by: NeilBrown <neilb(a)suse.com>
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/dm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -809,7 +809,8 @@ static void dec_pending(struct dm_io *io
} else {
/* done with normal IO or empty flush */
trace_block_bio_complete(md->queue, bio, io_error);
- bio->bi_error = io_error;
+ if (io_error)
+ bio->bi_error = io_error;
bio_endio(bio);
}
}
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-4.9/dm-correctly-handle-chained-bios-in-dec_pending.patch
This is a note to let you know that I've just added the patch titled
vfs: don't do RCU lookup of empty pathnames
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:
vfs-don-t-do-rcu-lookup-of-empty-pathnames.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 c0eb027e5aef70b71e5a38ee3e264dc0b497f343 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Date: Sun, 2 Apr 2017 17:10:08 -0700
Subject: vfs: don't do RCU lookup of empty pathnames
From: Linus Torvalds <torvalds(a)linux-foundation.org>
commit c0eb027e5aef70b71e5a38ee3e264dc0b497f343 upstream.
Normal pathname lookup doesn't allow empty pathnames, but using
AT_EMPTY_PATH (with name_to_handle_at() or fstatat(), for example) you
can trigger an empty pathname lookup.
And not only is the RCU lookup in that case entirely unnecessary
(because we'll obviously immediately finalize the end result), it is
actively wrong.
Why? An empth path is a special case that will return the original
'dirfd' dentry - and that dentry may not actually be RCU-free'd,
resulting in a potential use-after-free if we were to initialize the
path lazily under the RCU read lock and depend on complete_walk()
finalizing the dentry.
Found by syzkaller and KASAN.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Reported-by: Vegard Nossum <vegard.nossum(a)gmail.com>
Acked-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Eric Biggers <ebiggers3(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/namei.c | 3 +++
1 file changed, 3 insertions(+)
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2000,6 +2000,9 @@ static const char *path_init(struct name
int retval = 0;
const char *s = nd->name->name;
+ if (!*s)
+ flags &= ~LOOKUP_RCU;
+
nd->last_type = LAST_ROOT; /* if there are only slashes... */
nd->flags = flags | LOOKUP_JUMPED | LOOKUP_PARENT;
nd->depth = 0;
Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are
queue-4.4/x86-cpu-change-type-of-x86_cache_size-variable-to-unsigned-int.patch
queue-4.4/mm-hide-a-warning-for-compile_test.patch
queue-4.4/vfs-don-t-do-rcu-lookup-of-empty-pathnames.patch
queue-4.4/kvm-x86-reduce-retpoline-performance-impact-in-slot_handle_level_range-by-always-inlining-iterator-helper-methods.patch