<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/net/dccp/minisocks.c, branch linux-3.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.18.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.18.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2017-04-18T05:55:52Z</updated>
<entry>
<title>dccp: Unlock sock before calling sk_free()</title>
<updated>2017-04-18T05:55:52Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
</author>
<published>2017-03-01T19:35:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7b91d97839a8cee76e73de11d17ba470a77e017b'/>
<id>urn:sha1:7b91d97839a8cee76e73de11d17ba470a77e017b</id>
<content type='text'>
commit d5afb6f9b6bb2c57bd0c05e76e12489dc0d037d9 upstream.

The code where sk_clone() came from created a new socket and locked it,
but then, on the error path didn't unlock it.

This problem stayed there for a long while, till b0691c8ee7c2 ("net:
Unlock sock before calling sk_free()") fixed it, but unfortunately the
callers of sk_clone() (now sk_clone_locked()) were not audited and the
one in dccp_create_openreq_child() remained.

Now in the age of the syskaller fuzzer, this was finally uncovered, as
reported by Dmitry:

 ---- 8&lt; ----

I've got the following report while running syzkaller fuzzer on
86292b33d4b7 ("Merge branch 'akpm' (patches from Andrew)")

  [ BUG: held lock freed! ]
  4.10.0+ #234 Not tainted
  -------------------------
  syz-executor6/6898 is freeing memory
  ffff88006286cac0-ffff88006286d3b7, with a lock still held there!
   (slock-AF_INET6){+.-...}, at: [&lt;ffffffff8362c2c9&gt;] spin_lock
  include/linux/spinlock.h:299 [inline]
   (slock-AF_INET6){+.-...}, at: [&lt;ffffffff8362c2c9&gt;]
  sk_clone_lock+0x3d9/0x12c0 net/core/sock.c:1504
  5 locks held by syz-executor6/6898:
   #0:  (sk_lock-AF_INET6){+.+.+.}, at: [&lt;ffffffff839a34b4&gt;] lock_sock
  include/net/sock.h:1460 [inline]
   #0:  (sk_lock-AF_INET6){+.+.+.}, at: [&lt;ffffffff839a34b4&gt;]
  inet_stream_connect+0x44/0xa0 net/ipv4/af_inet.c:681
   #1:  (rcu_read_lock){......}, at: [&lt;ffffffff83bc1c2a&gt;]
  inet6_csk_xmit+0x12a/0x5d0 net/ipv6/inet6_connection_sock.c:126
   #2:  (rcu_read_lock){......}, at: [&lt;ffffffff8369b424&gt;] __skb_unlink
  include/linux/skbuff.h:1767 [inline]
   #2:  (rcu_read_lock){......}, at: [&lt;ffffffff8369b424&gt;] __skb_dequeue
  include/linux/skbuff.h:1783 [inline]
   #2:  (rcu_read_lock){......}, at: [&lt;ffffffff8369b424&gt;]
  process_backlog+0x264/0x730 net/core/dev.c:4835
   #3:  (rcu_read_lock){......}, at: [&lt;ffffffff83aeb5c0&gt;]
  ip6_input_finish+0x0/0x1700 net/ipv6/ip6_input.c:59
   #4:  (slock-AF_INET6){+.-...}, at: [&lt;ffffffff8362c2c9&gt;] spin_lock
  include/linux/spinlock.h:299 [inline]
   #4:  (slock-AF_INET6){+.-...}, at: [&lt;ffffffff8362c2c9&gt;]
  sk_clone_lock+0x3d9/0x12c0 net/core/sock.c:1504

Fix it just like was done by b0691c8ee7c2 ("net: Unlock sock before calling
sk_free()").

Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Cc: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: http://lkml.kernel.org/r/20170301153510.GE15145@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>inet: move ipv6only in sock_common</title>
<updated>2014-07-02T06:46:21Z</updated>
<author>
<name>Eric Dumazet</name>
</author>
<published>2014-06-27T15:36:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9fe516ba3fb29b6f6a752ffd93342fdee500ec01'/>
<id>urn:sha1:9fe516ba3fb29b6f6a752ffd93342fdee500ec01</id>
<content type='text'>
When an UDP application switches from AF_INET to AF_INET6 sockets, we
have a small performance degradation for IPv4 communications because of
extra cache line misses to access ipv6only information.

This can also be noticed for TCP listeners, as ipv6_only_sock() is also
used from __inet_lookup_listener()-&gt;compute_score()

This is magnified when SO_REUSEPORT is used.

Move ipv6only into struct sock_common so that it is available at
no extra cost in lookups.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: Fix use after free by removing length arg from sk_data_ready callbacks.</title>
<updated>2014-04-11T20:15:36Z</updated>
<author>
<name>David S. Miller</name>
</author>
<published>2014-04-11T20:15:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=676d23690fb62b5d51ba5d659935e9f7d9da9f8e'/>
<id>urn:sha1:676d23690fb62b5d51ba5d659935e9f7d9da9f8e</id>
<content type='text'>
Several spots in the kernel perform a sequence like:

	skb_queue_tail(&amp;sk-&gt;s_receive_queue, skb);
	sk-&gt;sk_data_ready(sk, skb-&gt;len);

But at the moment we place the SKB onto the socket receive queue it
can be consumed and freed up.  So this skb-&gt;len access is potentially
to freed up memory.

Furthermore, the skb-&gt;len can be modified by the consumer so it is
possible that the value isn't accurate.

And finally, no actual implementation of this callback actually uses
the length argument.  And since nobody actually cared about it's
value, lots of call sites pass arbitrary values in such as '0' and
even '1'.

So just remove the length argument from the callback, that way there
is no confusion whatsoever and all of these use-after-free cases get
fixed as a side effect.

Based upon a patch by Eric Dumazet and his suggestion to audit this
issue tree-wide.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>inet: rename ir_loc_port to ir_num</title>
<updated>2013-10-10T18:37:35Z</updated>
<author>
<name>Eric Dumazet</name>
</author>
<published>2013-10-10T07:04:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b44084c2c822f99dd3f2334b288b7e463d222662'/>
<id>urn:sha1:b44084c2c822f99dd3f2334b288b7e463d222662</id>
<content type='text'>
In commit 634fb979e8f ("inet: includes a sock_common in request_sock")
I forgot that the two ports in sock_common do not have same byte order :

skc_dport is __be16 (network order), but skc_num is __u16 (host order)

So sparse complains because ir_loc_port (mapped into skc_num) is
considered as __u16 while it should be __be16

Let rename ir_loc_port to ireq-&gt;ir_num (analogy with inet-&gt;inet_num),
and perform appropriate htons/ntohs conversions.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: Wu Fengguang &lt;fengguang.wu@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>inet: includes a sock_common in request_sock</title>
<updated>2013-10-10T04:08:07Z</updated>
<author>
<name>Eric Dumazet</name>
</author>
<published>2013-10-09T22:21:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=634fb979e8f3a70f04c1f2f519d0cd1142eb5c1a'/>
<id>urn:sha1:634fb979e8f3a70f04c1f2f519d0cd1142eb5c1a</id>
<content type='text'>
TCP listener refactoring, part 5 :

We want to be able to insert request sockets (SYN_RECV) into main
ehash table instead of the per listener hash table to allow RCU
lookups and remove listener lock contention.

This patch includes the needed struct sock_common in front
of struct request_sock

This means there is no more inet6_request_sock IPv6 specific
structure.

Following inet_request_sock fields were renamed as they became
macros to reference fields from struct sock_common.
Prefix ir_ was chosen to avoid name collisions.

loc_port   -&gt; ir_loc_port
loc_addr   -&gt; ir_loc_addr
rmt_addr   -&gt; ir_rmt_addr
rmt_port   -&gt; ir_rmt_port
iif        -&gt; ir_iif

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ipv6: make lookups simpler and faster</title>
<updated>2013-10-09T04:01:25Z</updated>
<author>
<name>Eric Dumazet</name>
</author>
<published>2013-10-03T22:42:29Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=efe4208f47f907b86f528788da711e8ab9dea44d'/>
<id>urn:sha1:efe4208f47f907b86f528788da711e8ab9dea44d</id>
<content type='text'>
TCP listener refactoring, part 4 :

To speed up inet lookups, we moved IPv4 addresses from inet to struct
sock_common

Now is time to do the same for IPv6, because it permits us to have fast
lookups for all kind of sockets, including upcoming SYN_RECV.

Getting IPv6 addresses in TCP lookups currently requires two extra cache
lines, plus a dereference (and memory stall).

inet6_sk(sk) does the dereference of inet_sk(__sk)-&gt;pinet6

This patch is way bigger than its IPv4 counter part, because for IPv4,
we could add aliases (inet_daddr, inet_rcv_saddr), while on IPv6,
it's not doable easily.

inet6_sk(sk)-&gt;daddr becomes sk-&gt;sk_v6_daddr
inet6_sk(sk)-&gt;rcv_saddr becomes sk-&gt;sk_v6_rcv_saddr

And timewait socket also have tw-&gt;tw_v6_daddr &amp; tw-&gt;tw_v6_rcv_saddr
at the same offset.

We get rid of INET6_TW_MATCH() as INET6_MATCH() is now the generic
macro.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>tcp: better retrans tracking for defer-accept</title>
<updated>2012-11-03T18:45:00Z</updated>
<author>
<name>Eric Dumazet</name>
</author>
<published>2012-10-27T23:16:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e6c022a4fa2d2d9ca9d0a7ac3b05ad988f39fc30'/>
<id>urn:sha1:e6c022a4fa2d2d9ca9d0a7ac3b05ad988f39fc30</id>
<content type='text'>
For passive TCP connections using TCP_DEFER_ACCEPT facility,
we incorrectly increment req-&gt;retrans each time timeout triggers
while no SYNACK is sent.

SYNACK are not sent for TCP_DEFER_ACCEPT that were established (for
which we received the ACK from client). Only the last SYNACK is sent
so that we can receive again an ACK from client, to move the req into
accept queue. We plan to change this later to avoid the useless
retransmit (and potential problem as this SYNACK could be lost)

TCP_INFO later gives wrong information to user, claiming imaginary
retransmits.

Decouple req-&gt;retrans field into two independent fields :

num_retrans : number of retransmit
num_timeout : number of timeouts

num_timeout is the counter that is incremented at each timeout,
regardless of actual SYNACK being sent or not, and used to
compute the exponential timeout.

Introduce inet_rtx_syn_ack() helper to increment num_retrans
only if -&gt;rtx_syn_ack() succeeded.

Use inet_rtx_syn_ack() from tcp_check_req() to increment num_retrans
when we re-send a SYNACK in answer to a (retransmitted) SYN.
Prior to this patch, we were not counting these retransmits.

Change tcp_v[46]_rtx_synack() to increment TCP_MIB_RETRANSSEGS
only if a synack packet was successfully queued.

Reported-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Julian Anastasov &lt;ja@ssi.bg&gt;
Cc: Vijay Subramanian &lt;subramanian.vijay@gmail.com&gt;
Cc: Elliott Hughes &lt;enh@google.com&gt;
Cc: Neal Cardwell &lt;ncardwell@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>dccp: fix bug in sequence number validation during connection setup</title>
<updated>2012-03-03T16:02:52Z</updated>
<author>
<name>Samuel Jero</name>
</author>
<published>2012-02-27T01:22:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f541fb7e20c848f947ca65fbf169efe69400c942'/>
<id>urn:sha1:f541fb7e20c848f947ca65fbf169efe69400c942</id>
<content type='text'>
This fixes a bug in the sequence number validation during the initial handshake.

The code did not treat the initial sequence numbers ISS and ISR as read-only and
did not keep state for GSR and GSS as required by the specification. This causes
problems with retransmissions during the initial handshake, causing the
budding connection to be reset.

This patch now treats ISS/ISR as read-only and tracks GSS/GSR as required.

Signed-off-by: Samuel Jero &lt;sj323707@ohio.edu&gt;
Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
</content>
</entry>
<entry>
<title>net: use IS_ENABLED(CONFIG_IPV6)</title>
<updated>2011-12-11T23:25:16Z</updated>
<author>
<name>Eric Dumazet</name>
</author>
<published>2011-12-10T09:48:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=dfd56b8b38fff3586f36232db58e1e9f7885a605'/>
<id>urn:sha1:dfd56b8b38fff3586f36232db58e1e9f7885a605</id>
<content type='text'>
Instead of testing defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)

Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: remove ipv6_addr_copy()</title>
<updated>2011-11-22T21:43:32Z</updated>
<author>
<name>Alexey Dobriyan</name>
</author>
<published>2011-11-21T03:39:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4e3fd7a06dc20b2d8ec6892233ad2012968fe7b6'/>
<id>urn:sha1:4e3fd7a06dc20b2d8ec6892233ad2012968fe7b6</id>
<content type='text'>
C assignment can handle struct in6_addr copying.

Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
