<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/net/rds, branch v3.15.2</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/net/rds?h=v3.15.2</id>
<link rel='self' href='https://git.amat.us/linux/atom/net/rds?h=v3.15.2'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-04-11T20:15:36Z</updated>
<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>
<email>davem@davemloft.net</email>
</author>
<published>2014-04-11T20:15:36Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/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>rds: prevent dereference of a NULL device in rds_iw_laddr_check</title>
<updated>2014-03-31T20:25:52Z</updated>
<author>
<name>Sasha Levin</name>
<email>sasha.levin@oracle.com</email>
</author>
<published>2014-03-30T00:39:35Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=bf39b4247b8799935ea91d90db250ab608a58e50'/>
<id>urn:sha1:bf39b4247b8799935ea91d90db250ab608a58e50</id>
<content type='text'>
Binding might result in a NULL device which is later dereferenced
without checking.

Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: add build-time checks for msg-&gt;msg_name size</title>
<updated>2014-01-19T07:04:16Z</updated>
<author>
<name>Steffen Hurrle</name>
<email>steffen@hurrle.net</email>
</author>
<published>2014-01-17T21:53:15Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=342dfc306fb32155314dad277f3c3686b83fb9f1'/>
<id>urn:sha1:342dfc306fb32155314dad277f3c3686b83fb9f1</id>
<content type='text'>
This is a follow-up patch to f3d3342602f8bc ("net: rework recvmsg
handler msg_name and msg_namelen logic").

DECLARE_SOCKADDR validates that the structure we use for writing the
name information to is not larger than the buffer which is reserved
for msg-&gt;msg_name (which is 128 bytes). Also use DECLARE_SOCKADDR
consistently in sendmsg code paths.

Signed-off-by: Steffen Hurrle &lt;steffen@hurrle.net&gt;
Suggested-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2014-01-18T08:55:41Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2014-01-18T08:55:41Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=41804420586ab41049a14ab7ef04eaa2280b8647'/>
<id>urn:sha1:41804420586ab41049a14ab7ef04eaa2280b8647</id>
<content type='text'>
Conflicts:
	drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
	net/ipv4/tcp_metrics.c

Overlapping changes between the "don't create two tcp metrics objects
with the same key" race fix in net and the addition of the destination
address in the lookup key in net-next.

Minor overlapping changes in bnx2x driver.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: rds: fix per-cpu helper usage</title>
<updated>2014-01-18T01:52:22Z</updated>
<author>
<name>Gerald Schaefer</name>
<email>gerald.schaefer@de.ibm.com</email>
</author>
<published>2014-01-16T15:54:48Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c196403b79aa241c3fefb3ee5bb328aa7c5cc860'/>
<id>urn:sha1:c196403b79aa241c3fefb3ee5bb328aa7c5cc860</id>
<content type='text'>
commit ae4b46e9d "net: rds: use this_cpu_* per-cpu helper" broke per-cpu
handling for rds. chpfirst is the result of __this_cpu_read(), so it is
an absolute pointer and not __percpu. Therefore, __this_cpu_write()
should not operate on chpfirst, but rather on cache-&gt;percpu-&gt;first, just
like __this_cpu_read() did before.

Cc: &lt;stable@vger.kernel.org&gt; # 3.8+
Signed-off-byd Gerald Schaefer &lt;gerald.schaefer@de.ibm.com&gt;

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: replace macros net_random and net_srandom with direct calls to prandom</title>
<updated>2014-01-14T23:15:25Z</updated>
<author>
<name>Aruna-Hewapathirane</name>
<email>aruna.hewapathirane@gmail.com</email>
</author>
<published>2014-01-11T12:15:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=63862b5bef7349dd1137e4c70702c67d77565785'/>
<id>urn:sha1:63862b5bef7349dd1137e4c70702c67d77565785</id>
<content type='text'>
This patch removes the net_random and net_srandom macros and replaces
them with direct calls to the prandom ones. As new commits only seem to
use prandom_u32 there is no use to keep them around.
This change makes it easier to grep for users of prandom_u32.

Signed-off-by: Aruna-Hewapathirane &lt;aruna.hewapathirane@gmail.com&gt;
Suggested-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>rds: prevent dereference of a NULL device</title>
<updated>2013-12-27T17:33:58Z</updated>
<author>
<name>Sasha Levin</name>
<email>sasha.levin@oracle.com</email>
</author>
<published>2013-12-19T04:49:42Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c2349758acf1874e4c2b93fe41d072336f1a31d0'/>
<id>urn:sha1:c2349758acf1874e4c2b93fe41d072336f1a31d0</id>
<content type='text'>
Binding might result in a NULL device, which is dereferenced
causing this BUG:

[ 1317.260548] BUG: unable to handle kernel NULL pointer dereference at 000000000000097
4
[ 1317.261847] IP: [&lt;ffffffff84225f52&gt;] rds_ib_laddr_check+0x82/0x110
[ 1317.263315] PGD 418bcb067 PUD 3ceb21067 PMD 0
[ 1317.263502] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 1317.264179] Dumping ftrace buffer:
[ 1317.264774]    (ftrace buffer empty)
[ 1317.265220] Modules linked in:
[ 1317.265824] CPU: 4 PID: 836 Comm: trinity-child46 Tainted: G        W    3.13.0-rc4-
next-20131218-sasha-00013-g2cebb9b-dirty #4159
[ 1317.267415] task: ffff8803ddf33000 ti: ffff8803cd31a000 task.ti: ffff8803cd31a000
[ 1317.268399] RIP: 0010:[&lt;ffffffff84225f52&gt;]  [&lt;ffffffff84225f52&gt;] rds_ib_laddr_check+
0x82/0x110
[ 1317.269670] RSP: 0000:ffff8803cd31bdf8  EFLAGS: 00010246
[ 1317.270230] RAX: 0000000000000000 RBX: ffff88020b0dd388 RCX: 0000000000000000
[ 1317.270230] RDX: ffffffff8439822e RSI: 00000000000c000a RDI: 0000000000000286
[ 1317.270230] RBP: ffff8803cd31be38 R08: 0000000000000000 R09: 0000000000000000
[ 1317.270230] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
[ 1317.270230] R13: 0000000054086700 R14: 0000000000a25de0 R15: 0000000000000031
[ 1317.270230] FS:  00007ff40251d700(0000) GS:ffff88022e200000(0000) knlGS:000000000000
0000
[ 1317.270230] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1317.270230] CR2: 0000000000000974 CR3: 00000003cd478000 CR4: 00000000000006e0
[ 1317.270230] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1317.270230] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000090602
[ 1317.270230] Stack:
[ 1317.270230]  0000000054086700 5408670000a25de0 5408670000000002 0000000000000000
[ 1317.270230]  ffffffff84223542 00000000ea54c767 0000000000000000 ffffffff86d26160
[ 1317.270230]  ffff8803cd31be68 ffffffff84223556 ffff8803cd31beb8 ffff8800c6765280
[ 1317.270230] Call Trace:
[ 1317.270230]  [&lt;ffffffff84223542&gt;] ? rds_trans_get_preferred+0x42/0xa0
[ 1317.270230]  [&lt;ffffffff84223556&gt;] rds_trans_get_preferred+0x56/0xa0
[ 1317.270230]  [&lt;ffffffff8421c9c3&gt;] rds_bind+0x73/0xf0
[ 1317.270230]  [&lt;ffffffff83e4ce62&gt;] SYSC_bind+0x92/0xf0
[ 1317.270230]  [&lt;ffffffff812493f8&gt;] ? context_tracking_user_exit+0xb8/0x1d0
[ 1317.270230]  [&lt;ffffffff8119313d&gt;] ? trace_hardirqs_on+0xd/0x10
[ 1317.270230]  [&lt;ffffffff8107a852&gt;] ? syscall_trace_enter+0x32/0x290
[ 1317.270230]  [&lt;ffffffff83e4cece&gt;] SyS_bind+0xe/0x10
[ 1317.270230]  [&lt;ffffffff843a6ad0&gt;] tracesys+0xdd/0xe2
[ 1317.270230] Code: 00 8b 45 cc 48 8d 75 d0 48 c7 45 d8 00 00 00 00 66 c7 45 d0 02 00
89 45 d4 48 89 df e8 78 49 76 ff 41 89 c4 85 c0 75 0c 48 8b 03 &lt;80&gt; b8 74 09 00 00 01 7
4 06 41 bc 9d ff ff ff f6 05 2a b6 c2 02
[ 1317.270230] RIP  [&lt;ffffffff84225f52&gt;] rds_ib_laddr_check+0x82/0x110
[ 1317.270230]  RSP &lt;ffff8803cd31bdf8&gt;
[ 1317.270230] CR2: 0000000000000974

Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>rds: prevent BUG_ON triggered on congestion update to loopback</title>
<updated>2013-12-03T16:54:18Z</updated>
<author>
<name>Venkat Venkatsubra</name>
<email>venkat.x.venkatsubra@oracle.com</email>
</author>
<published>2013-12-02T23:41:39Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=18fc25c94eadc52a42c025125af24657a93638c0'/>
<id>urn:sha1:18fc25c94eadc52a42c025125af24657a93638c0</id>
<content type='text'>
After congestion update on a local connection, when rds_ib_xmit returns
less bytes than that are there in the message, rds_send_xmit calls
back rds_ib_xmit with an offset that causes BUG_ON(off &amp; RDS_FRAG_SIZE)
to trigger.

