<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/ipv4, branch v3.12.52</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>net: fix IP early demux races</title>
<updated>2016-01-05T17:18:01+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-12-14T22:08:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=60beb2eef0388d851e5515dfad296b9016d57d25'/>
<id>60beb2eef0388d851e5515dfad296b9016d57d25</id>
<content type='text'>
[ Upstream commit 5037e9ef9454917b047f9f3a19b4dd179fbf7cd4 ]

David Wilder reported crashes caused by dst reuse.

&lt;quote David&gt;
  I am seeing a crash on a distro V4.2.3 kernel caused by a double
  release of a dst_entry.  In ipv4_dst_destroy() the call to
  list_empty() finds a poisoned next pointer, indicating the dst_entry
  has already been removed from the list and freed. The crash occurs
  18 to 24 hours into a run of a network stress exerciser.
&lt;/quote&gt;

Thanks to his detailed report and analysis, we were able to understand
the core issue.

IP early demux can associate a dst to skb, after a lookup in TCP/UDP
sockets.

When socket cache is not properly set, we want to store into
sk-&gt;sk_dst_cache the dst for future IP early demux lookups,
by acquiring a stable refcount on the dst.

Problem is this acquisition is simply using an atomic_inc(),
which works well, unless the dst was queued for destruction from
dst_release() noticing dst refcount went to zero, if DST_NOCACHE
was set on dst.

We need to make sure current refcount is not zero before incrementing
it, or risk double free as David reported.

This patch, being a stable candidate, adds two new helpers, and use
them only from IP early demux problematic paths.

It might be possible to merge in net-next skb_dst_force() and
skb_dst_force_safe(), but I prefer having the smallest patch for stable
kernels : Maybe some skb_dst_force() callers do not expect skb-&gt;dst
can suddenly be cleared.

Can probably be backported back to linux-3.6 kernels

Reported-by: David J. Wilder &lt;dwilder@us.ibm.com&gt;
Tested-by: David J. Wilder &lt;dwilder@us.ibm.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 5037e9ef9454917b047f9f3a19b4dd179fbf7cd4 ]

David Wilder reported crashes caused by dst reuse.

&lt;quote David&gt;
  I am seeing a crash on a distro V4.2.3 kernel caused by a double
  release of a dst_entry.  In ipv4_dst_destroy() the call to
  list_empty() finds a poisoned next pointer, indicating the dst_entry
  has already been removed from the list and freed. The crash occurs
  18 to 24 hours into a run of a network stress exerciser.
&lt;/quote&gt;

Thanks to his detailed report and analysis, we were able to understand
the core issue.

IP early demux can associate a dst to skb, after a lookup in TCP/UDP
sockets.

When socket cache is not properly set, we want to store into
sk-&gt;sk_dst_cache the dst for future IP early demux lookups,
by acquiring a stable refcount on the dst.

Problem is this acquisition is simply using an atomic_inc(),
which works well, unless the dst was queued for destruction from
dst_release() noticing dst refcount went to zero, if DST_NOCACHE
was set on dst.

We need to make sure current refcount is not zero before incrementing
it, or risk double free as David reported.

This patch, being a stable candidate, adds two new helpers, and use
them only from IP early demux problematic paths.

It might be possible to merge in net-next skb_dst_force() and
skb_dst_force_safe(), but I prefer having the smallest patch for stable
kernels : Maybe some skb_dst_force() callers do not expect skb-&gt;dst
can suddenly be cleared.

Can probably be backported back to linux-3.6 kernels

Reported-by: David J. Wilder &lt;dwilder@us.ibm.com&gt;
Tested-by: David J. Wilder &lt;dwilder@us.ibm.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: add validation for the socket syscall protocol argument</title>
<updated>2016-01-05T17:04:00+00:00</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2015-12-14T21:03:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0295617f822f630711f5af03316d3cbda6e737d4'/>
<id>0295617f822f630711f5af03316d3cbda6e737d4</id>
<content type='text'>
[ Upstream commit 79462ad02e861803b3840cc782248c7359451cd9 ]

郭永刚 reported that one could simply crash the kernel as root by
using a simple program:

	int socket_fd;
	struct sockaddr_in addr;
	addr.sin_port = 0;
	addr.sin_addr.s_addr = INADDR_ANY;
	addr.sin_family = 10;

	socket_fd = socket(10,3,0x40000000);
	connect(socket_fd , &amp;addr,16);

