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 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:48:06 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
@@ -420,7 +420,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-3.18/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-3.18/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
This is a note to let you know that I've just added the patch titled
net/unix: don't show information about sockets from other namespaces
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-unix-don-t-show-information-about-sockets-from-other-namespaces.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:48:06 CET 2017
From: Andrei Vagin <avagin(a)openvz.org>
Date: Wed, 25 Oct 2017 10:16:42 -0700
Subject: net/unix: don't show information about sockets from other namespaces
From: Andrei Vagin <avagin(a)openvz.org>
[ Upstream commit 0f5da659d8f1810f44de14acf2c80cd6499623a0 ]
socket_diag shows information only about sockets from a namespace where
a diag socket lives.
But if we request information about one unix socket, the kernel don't
check that its netns is matched with a diag socket namespace, so any
user can get information about any unix socket in a system. This looks
like a bug.
v2: add a Fixes tag
Fixes: 51d7cccf0723 ("net: make sock diag per-namespace")
Signed-off-by: Andrei Vagin <avagin(a)openvz.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/unix/diag.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/unix/diag.c
+++ b/net/unix/diag.c
@@ -256,6 +256,8 @@ static int unix_diag_get_exact(struct sk
err = -ENOENT;
if (sk == NULL)
goto out_nosk;
+ if (!net_eq(sock_net(sk), net))
+ goto out;
err = sock_diag_check_cookie(sk, req->udiag_cookie);
if (err)
Patches currently in stable-queue which might be from avagin(a)openvz.org are
queue-3.18/net-unix-don-t-show-information-about-sockets-from-other-namespaces.patch
This is a note to let you know that I've just added the patch titled
l2tp: check ps->sock before running pppol2tp_session_ioctl()
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:
l2tp-check-ps-sock-before-running-pppol2tp_session_ioctl.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Nov 16 15:48:06 CET 2017
From: Guillaume Nault <g.nault(a)alphalink.fr>
Date: Fri, 13 Oct 2017 19:22:35 +0200
Subject: l2tp: check ps->sock before running pppol2tp_session_ioctl()
From: Guillaume Nault <g.nault(a)alphalink.fr>
[ Upstream commit 5903f594935a3841137c86b9d5b75143a5b7121c ]
When pppol2tp_session_ioctl() is called by pppol2tp_tunnel_ioctl(),
the session may be unconnected. That is, it was created by
pppol2tp_session_create() and hasn't been connected with
pppol2tp_connect(). In this case, ps->sock is NULL, so we need to check
for this case in order to avoid dereferencing a NULL pointer.
Fixes: 309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault <g.nault(a)alphalink.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/l2tp/l2tp_ppp.c | 3 +++
1 file changed, 3 insertions(+)
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -1017,6 +1017,9 @@ static int pppol2tp_session_ioctl(struct
session->name, cmd, arg);
sk = ps->sock;
+ if (!sk)
+ return -EBADR;
+
sock_hold(sk);
switch (cmd) {
Patches currently in stable-queue which might be from g.nault(a)alphalink.fr are
queue-3.18/l2tp-check-ps-sock-before-running-pppol2tp_session_ioctl.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.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:
tcp-dccp-fix-other-lockdep-splats-accessing-ireq_opt.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 foo@baz Thu Nov 16 15:08:14 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
@@ -113,6 +113,12 @@ static inline u32 inet_request_mark(cons
return sk->sk_mark;
}
+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
@@ -415,8 +415,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
@@ -856,7 +856,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.4/tcp-dccp-fix-ireq-opt-races.patch
queue-4.4/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-4.4/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-4.4/packet-avoid-panic-in-packet_getsockopt.patch
queue-4.4/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.4/tun-tap-sanitize-tunsetsndbuf-input.patch
queue-4.4/tcp-dccp-fix-lockdep-splat-in-inet_csk_route_req.patch
queue-4.4/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.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:
tcp-dccp-fix-lockdep-splat-in-inet_csk_route_req.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 foo@baz Thu Nov 16 15:08:14 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
@@ -415,7 +415,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.4/tcp-dccp-fix-ireq-opt-races.patch
queue-4.4/tcp-fix-tcp_mtu_probe-vs-highest_sack.patch
queue-4.4/ipv6-flowlabel-do-not-leave-opt-tot_len-with-garbage.patch
queue-4.4/packet-avoid-panic-in-packet_getsockopt.patch
queue-4.4/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.4/tun-tap-sanitize-tunsetsndbuf-input.patch
queue-4.4/tcp-dccp-fix-lockdep-splat-in-inet_csk_route_req.patch
queue-4.4/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
ipip: only increase err_count for some certain type icmp in ipip_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:
ipip-only-increase-err_count-for-some-certain-type-icmp-in-ipip_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 foo@baz Thu Nov 16 15:08:14 CET 2017
From: Xin Long <lucien.xin(a)gmail.com>
Date: Thu, 26 Oct 2017 19:19:56 +0800
Subject: ipip: only increase err_count for some certain type icmp in ipip_err
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit f3594f0a7ea36661d7fd942facd7f31a64245f1a ]
t->err_count is used to count the link failure on tunnel and an err
will be reported to user socket in tx path if t->err_count is not 0.
udp socket could even return EHOSTUNREACH to users.
Since commit fd58156e456d ("IPIP: Use ip-tunneling code.") removed
the 'switch check' for icmp type in ipip_err(), err_count would be
increased by the icmp packet with ICMP_EXC_FRAGTIME code. an link
failure would be reported out due to this.
In Jianlin's case, when receiving ICMP_EXC_FRAGTIME a icmp packet,
udp netperf failed with the err:
send_data: data send error: No route to host (errno 113)
We expect this error reported from tunnel to socket when receiving
some certain type icmp, but not ICMP_EXC_FRAGTIME, ICMP_SR_FAILED
or ICMP_PARAMETERPROB ones.
This patch is to bring 'switch check' for icmp type back to ipip_err
so that it only reports link failure for the right type icmp, just as
in ipgre_err() and ipip6_err().
Fixes: fd58156e456d ("IPIP: Use ip-tunneling code.")
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ipip.c | 58 ++++++++++++++++++++++++++++++++++++++++----------------
1 file changed, 42 insertions(+), 16 deletions(-)
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -129,42 +129,68 @@ static struct rtnl_link_ops ipip_link_op
static int ipip_err(struct sk_buff *skb, u32 info)
{
-/* All the routers (except for Linux) return only
- 8 bytes of packet payload. It means, that precise relaying of
- ICMP in the real Internet is absolutely infeasible.
- */
+ /* All the routers (except for Linux) return only
+ 8 bytes of packet payload. It means, that precise relaying of
+ ICMP in the real Internet is absolutely infeasible.
+ */
struct net *net = dev_net(skb->dev);
struct ip_tunnel_net *itn = net_generic(net, ipip_net_id);
const struct iphdr *iph = (const struct iphdr *)skb->data;
- struct ip_tunnel *t;
- int err;
const int type = icmp_hdr(skb)->type;
const int code = icmp_hdr(skb)->code;
+ struct ip_tunnel *t;
+ int err = 0;
+
+ switch (type) {
+ case ICMP_DEST_UNREACH:
+ switch (code) {
+ case ICMP_SR_FAILED:
+ /* Impossible event. */
+ goto out;
+ default:
+ /* All others are translated to HOST_UNREACH.
+ * rfc2003 contains "deep thoughts" about NET_UNREACH,
+ * I believe they are just ether pollution. --ANK
+ */
+ break;
+ }
+ break;
+
+ case ICMP_TIME_EXCEEDED:
+ if (code != ICMP_EXC_TTL)
+ goto out;
+ break;
+
+ case ICMP_REDIRECT:
+ break;
+
+ default:
+ goto out;
+ }
- err = -ENOENT;
t = ip_tunnel_lookup(itn, skb->dev->ifindex, TUNNEL_NO_KEY,
iph->daddr, iph->saddr, 0);
- if (!t)
+ if (!t) {
+ err = -ENOENT;
goto out;
+ }
if (type == ICMP_DEST_UNREACH && code == ICMP_FRAG_NEEDED) {
- ipv4_update_pmtu(skb, dev_net(skb->dev), info,
- t->parms.link, 0, IPPROTO_IPIP, 0);
- err = 0;
+ ipv4_update_pmtu(skb, net, info, t->parms.link, 0,
+ iph->protocol, 0);
goto out;
}
if (type == ICMP_REDIRECT) {
- ipv4_redirect(skb, dev_net(skb->dev), t->parms.link, 0,
- IPPROTO_IPIP, 0);
- err = 0;
+ ipv4_redirect(skb, net, t->parms.link, 0, iph->protocol, 0);
goto out;
}
- if (t->parms.iph.daddr == 0)
+ if (t->parms.iph.daddr == 0) {
+ err = -ENOENT;
goto out;
+ }
- err = 0;
if (t->parms.iph.ttl == 0 && type == ICMP_TIME_EXCEEDED)
goto out;
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.4/sctp-reset-owner-sk-for-data-chunks-on-out-queues-when-migrating-a-sock.patch
queue-4.4/ipip-only-increase-err_count-for-some-certain-type-icmp-in-ipip_err.patch
queue-4.4/sctp-add-the-missing-sock_owned_by_user-check-in-sctp_icmp_redirect.patch
queue-4.4/ip6_gre-only-increase-err_count-for-some-certain-type-icmpv6-in-ip6gre_err.patch
This is a note to let you know that I've just added the patch titled
tun/tap: sanitize TUNSETSNDBUF input
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:
tun-tap-sanitize-tunsetsndbuf-input.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 foo@baz Thu Nov 16 15:08:14 CET 2017
From: Craig Gallek <kraig(a)google.com>
Date: Mon, 30 Oct 2017 18:50:11 -0400
Subject: tun/tap: sanitize TUNSETSNDBUF input
From: Craig Gallek <kraig(a)google.com>
[ Upstream commit 93161922c658c714715686cd0cf69b090cb9bf1d ]
Syzkaller found several variants of the lockup below by setting negative
values with the TUNSETSNDBUF ioctl. This patch adds a sanity check
to both the tun and tap versions of this ioctl.
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [repro:2389]
Modules linked in:
irq event stamp: 329692056
hardirqs last enabled at (329692055): [<ffffffff824b8381>] _raw_spin_unlock_irqrestore+0x31/0x75
hardirqs last disabled at (329692056): [<ffffffff824b9e58>] apic_timer_interrupt+0x98/0xb0
softirqs last enabled at (35659740): [<ffffffff824bc958>] __do_softirq+0x328/0x48c
softirqs last disabled at (35659731): [<ffffffff811c796c>] irq_exit+0xbc/0xd0
CPU: 0 PID: 2389 Comm: repro Not tainted 4.14.0-rc7 #23
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff880009452140 task.stack: ffff880006a20000
RIP: 0010:_raw_spin_lock_irqsave+0x11/0x80
RSP: 0018:ffff880006a27c50 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff10
RAX: ffff880009ac68d0 RBX: ffff880006a27ce0 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff880006a27ce0 RDI: ffff880009ac6900
RBP: ffff880006a27c60 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 000000000063ff00 R12: ffff880009ac6900
R13: ffff880006a27cf8 R14: 0000000000000001 R15: ffff880006a27cf8
FS: 00007f4be4838700(0000) GS:ffff88000cc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020101000 CR3: 0000000009616000 CR4: 00000000000006f0
Call Trace:
prepare_to_wait+0x26/0xc0
sock_alloc_send_pskb+0x14e/0x270
? remove_wait_queue+0x60/0x60
tun_get_user+0x2cc/0x19d0
? __tun_get+0x60/0x1b0
tun_chr_write_iter+0x57/0x86
__vfs_write+0x156/0x1e0
vfs_write+0xf7/0x230
SyS_write+0x57/0xd0
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x7f4be4356df9
RSP: 002b:00007ffc18101c08 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4be4356df9
RDX: 0000000000000046 RSI: 0000000020101000 RDI: 0000000000000005
RBP: 00007ffc18101c40 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000293 R12: 0000559c75f64780
R13: 00007ffc18101d30 R14: 0000000000000000 R15: 0000000000000000
Fixes: 33dccbb050bb ("tun: Limit amount of queued packets per device")
Fixes: 20d29d7a916a ("net: macvtap driver")
Signed-off-by: Craig Gallek <kraig(a)google.com>
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>
---
drivers/net/macvtap.c | 2 ++
drivers/net/tun.c | 4 ++++
2 files changed, 6 insertions(+)
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -1117,6 +1117,8 @@ static long macvtap_ioctl(struct file *f
case TUNSETSNDBUF:
if (get_user(s, sp))
return -EFAULT;
+ if (s <= 0)
+ return -EINVAL;
q->sk.sk_sndbuf = s;
return 0;
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -2065,6 +2065,10 @@ static long __tun_chr_ioctl(struct file
ret = -EFAULT;
break;
}
+ if (sndbuf <= 0) {
+ ret = -EINVAL;
+ break;
+ }
tun->sndbuf = sndbuf;
tun_set_sndbuf(tun);
Patches currently in stable-queue which might be from kraig(a)google.com are
queue-4.4/tun-tap-sanitize-tunsetsndbuf-input.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.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:
tun-call-dev_get_valid_name-before-register_netdevice.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 foo@baz Thu Nov 16 15:08:14 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
@@ -1684,6 +1684,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
@@ -3469,6 +3469,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
@@ -1111,9 +1111,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);
@@ -1129,6 +1128,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.4/tun-call-dev_get_valid_name-before-register_netdevice.patch
queue-4.4/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: allow positive return values on dev_get_valid_name() call
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:
tun-allow-positive-return-values-on-dev_get_valid_name-call.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 foo@baz Thu Nov 16 15:08:14 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
@@ -1685,7 +1685,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.4/tun-allow-positive-return-values-on-dev_get_valid_name-call.patch