<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/ipv4, branch v3.2.75</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>net: add validation for the socket syscall protocol argument</title>
<updated>2015-12-30T02:26:03+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=ef6d51d24d878be2291d7af783441356eb77649d'/>
<id>ef6d51d24d878be2291d7af783441356eb77649d</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;
[bwh: Backported to 3.2: open-code U8_MAX]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&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;
[bwh: Backported to 3.2: open-code U8_MAX]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: ipmr: fix static mfc/dev leaks on table destruction</title>
<updated>2015-12-30T02:26:02+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=80996afb50f7ffa1a7d07d2ad3320afd32e82f56'/>
<id>80996afb50f7ffa1a7d07d2ad3320afd32e82f56</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;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&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;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tcp: initialize tp-&gt;copied_seq in case of cross SYN connection</title>
<updated>2015-12-30T02:26:01+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=6cfa9781d3bf950eed455369966bbdf9d05871c5'/>
<id>6cfa9781d3bf950eed455369966bbdf9d05871c5</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: Ben Hutchings &lt;ben@decadent.org.uk&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: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv4: igmp: Allow removing groups from a removed interface</title>
<updated>2015-12-30T02:25:59+00:00</updated>
<author>
<name>Andrew Lunn</name>
<email>andrew@lunn.ch</email>
</author>
<published>2015-12-01T15:31:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b1fa852672fb1ea4b0e34bfa1136bb65dba66151'/>
<id>b1fa852672fb1ea4b0e34bfa1136bb65dba66151</id>
<content type='text'>
commit 4eba7bb1d72d9bde67d810d09bf62dc207b63c5c upstream.

When a multicast group is joined on a socket, a struct ip_mc_socklist
is appended to the sockets mc_list containing information about the
joined group.

If the interface is hot unplugged, this entry becomes stale. Prior to
commit 52ad353a5344f ("igmp: fix the problem when mc leave group") it
was possible to remove the stale entry by performing a
IP_DROP_MEMBERSHIP, passing either the old ifindex or ip address on
the interface. However, this fix enforces that the interface must
still exist. Thus with time, the number of stale entries grows, until
sysctl_igmp_max_memberships is reached and then it is not possible to
join and more groups.

The previous patch fixes an issue where a IP_DROP_MEMBERSHIP is
performed without specifying the interface, either by ifindex or ip
address. However here we do supply one of these. So loosen the
restriction on device existence to only apply when the interface has
not been specified. This then restores the ability to clean up the
stale entries.

Signed-off-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Fixes: 52ad353a5344f "(igmp: fix the problem when mc leave group")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4eba7bb1d72d9bde67d810d09bf62dc207b63c5c upstream.

When a multicast group is joined on a socket, a struct ip_mc_socklist
is appended to the sockets mc_list containing information about the
joined group.

If the interface is hot unplugged, this entry becomes stale. Prior to
commit 52ad353a5344f ("igmp: fix the problem when mc leave group") it
was possible to remove the stale entry by performing a
IP_DROP_MEMBERSHIP, passing either the old ifindex or ip address on
the interface. However, this fix enforces that the interface must
still exist. Thus with time, the number of stale entries grows, until
sysctl_igmp_max_memberships is reached and then it is not possible to
join and more groups.

The previous patch fixes an issue where a IP_DROP_MEMBERSHIP is
performed without specifying the interface, either by ifindex or ip
address. However here we do supply one of these. So loosen the
restriction on device existence to only apply when the interface has
not been specified. This then restores the ability to clean up the
stale entries.