AF_INET, AF_INET6 sockets actually only support 8-bit protocol
identifiers. inet_sock's skc_protocol field thus is sized accordingly,
thus larger protocol identifiers simply cut off the higher bits and
store a zero in the protocol fields.

This could lead to e.g. NULL function pointer because as a result of
the cut off inet_num is zero and we call down to inet_autobind, which
is NULL for raw sockets.

kernel: Call Trace:
kernel:  [&lt;ffffffff816db90e&gt;] ? inet_autobind+0x2e/0x70
kernel:  [&lt;ffffffff816db9a4&gt;] inet_dgram_connect+0x54/0x80
kernel:  [&lt;ffffffff81645069&gt;] SYSC_connect+0xd9/0x110
kernel:  [&lt;ffffffff810ac51b&gt;] ? ptrace_notify+0x5b/0x80
kernel:  [&lt;ffffffff810236d8&gt;] ? syscall_trace_enter_phase2+0x108/0x200
kernel:  [&lt;ffffffff81645e0e&gt;] SyS_connect+0xe/0x10
kernel:  [&lt;ffffffff81779515&gt;] tracesys_phase2+0x84/0x89

I found no particular commit which introduced this problem.

CVE: CVE-2015-8543
Cc: Cong Wang &lt;cwang@twopensource.com&gt;
Reported-by: 郭永刚 &lt;guoyonggang@360.cn&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 79462ad02e861803b3840cc782248c7359451cd9 ]

郭永刚 reported that one could simply crash the kernel as root by
using a simple program:

	int socket_fd;
	struct sockaddr_in addr;
	addr.sin_port = 0;
	addr.sin_addr.s_addr = INADDR_ANY;
	addr.sin_family = 10;

	socket_fd = socket(10,3,0x40000000);
	connect(socket_fd , &amp;addr,16);

AF_INET, AF_INET6 sockets actually only support 8-bit protocol
identifiers. inet_sock's skc_protocol field thus is sized accordingly,
thus larger protocol identifiers simply cut off the higher bits and
store a zero in the protocol fields.

This could lead to e.g. NULL function pointer because as a result of
the cut off inet_num is zero and we call down to inet_autobind, which
is NULL for raw sockets.

kernel: Call Trace:
kernel:  [&lt;ffffffff816db90e&gt;] ? inet_autobind+0x2e/0x70
kernel:  [&lt;ffffffff816db9a4&gt;] inet_dgram_connect+0x54/0x80
kernel:  [&lt;ffffffff81645069&gt;] SYSC_connect+0xd9/0x110
kernel:  [&lt;ffffffff810ac51b&gt;] ? ptrace_notify+0x5b/0x80
kernel:  [&lt;ffffffff810236d8&gt;] ? syscall_trace_enter_phase2+0x108/0x200
kernel:  [&lt;ffffffff81645e0e&gt;] SyS_connect+0xe/0x10
kernel:  [&lt;ffffffff81779515&gt;] tracesys_phase2+0x84/0x89

I found no particular commit which introduced this problem.

CVE: CVE-2015-8543
Cc: Cong Wang &lt;cwang@twopensource.com&gt;
Reported-by: 郭永刚 &lt;guoyonggang@360.cn&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>netfilter: ipt_rpfilter: remove the nh_scope test in rpfilter_lookup_reverse</title>
<updated>2016-01-05T16:00:01+00:00</updated>
<author>
<name>lucien</name>
<email>lucien.xin@gmail.com</email>
</author>
<published>2015-10-06T13:03:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=58ebe11c5f3f011159eb57306257a186684301f7'/>
<id>58ebe11c5f3f011159eb57306257a186684301f7</id>
<content type='text'>
commit cc4998febd567d1c671684abce5595344bd4e8b2 upstream.