For a 4Kb PAGE_SIZE rds_ib_xmit returns min(8240,4096)=4096 when actually
the message contains 8240 bytes. rds_send_xmit thinks there is more to send
and calls rds_ib_xmit again with a data offset "off" of 4096-48(rds header)
=4048 bytes thus hitting the BUG_ON(off &amp; RDS_FRAG_SIZE) [RDS_FRAG_SIZE=4k].

The commit 6094628bfd94323fc1cea05ec2c6affd98c18f7f
"rds: prevent BUG_ON triggering on congestion map updates" introduced
this regression. That change was addressing the triggering of a different
BUG_ON in rds_send_xmit() on PowerPC architecture with 64Kbytes PAGE_SIZE:
 	BUG_ON(ret != 0 &amp;&amp;
    		 conn-&gt;c_xmit_sg == rm-&gt;data.op_nents);
This was the sequence it was going through:
(rds_ib_xmit)
/* Do not send cong updates to IB loopback */
if (conn-&gt;c_loopback
   &amp;&amp; rm-&gt;m_inc.i_hdr.h_flags &amp; RDS_FLAG_CONG_BITMAP) {
  	rds_cong_map_updated(conn-&gt;c_fcong, ~(u64) 0);
    	return sizeof(struct rds_header) + RDS_CONG_MAP_BYTES;
}
rds_ib_xmit returns 8240
rds_send_xmit:
  c_xmit_data_off = 0 + 8240 - 48 (rds header accounted only the first time)
   		 = 8192
  c_xmit_data_off &lt; 65536 (sg-&gt;length), so calls rds_ib_xmit again
