<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/include/net/tcp.h, branch linux-4.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2018-05-23T01:33:44Z</updated>
<entry>
<title>tcp: sysctl: Fix a race to avoid unexpected 0 window from space</title>
<updated>2018-05-23T01:33:44Z</updated>
<author>
<name>Gao Feng</name>
<email>fgao@ikuai8.com</email>
</author>
<published>2017-03-23T23:05:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=39454594a620bb72218e2910574eb4614dd0ca99'/>
<id>urn:sha1:39454594a620bb72218e2910574eb4614dd0ca99</id>
<content type='text'>
[ Upstream commit c48367427a39ea0b85c7cf018fe4256627abfd9e ]

Because sysctl_tcp_adv_win_scale could be changed any time, so there
is one race in tcp_win_from_space.
For example,
1.sysctl_tcp_adv_win_scale&lt;=0 (sysctl_tcp_adv_win_scale is negative now)
2.space&gt;&gt;(-sysctl_tcp_adv_win_scale) (sysctl_tcp_adv_win_scale is postive now)

As a result, tcp_win_from_space returns 0. It is unexpected.

Certainly if the compiler put the sysctl_tcp_adv_win_scale into one
register firstly, then use the register directly, it would be ok.
But we could not depend on the compiler behavior.

Signed-off-by: Gao Feng &lt;fgao@ikuai8.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>tcp: fix tcp_mtu_probe() vs highest_sack</title>
<updated>2017-12-07T02:20:06Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2017-10-31T06:08:20Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5cabef21a8fa20704f23efa60d535a4ced702a38'/>
<id>urn:sha1:5cabef21a8fa20704f23efa60d535a4ced702a38</id>
<content type='text'>
[ 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-&gt;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-&gt;sacked_out,
since we want to replace tp-&gt;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 &lt;edumazet@google.com&gt;
Reported-by: Alexei Starovoitov &lt;alexei.starovoitov@gmail.com&gt;
Reported-by: Roman Gushchin &lt;guro@fb.com&gt;
Reported-by: Oleksandr Natalenko &lt;oleksandr@natalenko.name&gt;
Acked-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Acked-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Acked-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>tcp: fix use after free in tcp_xmit_retransmit_queue()</title>
<updated>2016-12-23T13:56:34Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2016-12-14T12:24:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9a66bc6ee0f9908ba98a7d19b94d49ec231ab0e1'/>
<id>urn:sha1:9a66bc6ee0f9908ba98a7d19b94d49ec231ab0e1</id>
<content type='text'>
[ Upstream commit bb1fceca22492109be12640d49f5ea5a544c6bb4 ]

When tcp_sendmsg() allocates a fresh and empty skb, it puts it at the
tail of the write queue using tcp_add_write_queue_tail()

Then it attempts to copy user data into this fresh skb.

If the copy fails, we undo the work and remove the fresh skb.

Unfortunately, this undo lacks the change done to tp-&gt;highest_sack and
we can leave a dangling pointer (to a freed skb)

Later, tcp_xmit_retransmit_queue() can dereference this pointer and
access freed memory. For regular kernels where memory is not unmapped,
this might cause SACK bugs because tcp_highest_sack_seq() is buggy,
returning garbage instead of tp-&gt;snd_nxt, but with various debug
features like CONFIG_DEBUG_PAGEALLOC, this can crash the kernel.

This bug was found by Marco Grassi thanks to syzkaller.

Fixes: 6859d49475d4 ("[TCP]: Abstract tp-&gt;highest_sack accessing &amp; point to next skb")
Reported-by: Marco Grassi &lt;marco.gra@gmail.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Ilpo Järvinen &lt;ilpo.jarvinen@helsinki.fi&gt;
Cc: Yuchung Cheng &lt;ycheng@google.com&gt;
Cc: Neal Cardwell &lt;ncardwell@google.com&gt;
Acked-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Reviewed-by: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
References: CVE-2016-6828
Signed-off-by: Philipp Hahn &lt;hahn@univention.de&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>tcp: prepare CC get_info() access from getsockopt()</title>
<updated>2015-04-29T21:10:38Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-04-28T23:23:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=64f40ff5bbdb1b679fb3c4dbc8230d6517d2b8dc'/>
<id>urn:sha1:64f40ff5bbdb1b679fb3c4dbc8230d6517d2b8dc</id>
<content type='text'>
We would like that optional info provided by Congestion Control
modules using netlink can also be read using getsockopt()

This patch changes get_info() to put this information in a buffer,
instead of skb, like tcp_get_info(), so that following patch
can reuse this common infrastructure.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Yuchung Cheng &lt;ycheng@google.com&gt;
Cc: Neal Cardwell &lt;ncardwell@google.com&gt;
Acked-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Acked-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>tcp: add tcpi_bytes_acked to tcp_info</title>
<updated>2015-04-29T21:10:37Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-04-28T22:28:17Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0df48c26d8418c5c9fba63fac15b660d70ca2f1c'/>
<id>urn:sha1:0df48c26d8418c5c9fba63fac15b660d70ca2f1c</id>
<content type='text'>
This patch tracks total number of bytes acked for a TCP socket.
This is the sum of all changes done to tp-&gt;snd_una, and allows
for precise tracking of delivered data.

RFC4898 named this : tcpEStatsAppHCThruOctetsAcked

This is a 64bit field, and can be fetched both from TCP_INFO
getsockopt() if one has a handle on a TCP socket, or from inet_diag
netlink facility (iproute2/ss patch will follow)

Note that tp-&gt;bytes_acked was placed near tp-&gt;snd_una for
best data locality and minimal performance impact.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Cc: Matt Mathis &lt;mattmathis@google.com&gt;
Cc: Eric Salo &lt;salo@google.com&gt;
Cc: Martin Lau &lt;kafai@fb.com&gt;
Cc: Chris Rapier &lt;rapier@psc.edu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>inet_diag: fix access to tcp cc information</title>
<updated>2015-04-17T17:28:31Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-04-17T01:10:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=521f1cf1dbb9d5ad858dca5dc75d1b45f64b6589'/>
<id>urn:sha1:521f1cf1dbb9d5ad858dca5dc75d1b45f64b6589</id>
<content type='text'>
Two different problems are fixed here :

1) inet_sk_diag_fill() might be called without socket lock held.
   icsk-&gt;icsk_ca_ops can change under us and module be unloaded.
   -&gt; Access to freed memory.
   Fix this using rcu_read_lock() to prevent module unload.