--accept-local  option works for res.type == RTN_LOCAL, which should be
from the local table, but there, the fib_info's nh-&gt;nh_scope =
RT_SCOPE_NOWHERE ( &gt; RT_SCOPE_HOST). in fib_create_info().

	if (cfg-&gt;fc_scope == RT_SCOPE_HOST) {
		struct fib_nh *nh = fi-&gt;fib_nh;

		/* Local address is added. */
		if (nhs != 1 || nh-&gt;nh_gw)
			goto err_inval;
		nh-&gt;nh_scope = RT_SCOPE_NOWHERE;   &lt;===
		nh-&gt;nh_dev = dev_get_by_index(net, fi-&gt;fib_nh-&gt;nh_oif);
		err = -ENODEV;
		if (!nh-&gt;nh_dev)
			goto failure;

but in our rpfilter_lookup_reverse():

	if (dev_match || flags &amp; XT_RPFILTER_LOOSE)
		return FIB_RES_NH(res).nh_scope &lt;= RT_SCOPE_HOST;

if nh-&gt;nh_scope &gt; RT_SCOPE_HOST, it will fail. --accept-local option
will never be passed.

it seems the test is bogus and can be removed to fix this issue.

	if (dev_match || flags &amp; XT_RPFILTER_LOOSE)
		return FIB_RES_NH(res).nh_scope &lt;= RT_SCOPE_HOST;

ipv6 does not have this issue.

Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Acked-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cc4998febd567d1c671684abce5595344bd4e8b2 upstream.

--accept-local  option works for res.type == RTN_LOCAL, which should be
from the local table, but there, the fib_info's nh-&gt;nh_scope =
RT_SCOPE_NOWHERE ( &gt; RT_SCOPE_HOST). in fib_create_info().

	if (cfg-&gt;fc_scope == RT_SCOPE_HOST) {
		struct fib_nh *nh = fi-&gt;fib_nh;

		/* Local address is added. */
		if (nhs != 1 || nh-&gt;nh_gw)
			goto err_inval;
		nh-&gt;nh_scope = RT_SCOPE_NOWHERE;   &lt;===
		nh-&gt;nh_dev = dev_get_by_index(net, fi-&gt;fib_nh-&gt;nh_oif);
		err = -ENODEV;
		if (!nh-&gt;nh_dev)
			goto failure;

but in our rpfilter_lookup_reverse():

	if (dev_match || flags &amp; XT_RPFILTER_LOOSE)
		return FIB_RES_NH(res).nh_scope &lt;= RT_SCOPE_HOST;

if nh-&gt;nh_scope &gt; RT_SCOPE_HOST, it will fail. --accept-local option
will never be passed.

it seems the test is bogus and can be removed to fix this issue.

	if (dev_match || flags &amp; XT_RPFILTER_LOOSE)
		return FIB_RES_NH(res).nh_scope &lt;= RT_SCOPE_HOST;

ipv6 does not have this issue.

Signed-off-by: Xin Long &lt;lucien.xin@gmail.com&gt;
Acked-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: ipmr: fix static mfc/dev leaks on table destruction</title>
<updated>2016-01-05T15:11:12+00:00</updated>
<author>
<name>Nikolay Aleksandrov</name>
<email>nikolay@cumulusnetworks.com</email>
</author>
<published>2015-11-20T12:54:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=536db34c350b88072b7ba763fc3203829b7d6e7d'/>
<id>536db34c350b88072b7ba763fc3203829b7d6e7d</id>
<content type='text'>
[ Upstream commit 0e615e9601a15efeeb8942cf7cd4dadba0c8c5a7 ]

When destroying an mrt table the static mfc entries and the static
devices are kept, which leads to devices that can never be destroyed
(because of refcnt taken) and leaked memory, for example:
unreferenced object 0xffff880034c144c0 (size 192):
  comm "mfc-broken", pid 4777, jiffies 4320349055 (age 46001.964s)
  hex dump (first 32 bytes):
    98 53 f0 34 00 88 ff ff 98 53 f0 34 00 88 ff ff  .S.4.....S.4....
    ef 0a 0a 14 01 02 03 04 00 00 00 00 01 00 00 00  ................
  backtrace:
    [&lt;ffffffff815c1b9e&gt;] kmemleak_alloc+0x4e/0xb0
    [&lt;ffffffff811ea6e0&gt;] kmem_cache_alloc+0x190/0x300
    [&lt;ffffffff815931cb&gt;] ip_mroute_setsockopt+0x5cb/0x910
    [&lt;ffffffff8153d575&gt;] do_ip_setsockopt.isra.11+0x105/0xff0
    [&lt;ffffffff8153e490&gt;] ip_setsockopt+0x30/0xa0
    [&lt;ffffffff81564e13&gt;] raw_setsockopt+0x33/0x90
    [&lt;ffffffff814d1e14&gt;] sock_common_setsockopt+0x14/0x20
    [&lt;ffffffff814d0b51&gt;] SyS_setsockopt+0x71/0xc0
    [&lt;ffffffff815cdbf6&gt;] entry_SYSCALL_64_fastpath+0x16/0x7a
    [&lt;ffffffffffffffff&gt;] 0xffffffffffffffff

Make sure that everything is cleaned on netns destruction.

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@cumulusnetworks.com&gt;
Reviewed-by: Cong Wang &lt;cwang@twopensource.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 0e615e9601a15efeeb8942cf7cd4dadba0c8c5a7 ]

When destroying an mrt table the static mfc entries and the static
devices are kept, which leads to devices that can never be destroyed
(because of refcnt taken) and leaked memory, for example:
unreferenced object 0xffff880034c144c0 (size 192):
  comm "mfc-broken", pid 4777, jiffies 4320349055 (age 46001.964s)
  hex dump (first 32 bytes):
    98 53 f0 34 00 88 ff ff 98 53 f0 34 00 88 ff ff  .S.4.....S.4....
    ef 0a 0a 14 01 02 03 04 00 00 00 00 01 00 00 00  ................
  backtrace:
    [&lt;ffffffff815c1b9e&gt;] kmemleak_alloc+0x4e/0xb0
    [&lt;ffffffff811ea6e0&gt;] kmem_cache_alloc+0x190/0x300
    [&lt;ffffffff815931cb&gt;] ip_mroute_setsockopt+0x5cb/0x910
    [&lt;ffffffff8153d575&gt;] do_ip_setsockopt.isra.11+0x105/0xff0
    [&lt;ffffffff8153e490&gt;] ip_setsockopt+0x30/0xa0
    [&lt;ffffffff81564e13&gt;] raw_setsockopt+0x33/0x90
    [&lt;ffffffff814d1e14&gt;] sock_common_setsockopt+0x14/0x20
    [&lt;ffffffff814d0b51&gt;] SyS_setsockopt+0x71/0xc0
    [&lt;ffffffff815cdbf6&gt;] entry_SYSCALL_64_fastpath+0x16/0x7a
    [&lt;ffffffffffffffff&gt;] 0xffffffffffffffff

Make sure that everything is cleaned on netns destruction.

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@cumulusnetworks.com&gt;
Reviewed-by: Cong Wang &lt;cwang@twopensource.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tcp: initialize tp-&gt;copied_seq in case of cross SYN connection</title>
<updated>2016-01-05T15:11:11+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-11-26T16:18:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9c43328bdee955eaedbc49eb0e03919ae1130e14'/>
<id>9c43328bdee955eaedbc49eb0e03919ae1130e14</id>
<content type='text'>
[ Upstream commit 142a2e7ece8d8ac0e818eb2c91f99ca894730e2a ]

Dmitry provided a syzkaller (http://github.com/google/syzkaller)
generated program that triggers the WARNING at
net/ipv4/tcp.c:1729 in tcp_recvmsg() :

WARN_ON(tp-&gt;copied_seq != tp-&gt;rcv_nxt &amp;&amp;
        !(flags &amp; (MSG_PEEK | MSG_TRUNC)));

His program is specifically attempting a Cross SYN TCP exchange,
that we support (for the pleasure of hackers ?), but it looks we
lack proper tcp-&gt;copied_seq initialization.

Thanks again Dmitry for your report and testings.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Tested-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 142a2e7ece8d8ac0e818eb2c91f99ca894730e2a ]

Dmitry provided a syzkaller (http://github.com/google/syzkaller)
generated program that triggers the WARNING at
net/ipv4/tcp.c:1729 in tcp_recvmsg() :

WARN_ON(tp-&gt;copied_seq != tp-&gt;rcv_nxt &amp;&amp;
        !(flags &amp; (MSG_PEEK | MSG_TRUNC)));

His program is specifically attempting a Cross SYN TCP exchange,
that we support (for the pleasure of hackers ?), but it looks we
lack proper tcp-&gt;copied_seq initialization.

Thanks again Dmitry for your report and testings.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Tested-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tcp: md5: fix lockdep annotation</title>
<updated>2016-01-05T15:11:10+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-11-18T20:40:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=42a3f2aef2fd789d153e3cdf9117833a44786b57'/>
<id>42a3f2aef2fd789d153e3cdf9117833a44786b57</id>
<content type='text'>
[ Upstream commit 1b8e6a01e19f001e9f93b39c32387961c91ed3cc ]

When a passive TCP is created, we eventually call tcp_md5_do_add()
with sk pointing to the child. It is not owner by the user yet (we
will add this socket into listener accept queue a bit later anyway)

But we do own the spinlock, so amend the lockdep annotation to avoid
following splat :

[ 8451.090932] net/ipv4/tcp_ipv4.c:923 suspicious rcu_dereference_protected() usage!
[ 8451.090932]
[ 8451.090932] other info that might help us debug this:
[ 8451.090932]
[ 8451.090934]
[ 8451.090934] rcu_scheduler_active = 1, debug_locks = 1
[ 8451.090936] 3 locks held by socket_sockopt_/214795:
[ 8451.090936]  #0:  (rcu_read_lock){.+.+..}, at: [&lt;ffffffff855c6ac1&gt;] __netif_receive_skb_core+0x151/0xe90
[ 8451.090947]  #1:  (rcu_read_lock){.+.+..}, at: [&lt;ffffffff85618143&gt;] ip_local_deliver_finish+0x43/0x2b0
[ 8451.090952]  #2:  (slock-AF_INET){+.-...}, at: [&lt;ffffffff855acda5&gt;] sk_clone_lock+0x1c5/0x500
[ 8451.090958]
[ 8451.090958] stack backtrace:
[ 8451.090960] CPU: 7 PID: 214795 Comm: socket_sockopt_

[ 8451.091215] Call Trace:
[ 8451.091216]  &lt;IRQ&gt;  [&lt;ffffffff856fb29c&gt;] dump_stack+0x55/0x76
[ 8451.091229]  [&lt;ffffffff85123b5b&gt;] lockdep_rcu_suspicious+0xeb/0x110
[ 8451.091235]  [&lt;ffffffff8564544f&gt;] tcp_md5_do_add+0x1bf/0x1e0
[ 8451.091239]  [&lt;ffffffff85645751&gt;] tcp_v4_syn_recv_sock+0x1f1/0x4c0
[ 8451.091242]  [&lt;ffffffff85642b27&gt;] ? tcp_v4_md5_hash_skb+0x167/0x190
[ 8451.091246]  [&lt;ffffffff85647c78&gt;] tcp_check_req+0x3c8/0x500
[ 8451.091249]  [&lt;ffffffff856451ae&gt;] ? tcp_v4_inbound_md5_hash+0x11e/0x190
[ 8451.091253]  [&lt;ffffffff85647170&gt;] tcp_v4_rcv+0x3c0/0x9f0
[ 8451.091256]  [&lt;ffffffff85618143&gt;] ? ip_local_deliver_finish+0x43/0x2b0
[ 8451.091260]  [&lt;ffffffff856181b6&gt;] ip_local_deliver_finish+0xb6/0x2b0
[ 8451.091263]  [&lt;ffffffff85618143&gt;] ? ip_local_deliver_finish+0x43/0x2b0
[ 8451.091267]  [&lt;ffffffff85618d38&gt;] ip_local_deliver+0x48/0x80
[ 8451.091270]  [&lt;ffffffff85618510&gt;] ip_rcv_finish+0x160/0x700
[ 8451.091273]  [&lt;ffffffff8561900e&gt;] ip_rcv+0x29e/0x3d0
[ 8451.091277]  [&lt;ffffffff855c74b7&gt;] __netif_receive_skb_core+0xb47/0xe90

Fixes: a8afca0329988 ("tcp: md5: protects md5sig_info with RCU")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: Willem de Bruijn &lt;willemb@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 1b8e6a01e19f001e9f93b39c32387961c91ed3cc ]

When a passive TCP is created, we eventually call tcp_md5_do_add()
with sk pointing to the child. It is not owner by the user yet (we
will add this socket into listener accept queue a bit later anyway)

But we do own the spinlock, so amend the lockdep annotation to avoid
following splat :

[ 8451.090932] net/ipv4/tcp_ipv4.c:923 suspicious rcu_dereference_protected() usage!
[ 8451.090932]
[ 8451.090932] other info that might help us debug this:
[ 8451.090932]
[ 8451.090934]
[ 8451.090934] rcu_scheduler_active = 1, debug_locks = 1
[ 8451.090936] 3 locks held by socket_sockopt_/214795:
[ 8451.090936]  #0:  (rcu_read_lock){.+.+..}, at: [&lt;ffffffff855c6ac1&gt;] __netif_receive_skb_core+0x151/0xe90
[ 8451.090947]  #1:  (rcu_read_lock){.+.+..}, at: [&lt;ffffffff85618143&gt;] ip_local_deliver_finish+0x43/0x2b0
[ 8451.090952]  #2:  (slock-AF_INET){+.-...}, at: [&lt;ffffffff855acda5&gt;] sk_clone_lock+0x1c5/0x500
[ 8451.090958]
[ 8451.090958] stack backtrace:
[ 8451.090960] CPU: 7 PID: 214795 Comm: socket_sockopt_

[ 8451.091215] Call Trace:
[ 8451.091216]  &lt;IRQ&gt;  [&lt;ffffffff856fb29c&gt;] dump_stack+0x55/0x76
[ 8451.091229]  [&lt;ffffffff85123b5b&gt;] lockdep_rcu_suspicious+0xeb/0x110
[ 8451.091235]  [&lt;ffffffff8564544f&gt;] tcp_md5_do_add+0x1bf/0x1e0
[ 8451.091239]  [&lt;ffffffff85645751&gt;] tcp_v4_syn_recv_sock+0x1f1/0x4c0
[ 8451.091242]  [&lt;ffffffff85642b27&gt;] ? tcp_v4_md5_hash_skb+0x167/0x190
[ 8451.091246]  [&lt;ffffffff85647c78&gt;] tcp_check_req+0x3c8/0x500
[ 8451.091249]  [&lt;ffffffff856451ae&gt;] ? tcp_v4_inbound_md5_hash+0x11e/0x190
[ 8451.091253]  [&lt;ffffffff85647170&gt;] tcp_v4_rcv+0x3c0/0x9f0
[ 8451.091256]  [&lt;ffffffff85618143&gt;] ? ip_local_deliver_finish+0x43/0x2b0
[ 8451.091260]  [&lt;ffffffff856181b6&gt;] ip_local_deliver_finish+0xb6/0x2b0
[ 8451.091263]  [&lt;ffffffff85618143&gt;] ? ip_local_deliver_finish+0x43/0x2b0
[ 8451.091267]  [&lt;ffffffff85618d38&gt;] ip_local_deliver+0x48/0x80
[ 8451.091270]  [&lt;ffffffff85618510&gt;] ip_rcv_finish+0x160/0x700
[ 8451.091273]  [&lt;ffffffff8561900e&gt;] ip_rcv+0x29e/0x3d0
[ 8451.091277]  [&lt;ffffffff855c74b7&gt;] __netif_receive_skb_core+0xb47/0xe90

Fixes: a8afca0329988 ("tcp: md5: protects md5sig_info with RCU")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: Willem de Bruijn &lt;willemb@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipmr: fix possible race resulting from improper usage of IP_INC_STATS_BH() in preemptible context.</title>
<updated>2015-11-14T15:48:47+00:00</updated>
<author>
<name>Ani Sinha</name>
<email>ani@arista.com</email>
</author>
<published>2015-10-30T23:54:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7b831da141a97f9bc60d3b6ef0b21dcaf596ec74'/>
<id>7b831da141a97f9bc60d3b6ef0b21dcaf596ec74</id>
<content type='text'>
[ Upstream commit 44f49dd8b5a606870a1f21101522a0f9c4414784 ]

Fixes the following kernel BUG :

BUG: using __this_cpu_add() in preemptible [00000000] code: bash/2758
caller is __this_cpu_preempt_check+0x13/0x15
CPU: 0 PID: 2758 Comm: bash Tainted: P           O   3.18.19 #2
 ffffffff8170eaca ffff880110d1b788 ffffffff81482b2a 0000000000000000
 0000000000000000 ffff880110d1b7b8 ffffffff812010ae ffff880007cab800
 ffff88001a060800 ffff88013a899108 ffff880108b84240 ffff880110d1b7c8
Call Trace:
[&lt;ffffffff81482b2a&gt;] dump_stack+0x52/0x80
[&lt;ffffffff812010ae&gt;] check_preemption_disabled+0xce/0xe1
[&lt;ffffffff812010d4&gt;] __this_cpu_preempt_check+0x13/0x15
[&lt;ffffffff81419d60&gt;] ipmr_queue_xmit+0x647/0x70c
[&lt;ffffffff8141a154&gt;] ip_mr_forward+0x32f/0x34e
[&lt;ffffffff8141af76&gt;] ip_mroute_setsockopt+0xe03/0x108c
[&lt;ffffffff810553fc&gt;] ? get_parent_ip+0x11/0x42
[&lt;ffffffff810e6974&gt;] ? pollwake+0x4d/0x51
[&lt;ffffffff81058ac0&gt;] ? default_wake_function+0x0/0xf
[&lt;ffffffff810553fc&gt;] ? get_parent_ip+0x11/0x42
[&lt;ffffffff810613d9&gt;] ? __wake_up_common+0x45/0x77
[&lt;ffffffff81486ea9&gt;] ? _raw_spin_unlock_irqrestore+0x1d/0x32
[&lt;ffffffff810618bc&gt;] ? __wake_up_sync_key+0x4a/0x53
[&lt;ffffffff8139a519&gt;] ? sock_def_readable+0x71/0x75
[&lt;ffffffff813dd226&gt;] do_ip_setsockopt+0x9d/0xb55
[&lt;ffffffff81429818&gt;] ? unix_seqpacket_sendmsg+0x3f/0x41
[&lt;ffffffff813963fe&gt;] ? sock_sendmsg+0x6d/0x86
[&lt;ffffffff813959d4&gt;] ? sockfd_lookup_light+0x12/0x5d
[&lt;ffffffff8139650a&gt;] ? SyS_sendto+0xf3/0x11b
[&lt;ffffffff810d5738&gt;] ? new_sync_read+0x82/0xaa
[&lt;ffffffff813ddd19&gt;] compat_ip_setsockopt+0x3b/0x99
[&lt;ffffffff813fb24a&gt;] compat_raw_setsockopt+0x11/0x32
[&lt;ffffffff81399052&gt;] compat_sock_common_setsockopt+0x18/0x1f
[&lt;ffffffff813c4d05&gt;] compat_SyS_setsockopt+0x1a9/0x1cf
[&lt;ffffffff813c4149&gt;] compat_SyS_socketcall+0x180/0x1e3
[&lt;ffffffff81488ea1&gt;] cstar_dispatch+0x7/0x1e

Signed-off-by: Ani Sinha &lt;ani@arista.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 44f49dd8b5a606870a1f21101522a0f9c4414784 ]