rds_ib_xmit returns 8240
rds_send_xmit:
  c_xmit_data_off = 8192 + 8240 = 16432, calls rds_ib_xmit again
  and so on (c_xmit_data_off 24672,32912,41152,49392,57632)
rds_ib_xmit returns 8240
On this iteration this sequence causes the BUG_ON in rds_send_xmit:
    while (ret) {
    	tmp = min_t(int, ret, sg-&gt;length - conn-&gt;c_xmit_data_off);
    	[tmp = 65536 - 57632 = 7904]
    	conn-&gt;c_xmit_data_off += tmp;
    	[c_xmit_data_off = 57632 + 7904 = 65536]
    	ret -= tmp;
    	[ret = 8240 - 7904 = 336]
    	if (conn-&gt;c_xmit_data_off == sg-&gt;length) {
    		conn-&gt;c_xmit_data_off = 0;
    		sg++;
    		conn-&gt;c_xmit_sg++;
    		BUG_ON(ret != 0 &amp;&amp;
    			conn-&gt;c_xmit_sg == rm-&gt;data.op_nents);
    		[c_xmit_sg = 1, rm-&gt;data.op_nents = 1]

What the current fix does:
Since the congestion update over loopback is not actually transmitted
as a message, all that rds_ib_xmit needs to do is let the caller think
the full message has been transmitted and not return partial bytes.
It will return 8240 (RDS_CONG_MAP_BYTES+48) when PAGE_SIZE is 4Kb.
And 64Kb+48 when page size is 64Kb.

Reported-by: Josh Hunt &lt;joshhunt00@gmail.com&gt;
Tested-by: Honggang Li &lt;honli@redhat.com&gt;
Acked-by: Bang Nguyen &lt;bang.nguyen@oracle.com&gt;
Signed-off-by: Venkat Venkatsubra &lt;venkat.x.venkatsubra@oracle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: rework recvmsg handler msg_name and msg_namelen logic</title>
<updated>2013-11-21T02:52:30Z</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2013-11-21T02:14:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f3d3342602f8bcbf37d7c46641cb9bca7618eb1c'/>
<id>urn:sha1:f3d3342602f8bcbf37d7c46641cb9bca7618eb1c</id>
<content type='text'>
This patch now always passes msg-&gt;msg_namelen as 0. recvmsg handlers must
set msg_namelen to the proper size &lt;= sizeof(struct sockaddr_storage)
to return msg_name to the user.

This prevents numerous uninitialized memory leaks we had in the
recvmsg handlers and makes it harder for new code to accidentally leak
uninitialized memory.

Optimize for the case recvfrom is called with NULL as address. We don't
need to copy the address at all, so set it to NULL before invoking the
recvmsg handler. We can do so, because all the recvmsg handlers must
cope with the case a plain read() is called on them. read() also sets
msg_name to NULL.

Also document these changes in include/linux/net.h as suggested by David
Miller.

Changes since RFC:

Set msg-&gt;msg_name = NULL if user specified a NULL in msg_name but had a
non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
affect sendto as it would bail out earlier while trying to copy-in the
address. It also more naturally reflects the logic by the callers of
verify_iovec.

With this change in place I could remove "
if (!uaddr || msg_sys-&gt;msg_namelen == 0)
	msg-&gt;msg_name = NULL
".

This change does not alter the user visible error logic as we ignore
msg_namelen as long as msg_name is NULL.

Also remove two unnecessary curly brackets in ___sys_recvmsg and change
comments to netdev style.

Cc: David Miller &lt;davem@davemloft.net&gt;
Suggested-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>inet: convert inet_ehash_secret and ipv6_hash_secret to net_get_random_once</title>
<updated>2013-10-19T23:45:35Z</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2013-10-19T19:48:57Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1bbdceef1e535add893bf71d7b7ab102e4eb69eb'/>
<id>urn:sha1:1bbdceef1e535add893bf71d7b7ab102e4eb69eb</id>
<content type='text'>
Initialize the ehash and ipv6_hash_secrets with net_get_random_once.

Each compilation unit gets its own secret now:
  ipv4/inet_hashtables.o
  ipv4/udp.o
  ipv6/inet6_hashtables.o
  ipv6/udp.o
  rds/connection.o

The functions still get inlined into the hashing functions. In the fast
path we have at most two (needed in ipv6) if (unlikely(...)).

Cc: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