Signed-off-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Fixes: 52ad353a5344f "(igmp: fix the problem when mc leave group")
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&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-27T12:48:25+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=33cf84ba8c25b40c7de52029efc8d4372725c95f'/>
<id>33cf84ba8c25b40c7de52029efc8d4372725c95f</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;
[bwh: Backported to 3.2: ipmr doesn't implement IPSTATS_MIB_OUTOCTETS]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&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;
[bwh: Backported to 3.2: ipmr doesn't implement IPSTATS_MIB_OUTOCTETS]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: add length argument to skb_copy_and_csum_datagram_iovec</title>
<updated>2015-11-17T15:54:45+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=127500d724f8c43f452610c9080444eedb5eaa6c'/>
<id>127500d724f8c43f452610c9080444eedb5eaa6c</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;
[bwh: Backported to 3.2: adjust context in include/linux/skbuff.h]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&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;
[bwh: Backported to 3.2: adjust context in include/linux/skbuff.h]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: lock socket in ip6_datagram_connect()</title>
<updated>2015-10-13T02:46:12+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=c1a7dedbcb0b60ecbcda0d2398ad5d2b078c9f47'/>
<id>c1a7dedbcb0b60ecbcda0d2398ad5d2b078c9f47</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;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&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;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>inet: frags: fix defragmented packet's IP header for af_packet</title>
<updated>2015-08-12T14:33:22+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=8c3d7424eb960448262e12d888f8093a39548c91'/>
<id>8c3d7424eb960448262e12d888f8093a39548c91</id>
<content type='text'>
commit 0848f6428ba3a2e42db124d41ac6f548655735bf upstream.

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;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0848f6428ba3a2e42db124d41ac6f548655735bf upstream.

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;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>udp: fix behavior of wrong checksums</title>
<updated>2015-08-06T23:32:15+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-05-30T16:16:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=556574d97b6e0c2970b7e5ab693bcf35f73195fa'/>
<id>556574d97b6e0c2970b7e5ab693bcf35f73195fa</id>
<content type='text'>
commit beb39db59d14990e401e235faf66a6b9b31240b0 upstream.

We have two problems in UDP stack related to bogus checksums :

1) We return -EAGAIN to application even if receive queue is not empty.
   This breaks applications using edge trigger epoll()

2) Under UDP flood, we can loop forever without yielding to other
   processes, potentially hanging the host, especially on non SMP.

This patch is an attempt to make things better.

We might in the future add extra support for rt applications
wanting to better control time spent doing a recv() in a hostile
environment. For example we could validate checksums before queuing
packets in socket receive queue.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Willem de Bruijn &lt;willemb@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit beb39db59d14990e401e235faf66a6b9b31240b0 upstream.

We have two problems in UDP stack related to bogus checksums :

1) We return -EAGAIN to application even if receive queue is not empty.
   This breaks applications using edge trigger epoll()

2) Under UDP flood, we can loop forever without yielding to other
   processes, potentially hanging the host, especially on non SMP.

This patch is an attempt to make things better.

We might in the future add extra support for rt applications
wanting to better control time spent doing a recv() in a hostile
environment. For example we could validate checksums before queuing
packets in socket receive queue.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Willem de Bruijn &lt;willemb@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tcp: avoid looping in tcp_send_fin()</title>
<updated>2015-05-09T22:16:40+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-04-23T17:42:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=82241580d7734af2207ad0bb1720904f569dac3a'/>
<id>82241580d7734af2207ad0bb1720904f569dac3a</id>
<content type='text'>
[ Upstream commit 845704a535e9b3c76448f52af1b70e4422ea03fd ]

Presence of an unbound loop in tcp_send_fin() had always been hard
to explain when analyzing crash dumps involving gigantic dying processes
with millions of sockets.

Lets try a different strategy :

In case of memory pressure, try to add the FIN flag to last packet
in write queue, even if packet was already sent. TCP stack will
be able to deliver this FIN after a timeout event. Note that this
FIN being delivered by a retransmit, it also carries a Push flag
given our current implementation.

By checking sk_under_memory_pressure(), we anticipate that cooking
many FIN packets might deplete tcp memory.

In the case we could not allocate a packet, even with __GFP_WAIT
allocation, then not sending a FIN seems quite reasonable if it allows
to get rid of this socket, free memory, and not block the process from
eventually doing other useful work.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[bwh: Backported to 3.2:
 - Drop inapplicable change to sk_forced_wmem_schedule()
 - s/sk_under_memory_pressure(sk)/tcp_memory_pressure/]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 845704a535e9b3c76448f52af1b70e4422ea03fd ]

Presence of an unbound loop in tcp_send_fin() had always been hard
to explain when analyzing crash dumps involving gigantic dying processes
with millions of sockets.

Lets try a different strategy :

In case of memory pressure, try to add the FIN flag to last packet
in write queue, even if packet was already sent. TCP stack will
be able to deliver this FIN after a timeout event. Note that this
FIN being delivered by a retransmit, it also carries a Push flag
given our current implementation.

By checking sk_under_memory_pressure(), we anticipate that cooking
many FIN packets might deplete tcp memory.

In the case we could not allocate a packet, even with __GFP_WAIT
allocation, then not sending a FIN seems quite reasonable if it allows
to get rid of this socket, free memory, and not block the process from
eventually doing other useful work.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[bwh: Backported to 3.2:
 - Drop inapplicable change to sk_forced_wmem_schedule()
 - s/sk_under_memory_pressure(sk)/tcp_memory_pressure/]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