Fixes the following kernel BUG :

BUG: using __this_cpu_add() in preemptible [00000000] code: bash/2758
caller is __this_cpu_preempt_check+0x13/0x15
CPU: 0 PID: 2758 Comm: bash Tainted: P           O   3.18.19 #2
 ffffffff8170eaca ffff880110d1b788 ffffffff81482b2a 0000000000000000
 0000000000000000 ffff880110d1b7b8 ffffffff812010ae ffff880007cab800
 ffff88001a060800 ffff88013a899108 ffff880108b84240 ffff880110d1b7c8
Call Trace:
[&lt;ffffffff81482b2a&gt;] dump_stack+0x52/0x80
[&lt;ffffffff812010ae&gt;] check_preemption_disabled+0xce/0xe1
[&lt;ffffffff812010d4&gt;] __this_cpu_preempt_check+0x13/0x15
[&lt;ffffffff81419d60&gt;] ipmr_queue_xmit+0x647/0x70c
[&lt;ffffffff8141a154&gt;] ip_mr_forward+0x32f/0x34e
[&lt;ffffffff8141af76&gt;] ip_mroute_setsockopt+0xe03/0x108c
[&lt;ffffffff810553fc&gt;] ? get_parent_ip+0x11/0x42
[&lt;ffffffff810e6974&gt;] ? pollwake+0x4d/0x51
[&lt;ffffffff81058ac0&gt;] ? default_wake_function+0x0/0xf
[&lt;ffffffff810553fc&gt;] ? get_parent_ip+0x11/0x42
[&lt;ffffffff810613d9&gt;] ? __wake_up_common+0x45/0x77
[&lt;ffffffff81486ea9&gt;] ? _raw_spin_unlock_irqrestore+0x1d/0x32
[&lt;ffffffff810618bc&gt;] ? __wake_up_sync_key+0x4a/0x53
[&lt;ffffffff8139a519&gt;] ? sock_def_readable+0x71/0x75
[&lt;ffffffff813dd226&gt;] do_ip_setsockopt+0x9d/0xb55
[&lt;ffffffff81429818&gt;] ? unix_seqpacket_sendmsg+0x3f/0x41
[&lt;ffffffff813963fe&gt;] ? sock_sendmsg+0x6d/0x86
[&lt;ffffffff813959d4&gt;] ? sockfd_lookup_light+0x12/0x5d
[&lt;ffffffff8139650a&gt;] ? SyS_sendto+0xf3/0x11b
[&lt;ffffffff810d5738&gt;] ? new_sync_read+0x82/0xaa
[&lt;ffffffff813ddd19&gt;] compat_ip_setsockopt+0x3b/0x99
[&lt;ffffffff813fb24a&gt;] compat_raw_setsockopt+0x11/0x32
[&lt;ffffffff81399052&gt;] compat_sock_common_setsockopt+0x18/0x1f
[&lt;ffffffff813c4d05&gt;] compat_SyS_setsockopt+0x1a9/0x1cf
[&lt;ffffffff813c4149&gt;] compat_SyS_socketcall+0x180/0x1e3
[&lt;ffffffff81488ea1&gt;] cstar_dispatch+0x7/0x1e