2) Some TCP Congestion Control modules provide information
   but again this is not safe against icsk-&gt;icsk_ca_ops
   change and nla_put() errors were ignored. Some sockets
   could not get the additional info if skb was almost full.

Fix this by returning a status from get_info() handlers and
using rcu protection as well.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>tcp: RFC7413 option support for Fast Open client</title>
<updated>2015-04-07T22:36:39Z</updated>
<author>
<name>Daniel Lee</name>
<email>Longinus00@gmail.com</email>
</author>
<published>2015-04-06T21:37:27Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2646c831c00c5d22aa72b79d24069c1b412cda7c'/>
<id>urn:sha1:2646c831c00c5d22aa72b79d24069c1b412cda7c</id>
<content type='text'>
Fast Open has been using an experimental option with a magic number
(RFC6994). This patch makes the client by default use the RFC7413
option (34) to get and send Fast Open cookies.  This patch makes
the client solicit cookies from a given server first with the
RFC7413 option. If that fails to elicit a cookie, then it tries
the RFC6994 experimental option. If that also fails, it uses the
RFC7413 option on all subsequent connect attempts.  If the server
returns a Fast Open cookie then the client caches the form of the
option that successfully elicited a cookie, and uses that form on
later connects when it presents that cookie.

The idea is to gradually obsolete the use of experimental options as
the servers and clients upgrade, while keeping the interoperability
meanwhile.

Signed-off-by: Daniel Lee &lt;Longinus00@gmail.com&gt;
Signed-off-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Signed-off-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>tcp: RFC7413 option support for Fast Open server</title>
<updated>2015-04-07T22:36:39Z</updated>
<author>
<name>Daniel Lee</name>
<email>Longinus00@gmail.com</email>
</author>
<published>2015-04-06T21:37:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7f9b838b71eb78a27de27a12ca5de8542fac3115'/>
<id>urn:sha1:7f9b838b71eb78a27de27a12ca5de8542fac3115</id>
<content type='text'>
Fast Open has been using the experimental option with a magic number
(RFC6994) to request and grant Fast Open cookies. This patch enables
the server to support the official IANA option 34 in RFC7413 in
addition.

The change has passed all existing Fast Open tests with both
old and new options at Google.

Signed-off-by: Daniel Lee &lt;Longinus00@gmail.com&gt;
Signed-off-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Signed-off-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>tcp: tcp_syn_flood_action() can be static</title>
<updated>2015-03-29T19:17:18Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-03-25T22:08:47Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=41d25fe0927aabb1d4b671871a99a55bcd203257'/>
<id>urn:sha1:41d25fe0927aabb1d4b671871a99a55bcd203257</id>
<content type='text'>
After commit 1fb6f159fd21 ("tcp: add tcp_conn_request"),
tcp_syn_flood_action() is no longer used from IPv6.

We can make it static, by moving it above tcp_conn_request()

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reviewed-by: Octavian Purdila &lt;octavian.purdila@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>tcp: md5: get rid of tcp_v[46]_reqsk_md5_lookup()</title>
<updated>2015-03-25T01:16:30Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2015-03-24T22:58:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fd3a154a00fb991872680f19021f5edbb40b4dbe'/>
<id>urn:sha1:fd3a154a00fb991872680f19021f5edbb40b4dbe</id>
<content type='text'>
With request socks convergence, we no longer need
different lookup methods. A request socket can
use generic lookup function.

Add const qualifier to 2nd tcp_v[46]_md5_lookup() parameter.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
