This is a note to let you know that I've just added the patch titled
tun: allow positive return values on dev_get_valid_name() call
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:
tun-allow-positive-return-values-on-dev_get_valid_name-call.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Nov 15 17:24:03 CET 2017
From: Julien Gomes <julien(a)arista.com>
Date: Wed, 25 Oct 2017 11:50:50 -0700
Subject: tun: allow positive return values on dev_get_valid_name() call
From: Julien Gomes <julien(a)arista.com>
[ Upstream commit 5c25f65fd1e42685f7ccd80e0621829c105785d9 ]
If the name argument of dev_get_valid_name() contains "%d", it will try
to assign it a unit number in __dev__alloc_name() and return either the
unit number (>= 0) or an error code (< 0).
Considering positive values as error values prevent tun device creations
relying this mechanism, therefor we should only consider negative values
as errors here.
Signed-off-by: Julien Gomes <julien(a)arista.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>
---
drivers/net/tun.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1788,7 +1788,7 @@ static int tun_set_iff(struct net *net,
if (!dev)
return -ENOMEM;
err = dev_get_valid_name(net, dev, name);
- if (err)
+ if (err < 0)
goto err_free_dev;
dev_net_set(dev, net);
Patches currently in stable-queue which might be from julien(a)arista.com are
queue-4.9/tun-allow-positive-return-values-on-dev_get_valid_name-call.patch
This is a note to let you know that I've just added the patch titled
tun: call dev_get_valid_name() before register_netdevice()
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:
tun-call-dev_get_valid_name-before-register_netdevice.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Nov 15 17:24:03 CET 2017
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Fri, 13 Oct 2017 11:58:53 -0700
Subject: tun: call dev_get_valid_name() before register_netdevice()
From: Cong Wang <xiyou.wangcong(a)gmail.com>
[ Upstream commit 0ad646c81b2182f7fa67ec0c8c825e0ee165696d ]
register_netdevice() could fail early when we have an invalid
dev name, in which case ->ndo_uninit() is not called. For tun
device, this is a problem because a timer etc. are already
initialized and it expects ->ndo_uninit() to clean them up.
We could move these initializations into a ->ndo_init() so
that register_netdevice() knows better, however this is still
complicated due to the logic in tun_detach().
Therefore, I choose to just call dev_get_valid_name() before
register_netdevice(), which is quicker and much easier to audit.
And for this specific case, it is already enough.
Fixes: 96442e42429e ("tuntap: choose the txq based on rxq")
Reported-by: Dmitry Alexeev <avekceeb(a)gmail.com>
Cc: Jason Wang <jasowang(a)redhat.com>
Cc: "Michael S. Tsirkin" <mst(a)redhat.com>
Signed-off-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>
---
drivers/net/tun.c | 3 +++
include/linux/netdevice.h | 3 +++
net/core/dev.c | 6 +++---
3 files changed, 9 insertions(+), 3 deletions(-)
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1787,6 +1787,9 @@ static int tun_set_iff(struct net *net,
if (!dev)
return -ENOMEM;
+ err = dev_get_valid_name(net, dev, name);
+ if (err)
+ goto err_free_dev;
dev_net_set(dev, net);
dev->rtnl_link_ops = &tun_link_ops;
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3742,6 +3742,9 @@ struct net_device *alloc_netdev_mqs(int
unsigned char name_assign_type,
void (*setup)(struct net_device *),
unsigned int txqs, unsigned int rxqs);
+int dev_get_valid_name(struct net *net, struct net_device *dev,
+ const char *name);
+
#define alloc_netdev(sizeof_priv, name, name_assign_type, setup) \
alloc_netdev_mqs(sizeof_priv, name, name_assign_type, setup, 1, 1)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1115,9 +1115,8 @@ static int dev_alloc_name_ns(struct net
return ret;
}
-static int dev_get_valid_name(struct net *net,
- struct net_device *dev,
- const char *name)
+int dev_get_valid_name(struct net *net, struct net_device *dev,
+ const char *name)
{
BUG_ON(!net);
@@ -1133,6 +1132,7 @@ static int dev_get_valid_name(struct net
return 0;
}
+EXPORT_SYMBOL(dev_get_valid_name);
/**
* dev_change_name - change name of a device
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.9/tun-call-dev_get_valid_name-before-register_netdevice.patch
queue-4.9/net_sched-avoid-matching-qdisc-with-zero-handle.patch
queue-4.9/tun-allow-positive-return-values-on-dev_get_valid_name-call.patch
This is a note to let you know that I've just added the patch titled
tcp: fix tcp_mtu_probe() vs highest_sack
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:
tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Nov 15 17:24:03 CET 2017
From: Eric Dumazet <edumazet(a)google.com>
Date: Mon, 30 Oct 2017 23:08:20 -0700
Subject: tcp: fix tcp_mtu_probe() vs highest_sack
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 2b7cda9c35d3b940eb9ce74b30bbd5eb30db493d ]
Based on SNMP values provided by Roman, Yuchung made the observation
that some crashes in tcp_sacktag_walk() might be caused by MTU probing.
Looking at tcp_mtu_probe(), I found that when a new skb was placed
in front of the write queue, we were not updating tcp highest sack.
If one skb is freed because all its content was copied to the new skb
(for MTU probing), then tp->highest_sack could point to a now freed skb.
Bad things would then happen, including infinite loops.
This patch renames tcp_highest_sack_combine() and uses it
from tcp_mtu_probe() to fix the bug.
Note that I also removed one test against tp->sacked_out,
since we want to replace tp->highest_sack regardless of whatever
condition, since keeping a stale pointer to freed skb is a recipe
for disaster.
Fixes: a47e5a988a57 ("[TCP]: Convert highest_sack to sk_buff to allow direct access")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: Alexei Starovoitov <alexei.starovoitov(a)gmail.com>
Reported-by: Roman Gushchin <guro(a)fb.com>
Reported-by: Oleksandr Natalenko <oleksandr(a)natalenko.name>
Acked-by: Alexei Starovoitov <ast(a)kernel.org>
Acked-by: Neal Cardwell <ncardwell(a)google.com>
Acked-by: Yuchung Cheng <ycheng(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/net/tcp.h | 6 +++---
net/ipv4/tcp_output.c | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1681,12 +1681,12 @@ static inline void tcp_highest_sack_rese
tcp_sk(sk)->highest_sack = tcp_write_queue_head(sk);
}
-/* Called when old skb is about to be deleted (to be combined with new skb) */
-static inline void tcp_highest_sack_combine(struct sock *sk,
+/* Called when old skb is about to be deleted and replaced by new skb */
+static inline void tcp_highest_sack_replace(struct sock *sk,
struct sk_buff *old,
struct sk_buff *new)
{
- if (tcp_sk(sk)->sacked_out && (old == tcp_sk(sk)->highest_sack))
+ if (old == tcp_highest_sack(sk))
tcp_sk(sk)->highest_sack = new;
}
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1996,6 +1996,7 @@ static int tcp_mtu_probe(struct sock *sk
nskb->ip_summed = skb->ip_summed;
tcp_insert_write_queue_before(nskb, skb, sk);
+ tcp_highest_sack_replace(sk, skb, nskb);
len = 0;
tcp_for_write_queue_from_safe(skb, next, sk) {
@@ -2535,7 +2536,7 @@ static void tcp_collapse_retrans(struct
BUG_ON(tcp_skb_pcount(skb) != 1 || tcp_skb_pcount(next_skb) != 1);
- tcp_highest_sack_combine(sk, next_skb, skb);
+ tcp_highest_sack_replace(sk, next_skb, skb);
tcp_unlink_write_queue(next_skb, sk);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.9/net-call-cgroup_sk_alloc-earlier-in-sk_clone_lock.patch
queue-4.9/tcp-dccp-fix-ireq-opt-races.patch
queue-4.9/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-4.9/ipv6-addrconf-increment-ifp-refcount-before-ipv6_del_addr.patch
queue-4.9/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-4.9/packet-avoid-panic-in-packet_getsockopt.patch
queue-4.9/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.9/net_sched-avoid-matching-qdisc-with-zero-handle.patch
queue-4.9/tun-tap-sanitize-tunsetsndbuf-input.patch
queue-4.9/tcp-dccp-fix-lockdep-splat-in-inet_csk_route_req.patch
queue-4.9/tcp-dccp-fix-other-lockdep-splats-accessing-ireq_opt.patch
This is a note to let you know that I've just added the patch titled
tcp/dccp: fix other lockdep splats accessing ireq_opt
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:
tcp-dccp-fix-other-lockdep-splats-accessing-ireq_opt.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Nov 15 17:24:03 CET 2017
From: Eric Dumazet <edumazet(a)google.com>
Date: Tue, 24 Oct 2017 08:20:31 -0700
Subject: tcp/dccp: fix other lockdep splats accessing ireq_opt
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 06f877d613be3621604c2520ec0351d9fbdca15f ]
In my first attempt to fix the lockdep splat, I forgot we could
enter inet_csk_route_req() with a freshly allocated request socket,
for which refcount has not yet been elevated, due to complex
SLAB_TYPESAFE_BY_RCU rules.
We either are in rcu_read_lock() section _or_ we own a refcount on the
request.
Correct RCU verb to use here is rcu_dereference_check(), although it is
not possible to prove we actually own a reference on a shared
refcount :/
In v2, I added ireq_opt_deref() helper and use in three places, to fix other
possible splats.
[ 49.844590] lockdep_rcu_suspicious+0xea/0xf3
[ 49.846487] inet_csk_route_req+0x53/0x14d
[ 49.848334] tcp_v4_route_req+0xe/0x10
[ 49.850174] tcp_conn_request+0x31c/0x6a0
[ 49.851992] ? __lock_acquire+0x614/0x822
[ 49.854015] tcp_v4_conn_request+0x5a/0x79
[ 49.855957] ? tcp_v4_conn_request+0x5a/0x79
[ 49.858052] tcp_rcv_state_process+0x98/0xdcc
[ 49.859990] ? sk_filter_trim_cap+0x2f6/0x307
[ 49.862085] tcp_v4_do_rcv+0xfc/0x145
[ 49.864055] ? tcp_v4_do_rcv+0xfc/0x145
[ 49.866173] tcp_v4_rcv+0x5ab/0xaf9
[ 49.868029] ip_local_deliver_finish+0x1af/0x2e7
[ 49.870064] ip_local_deliver+0x1b2/0x1c5
[ 49.871775] ? inet_del_offload+0x45/0x45
[ 49.873916] ip_rcv_finish+0x3f7/0x471
[ 49.875476] ip_rcv+0x3f1/0x42f
[ 49.876991] ? ip_local_deliver_finish+0x2e7/0x2e7
[ 49.878791] __netif_receive_skb_core+0x6d3/0x950
[ 49.880701] ? process_backlog+0x7e/0x216
[ 49.882589] __netif_receive_skb+0x1d/0x5e
[ 49.884122] process_backlog+0x10c/0x216
[ 49.885812] net_rx_action+0x147/0x3df
Fixes: a6ca7abe53633 ("tcp/dccp: fix lockdep splat in inet_csk_route_req()")
Fixes: c92e8c02fe66 ("tcp/dccp: fix ireq->opt races")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: kernel test robot <fengguang.wu(a)intel.com>
Reported-by: Maciej Żenczykowski <maze(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/net/inet_sock.h | 6 ++++++
net/dccp/ipv4.c | 2 +-
net/ipv4/inet_connection_sock.c | 4 ++--
net/ipv4/tcp_ipv4.c | 2 +-
4 files changed, 10 insertions(+), 4 deletions(-)
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@ -132,6 +132,12 @@ static inline int inet_request_bound_dev
return sk->sk_bound_dev_if;
}
+static inline struct ip_options_rcu *ireq_opt_deref(const struct inet_request_sock *ireq)
+{
+ return rcu_dereference_check(ireq->ireq_opt,
+ atomic_read(&ireq->req.rsk_refcnt) > 0);
+}
+
struct inet_cork {
unsigned int flags;
__be32 addr;
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -495,7 +495,7 @@ static int dccp_v4_send_response(const s
ireq->ir_rmt_addr);
err = ip_build_and_send_pkt(skb, sk, ireq->ir_loc_addr,
ireq->ir_rmt_addr,
- rcu_dereference(ireq->ireq_opt));
+ ireq_opt_deref(ireq));
err = net_xmit_eval(err);
}
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -410,8 +410,8 @@ struct dst_entry *inet_csk_route_req(con
struct ip_options_rcu *opt;
struct rtable *rt;
- opt = rcu_dereference_protected(ireq->ireq_opt,
- atomic_read(&req->rsk_refcnt) > 0);
+ opt = ireq_opt_deref(ireq);
+
flowi4_init_output(fl4, ireq->ir_iif, ireq->ir_mark,
RT_CONN_FLAGS(sk), RT_SCOPE_UNIVERSE,
sk->sk_protocol, inet_sk_flowi_flags(sk),
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -861,7 +861,7 @@ static int tcp_v4_send_synack(const stru
err = ip_build_and_send_pkt(skb, sk, ireq->ir_loc_addr,
ireq->ir_rmt_addr,
- rcu_dereference(ireq->ireq_opt));
+ ireq_opt_deref(ireq));
err = net_xmit_eval(err);
}
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.9/net-call-cgroup_sk_alloc-earlier-in-sk_clone_lock.patch
queue-4.9/tcp-dccp-fix-ireq-opt-races.patch
queue-4.9/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-4.9/ipv6-addrconf-increment-ifp-refcount-before-ipv6_del_addr.patch
queue-4.9/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-4.9/packet-avoid-panic-in-packet_getsockopt.patch
queue-4.9/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.9/net_sched-avoid-matching-qdisc-with-zero-handle.patch
queue-4.9/tun-tap-sanitize-tunsetsndbuf-input.patch
queue-4.9/tcp-dccp-fix-lockdep-splat-in-inet_csk_route_req.patch
queue-4.9/tcp-dccp-fix-other-lockdep-splats-accessing-ireq_opt.patch
This is a note to let you know that I've just added the patch titled
tcp/dccp: fix lockdep splat in inet_csk_route_req()
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:
tcp-dccp-fix-lockdep-splat-in-inet_csk_route_req.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Nov 15 17:24:03 CET 2017
From: Eric Dumazet <edumazet(a)google.com>
Date: Sun, 22 Oct 2017 12:33:57 -0700
Subject: tcp/dccp: fix lockdep splat in inet_csk_route_req()
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit a6ca7abe53633d08eea1c6756cb49c9b2d4c90bf ]
This patch fixes the following lockdep splat in inet_csk_route_req()
lockdep_rcu_suspicious
inet_csk_route_req
tcp_v4_send_synack
tcp_rtx_synack
inet_rtx_syn_ack
tcp_fastopen_synack_time
tcp_retransmit_timer
tcp_write_timer_handler
tcp_write_timer
call_timer_fn
Thread running inet_csk_route_req() owns a reference on the request
socket, so we have the guarantee ireq->ireq_opt wont be changed or
freed.
lockdep can enforce this invariant for us.
Fixes: c92e8c02fe66 ("tcp/dccp: fix ireq->opt races")
Signed-off-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/ipv4/inet_connection_sock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -410,7 +410,8 @@ struct dst_entry *inet_csk_route_req(con
struct ip_options_rcu *opt;
struct rtable *rt;
- opt = rcu_dereference(ireq->ireq_opt);
+ opt = rcu_dereference_protected(ireq->ireq_opt,
+ atomic_read(&req->rsk_refcnt) > 0);
flowi4_init_output(fl4, ireq->ir_iif, ireq->ir_mark,
RT_CONN_FLAGS(sk), RT_SCOPE_UNIVERSE,
sk->sk_protocol, inet_sk_flowi_flags(sk),
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.9/net-call-cgroup_sk_alloc-earlier-in-sk_clone_lock.patch
queue-4.9/tcp-dccp-fix-ireq-opt-races.patch
queue-4.9/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-4.9/ipv6-addrconf-increment-ifp-refcount-before-ipv6_del_addr.patch
queue-4.9/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-4.9/packet-avoid-panic-in-packet_getsockopt.patch
queue-4.9/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.9/net_sched-avoid-matching-qdisc-with-zero-handle.patch
queue-4.9/tun-tap-sanitize-tunsetsndbuf-input.patch
queue-4.9/tcp-dccp-fix-lockdep-splat-in-inet_csk_route_req.patch
queue-4.9/tcp-dccp-fix-other-lockdep-splats-accessing-ireq_opt.patch
This is a note to let you know that I've just added the patch titled
tap: double-free in error path in tap_open()
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:
tap-double-free-in-error-path-in-tap_open.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Nov 15 17:24:03 CET 2017
From: Girish Moodalbail <girish.moodalbail(a)oracle.com>
Date: Wed, 25 Oct 2017 00:23:04 -0700
Subject: tap: double-free in error path in tap_open()
From: Girish Moodalbail <girish.moodalbail(a)oracle.com>
[ Upstream commit 78e0ea6791d7baafb8a0ca82b1bd0c7b3453c919 ]
Double free of skb_array in tap module is causing kernel panic. When
tap_set_queue() fails we free skb_array right away by calling
skb_array_cleanup(). However, later on skb_array_cleanup() is called
again by tap_sock_destruct through sock_put(). This patch fixes that
issue.
Fixes: 362899b8725b35e3 (macvtap: switch to use skb array)
Signed-off-by: Girish Moodalbail <girish.moodalbail(a)oracle.com>
Acked-by: Jason Wang <jasowang(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/macvtap.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -559,6 +559,10 @@ static int macvtap_open(struct inode *in
&macvtap_proto, 0);
if (!q)
goto err;
+ if (skb_array_init(&q->skb_array, dev->tx_queue_len, GFP_KERNEL)) {
+ sk_free(&q->sk);
+ goto err;
+ }
RCU_INIT_POINTER(q->sock.wq, &q->wq);
init_waitqueue_head(&q->wq.wait);
@@ -582,22 +586,18 @@ static int macvtap_open(struct inode *in
if ((dev->features & NETIF_F_HIGHDMA) && (dev->features & NETIF_F_SG))
sock_set_flag(&q->sk, SOCK_ZEROCOPY);
- err = -ENOMEM;
- if (skb_array_init(&q->skb_array, dev->tx_queue_len, GFP_KERNEL))
- goto err_array;
-
err = macvtap_set_queue(dev, file, q);
- if (err)
- goto err_queue;
+ if (err) {
+ /* macvtap_sock_destruct() will take care of freeing skb_array */
+ goto err_put;
+ }
dev_put(dev);
rtnl_unlock();
return err;
-err_queue:
- skb_array_cleanup(&q->skb_array);
-err_array:
+err_put:
sock_put(&q->sk);
err:
if (dev)
Patches currently in stable-queue which might be from girish.moodalbail(a)oracle.com are
queue-4.9/tap-double-free-in-error-path-in-tap_open.patch
This is a note to let you know that I've just added the patch titled
soreuseport: fix initialization race
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:
soreuseport-fix-initialization-race.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Nov 15 17:24:03 CET 2017
From: Craig Gallek <kraig(a)google.com>
Date: Thu, 19 Oct 2017 15:00:29 -0400
Subject: soreuseport: fix initialization race
From: Craig Gallek <kraig(a)google.com>
[ Upstream commit 1b5f962e71bfad6284574655c406597535c3ea7a ]
Syzkaller stumbled upon a way to trigger
WARNING: CPU: 1 PID: 13881 at net/core/sock_reuseport.c:41
reuseport_alloc+0x306/0x3b0 net/core/sock_reuseport.c:39
There are two initialization paths for the sock_reuseport structure in a
socket: Through the udp/tcp bind paths of SO_REUSEPORT sockets or through
SO_ATTACH_REUSEPORT_[CE]BPF before bind. The existing implementation
assumedthat the socket lock protected both of these paths when it actually
only protects the SO_ATTACH_REUSEPORT path. Syzkaller triggered this
double allocation by running these paths concurrently.
This patch moves the check for double allocation into the reuseport_alloc
function which is protected by a global spin lock.
Fixes: e32ea7e74727 ("soreuseport: fast reuseport UDP socket selection")
Fixes: c125e80b8868 ("soreuseport: fast reuseport TCP socket selection")
Signed-off-by: Craig Gallek <kraig(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/sock_reuseport.c | 12 +++++++++---
net/ipv4/inet_hashtables.c | 5 +----
net/ipv4/udp.c | 5 +----
3 files changed, 11 insertions(+), 11 deletions(-)
--- a/net/core/sock_reuseport.c
+++ b/net/core/sock_reuseport.c
@@ -36,9 +36,14 @@ int reuseport_alloc(struct sock *sk)
* soft irq of receive path or setsockopt from process context
*/
spin_lock_bh(&reuseport_lock);
- WARN_ONCE(rcu_dereference_protected(sk->sk_reuseport_cb,
- lockdep_is_held(&reuseport_lock)),
- "multiple allocations for the same socket");
+
+ /* Allocation attempts can occur concurrently via the setsockopt path
+ * and the bind/hash path. Nothing to do when we lose the race.
+ */
+ if (rcu_dereference_protected(sk->sk_reuseport_cb,
+ lockdep_is_held(&reuseport_lock)))
+ goto out;
+
reuse = __reuseport_alloc(INIT_SOCKS);
if (!reuse) {
spin_unlock_bh(&reuseport_lock);
@@ -49,6 +54,7 @@ int reuseport_alloc(struct sock *sk)
reuse->num_socks = 1;
rcu_assign_pointer(sk->sk_reuseport_cb, reuse);
+out:
spin_unlock_bh(&reuseport_lock);
return 0;
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -455,10 +455,7 @@ static int inet_reuseport_add_sock(struc
return reuseport_add_sock(sk, sk2);
}
- /* Initial allocation may have already happened via setsockopt */
- if (!rcu_access_pointer(sk->sk_reuseport_cb))
- return reuseport_alloc(sk);
- return 0;
+ return reuseport_alloc(sk);
}
int __inet_hash(struct sock *sk, struct sock *osk,
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -222,10 +222,7 @@ static int udp_reuseport_add_sock(struct
}
}
- /* Initial allocation may have already happened via setsockopt */
- if (!rcu_access_pointer(sk->sk_reuseport_cb))
- return reuseport_alloc(sk);
- return 0;
+ return reuseport_alloc(sk);
}
/**
Patches currently in stable-queue which might be from kraig(a)google.com are
queue-4.9/soreuseport-fix-initialization-race.patch
queue-4.9/tun-tap-sanitize-tunsetsndbuf-input.patch
This is a note to let you know that I've just added the patch titled
sctp: reset owner sk for data chunks on out queues when migrating a sock
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:
sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Nov 15 17:24:03 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Sat, 28 Oct 2017 02:13:29 +0800
Subject: sctp: reset owner sk for data chunks on out queues when migrating a sock
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit d04adf1b355181e737b6b1e23d801b07f0b7c4c0 ]
Now when migrating sock to another one in sctp_sock_migrate(), it only
resets owner sk for the data in receive queues, not the chunks on out
queues.
It would cause that data chunks length on the sock is not consistent
with sk sk_wmem_alloc. When closing the sock or freeing these chunks,
the old sk would never be freed, and the new sock may crash due to
the overflow sk_wmem_alloc.
syzbot found this issue with this series:
r0 = socket$inet_sctp()
sendto$inet(r0)
listen(r0)
accept4(r0)
close(r0)
Although listen() should have returned error when one TCP-style socket
is in connecting (I may fix this one in another patch), it could also
be reproduced by peeling off an assoc.
This issue is there since very beginning.
This patch is to reset owner sk for the chunks on out queues so that
sk sk_wmem_alloc has correct value after accept one sock or peeloff
an assoc to one sock.
Note that when resetting owner sk for chunks on outqueue, it has to
sctp_clear_owner_w/skb_orphan chunks before changing assoc->base.sk
first and then sctp_set_owner_w them after changing assoc->base.sk,
due to that sctp_wfree and it's callees are using assoc->base.sk.
Reported-by: Dmitry Vyukov <dvyukov(a)google.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>
---
net/sctp/socket.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -168,6 +168,36 @@ static inline void sctp_set_owner_w(stru
sk_mem_charge(sk, chunk->skb->truesize);
}
+static void sctp_clear_owner_w(struct sctp_chunk *chunk)
+{
+ skb_orphan(chunk->skb);
+}
+
+static void sctp_for_each_tx_datachunk(struct sctp_association *asoc,
+ void (*cb)(struct sctp_chunk *))
+
+{
+ struct sctp_outq *q = &asoc->outqueue;
+ struct sctp_transport *t;
+ struct sctp_chunk *chunk;
+
+ list_for_each_entry(t, &asoc->peer.transport_addr_list, transports)
+ list_for_each_entry(chunk, &t->transmitted, transmitted_list)
+ cb(chunk);
+
+ list_for_each_entry(chunk, &q->retransmit, list)
+ cb(chunk);
+
+ list_for_each_entry(chunk, &q->sacked, list)
+ cb(chunk);
+
+ list_for_each_entry(chunk, &q->abandoned, list)
+ cb(chunk);
+
+ list_for_each_entry(chunk, &q->out_chunk_list, list)
+ cb(chunk);
+}
+
/* Verify that this is a valid address. */
static inline int sctp_verify_addr(struct sock *sk, union sctp_addr *addr,
int len)
@@ -7826,7 +7856,9 @@ static void sctp_sock_migrate(struct soc
* paths won't try to lock it and then oldsk.
*/
lock_sock_nested(newsk, SINGLE_DEPTH_NESTING);
+ sctp_for_each_tx_datachunk(assoc, sctp_clear_owner_w);
sctp_assoc_migrate(assoc, newsk);
+ sctp_for_each_tx_datachunk(assoc, sctp_set_owner_w);
/* If the association on the newsk is already closed before accept()
* is called, set RCV_SHUTDOWN flag.
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.9/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-4.9/ipip-only-increase-err_count-for-some-certain-type-icmp-in-ipip_err.patch
queue-4.9/sctp-full-support-for-ipv6-ip_nonlocal_bind-ip_freebind.patch
queue-4.9/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.9/ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
queue-4.9/ip6_gre-update-dst-pmtu-if-dev-mtu-has-been-updated-by-toobig-in-__gre6_xmit.patch
This is a note to let you know that I've just added the patch titled
sctp: add the missing sock_owned_by_user check in sctp_icmp_redirect
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:
sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Nov 15 17:24:03 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Wed, 18 Oct 2017 21:37:49 +0800
Subject: sctp: add the missing sock_owned_by_user check in sctp_icmp_redirect
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit 1cc276cec9ec574d41cf47dfc0f51406b6f26ab4 ]
Now sctp processes icmp redirect packet in sctp_icmp_redirect where
it calls sctp_transport_dst_check in which tp->dst can be released.
The problem is before calling sctp_transport_dst_check, it doesn't
check sock_owned_by_user, which means tp->dst could be freed while
a process is accessing it with owning the socket.
An use-after-free issue could be triggered by this.
This patch is to fix it by checking sock_owned_by_user before calling
sctp_transport_dst_check in sctp_icmp_redirect, so that it would not
release tp->dst if users still hold sock lock.
Besides, the same issue fixed in commit 45caeaa5ac0b ("dccp/tcp: fix
routing redirect race") on sctp also needs this check.
Fixes: 55be7a9c6074 ("ipv4: Add redirect support to all protocol icmp error handlers")
Reported-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Acked-by: Neil Horman <nhorman(a)tuxdriver.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -421,7 +421,7 @@ void sctp_icmp_redirect(struct sock *sk,
{
struct dst_entry *dst;
- if (!t)
+ if (sock_owned_by_user(sk) || !t)
return;
dst = sctp_transport_dst_check(t);
if (dst)
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.9/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-4.9/ipip-only-increase-err_count-for-some-certain-type-icmp-in-ipip_err.patch
queue-4.9/sctp-full-support-for-ipv6-ip_nonlocal_bind-ip_freebind.patch
queue-4.9/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.9/ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
queue-4.9/ip6_gre-update-dst-pmtu-if-dev-mtu-has-been-updated-by-toobig-in-__gre6_xmit.patch