Signed-off-by: Ani Sinha &lt;ani@arista.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: add length argument to skb_copy_and_csum_datagram_iovec</title>
<updated>2015-10-26T12:36:01+00:00</updated>
<author>
<name>Sabrina Dubroca</name>
<email>sd@queasysnail.net</email>
</author>
<published>2015-10-15T12:25:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3e1ac3aafbd0cf1f7c81cb7099a8a1d0407e021d'/>
<id>3e1ac3aafbd0cf1f7c81cb7099a8a1d0407e021d</id>
<content type='text'>
Without this length argument, we can read past the end of the iovec in
memcpy_toiovec because we have no way of knowing the total length of the
iovec's buffers.

This is needed for stable kernels where 89c22d8c3b27 ("net: Fix skb
csum races when peeking") has been backported but that don't have the
ioviter conversion, which is almost all the stable trees &lt;= 3.18.

This also fixes a kernel crash for NFS servers when the client uses
 -onfsvers=3,proto=udp to mount the export.

Signed-off-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Reviewed-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Without this length argument, we can read past the end of the iovec in
memcpy_toiovec because we have no way of knowing the total length of the
iovec's buffers.

This is needed for stable kernels where 89c22d8c3b27 ("net: Fix skb
csum races when peeking") has been backported but that don't have the
ioviter conversion, which is almost all the stable trees &lt;= 3.18.

This also fixes a kernel crash for NFS servers when the client uses
 -onfsvers=3,proto=udp to mount the export.

Signed-off-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Reviewed-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>inet: frags: fix defragmented packet's IP header for af_packet</title>
<updated>2015-08-27T07:27:02+00:00</updated>
<author>
<name>Edward Hyunkoo Jee</name>
<email>edjee@google.com</email>
</author>
<published>2015-07-21T07:43:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=76c4d538cebac5e63b08777903d53e4376e294da'/>
<id>76c4d538cebac5e63b08777903d53e4376e294da</id>
<content type='text'>
[ Upstream commit 0848f6428ba3a2e42db124d41ac6f548655735bf ]

When ip_frag_queue() computes positions, it assumes that the passed
sk_buff does not contain L2 headers.

However, when PACKET_FANOUT_FLAG_DEFRAG is used, IP reassembly
functions can be called on outgoing packets that contain L2 headers.

Also, IPv4 checksum is not corrected after reassembly.

Fixes: 7736d33f4262 ("packet: Add pre-defragmentation support for ipv4 fanouts.")
Signed-off-by: Edward Hyunkoo Jee &lt;edjee@google.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Willem de Bruijn &lt;willemb@google.com&gt;
Cc: Jerry Chu &lt;hkchu@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 0848f6428ba3a2e42db124d41ac6f548655735bf ]

When ip_frag_queue() computes positions, it assumes that the passed
sk_buff does not contain L2 headers.

However, when PACKET_FANOUT_FLAG_DEFRAG is used, IP reassembly
functions can be called on outgoing packets that contain L2 headers.

Also, IPv4 checksum is not corrected after reassembly.

Fixes: 7736d33f4262 ("packet: Add pre-defragmentation support for ipv4 fanouts.")
Signed-off-by: Edward Hyunkoo Jee &lt;edjee@google.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Willem de Bruijn &lt;willemb@google.com&gt;
Cc: Jerry Chu &lt;hkchu@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: lock socket in ip6_datagram_connect()</title>
<updated>2015-08-27T07:27:01+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-07-14T06:10:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b29321b96de6167daf84306903cedc5b214fe5b7'/>
<id>b29321b96de6167daf84306903cedc5b214fe5b7</id>
<content type='text'>
[ Upstream commit 03645a11a570d52e70631838cb786eb4253eb463 ]

ip6_datagram_connect() is doing a lot of socket changes without
socket being locked.

This looks wrong, at least for udp_lib_rehash() which could corrupt
lists because of concurrent udp_sk(sk)-&gt;udp_portaddr_hash accesses.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 03645a11a570d52e70631838cb786eb4253eb463 ]

ip6_datagram_connect() is doing a lot of socket changes without
socket being locked.

This looks wrong, at least for udp_lib_rehash() which could corrupt
lists because of concurrent udp_sk(sk)-&gt;udp_portaddr_hash accesses.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
</feed>
