<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/net, branch v3.4.35</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/net?h=v3.4.35</id>
<link rel='self' href='https://git.amat.us/linux/atom/net?h=v3.4.35'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-03-03T22:06:43Z</updated>
<entry>
<title>svcrpc: make svc_age_temp_xprts enqueue under sv_lock</title>
<updated>2013-03-03T22:06:43Z</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2013-02-10T16:33:48Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7e5e167c5c1b44f408fa8f8a8f062f234cd0f0d6'/>
<id>urn:sha1:7e5e167c5c1b44f408fa8f8a8f062f234cd0f0d6</id>
<content type='text'>
commit e75bafbff2270993926abcc31358361db74a9bc2 upstream.

svc_age_temp_xprts expires xprts in a two-step process: first it takes
the sv_lock and moves the xprts to expire off their server-wide list
(sv_tempsocks or sv_permsocks) to a local list.  Then it drops the
sv_lock and enqueues and puts each one.

I see no reason for this: svc_xprt_enqueue() will take sp_lock, but the
sv_lock and sp_lock are not otherwise nested anywhere (and documentation
at the top of this file claims it's correct to nest these with sp_lock
inside.)

Tested-by: Jason Tibbitts &lt;tibbs@math.uh.edu&gt;
Tested-by: Paweł Sikora &lt;pawel.sikora@agmk.net&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>sock_diag: Fix out-of-bounds access to sock_diag_handlers[]</title>
<updated>2013-02-28T14:59:06Z</updated>
<author>
<name>Mathias Krause</name>
<email>minipli@googlemail.com</email>
</author>
<published>2013-02-23T01:13:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8c2223fc19032e7b8761e46c15e1ed167a252285'/>
<id>urn:sha1:8c2223fc19032e7b8761e46c15e1ed167a252285</id>
<content type='text'>
[ Upstream commit 6e601a53566d84e1ffd25e7b6fe0b6894ffd79c0 ]

Userland can send a netlink message requesting SOCK_DIAG_BY_FAMILY
with a family greater or equal then AF_MAX -- the array size of
sock_diag_handlers[]. The current code does not test for this
condition therefore is vulnerable to an out-of-bound access opening
doors for a privilege escalation.

Signed-off-by: Mathias Krause &lt;minipli@googlemail.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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ipv6: use a stronger hash for tcp</title>
<updated>2013-02-28T14:59:06Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2013-02-21T12:18:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e5a096aa0aeb1fc8ad8b3d6bd70d322a0d65edc4'/>
<id>urn:sha1:e5a096aa0aeb1fc8ad8b3d6bd70d322a0d65edc4</id>
<content type='text'>
[ Upstream commit 08dcdbf6a7b9d14c2302c5bd0c5390ddf122f664 ]

It looks like its possible to open thousands of TCP IPv6
sessions on a server, all landing in a single slot of TCP hash
table. Incoming packets have to lookup sockets in a very
long list.

We should hash all bits from foreign IPv6 addresses, using
a salt and hash mix, not a simple XOR.

inet6_ehashfn() can also separately use the ports, instead
of xoring them.

Reported-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Yuchung Cheng &lt;ycheng@google.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>ipv4: fix a bug in ping_err().</title>
<updated>2013-02-28T14:59:06Z</updated>
<author>
<name>Li Wei</name>
<email>lw@cn.fujitsu.com</email>
</author>
<published>2013-02-21T00:09:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=785e5dce256ea5bdf4871af13f9908b74264b515'/>
<id>urn:sha1:785e5dce256ea5bdf4871af13f9908b74264b515</id>
<content type='text'>
[ Upstream commit b531ed61a2a2a77eeb2f7c88b49aa5ec7d9880d8 ]

We should get 'type' and 'code' from the outer ICMP header.

Signed-off-by: Li Wei &lt;lw@cn.fujitsu.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>net: fix infinite loop in __skb_recv_datagram()</title>
<updated>2013-02-28T14:59:06Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2013-02-12T06:16:53Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b5428e471b91192a2438d04c1d2ff2b3d4708366'/>
<id>urn:sha1:b5428e471b91192a2438d04c1d2ff2b3d4708366</id>
<content type='text'>
[ Upstream commit 77c1090f94d1b0b5186fb13a1b71b47b1343f87f ]

Tommi was fuzzing with trinity and reported the following problem :

commit 3f518bf745 (datagram: Add offset argument to __skb_recv_datagram)
missed that a raw socket receive queue can contain skbs with no payload.

We can loop in __skb_recv_datagram() with MSG_PEEK mode, because
wait_for_packet() is not prepared to skip these skbs.

[   83.541011] INFO: rcu_sched detected stalls on CPUs/tasks: {}
(detected by 0, t=26002 jiffies, g=27673, c=27672, q=75)
[   83.541011] INFO: Stall ended before state dump start
[  108.067010] BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child31:2847]
...
[  108.067010] Call Trace:
[  108.067010]  [&lt;ffffffff818cc103&gt;] __skb_recv_datagram+0x1a3/0x3b0
[  108.067010]  [&lt;ffffffff818cc33d&gt;] skb_recv_datagram+0x2d/0x30
[  108.067010]  [&lt;ffffffff819ed43d&gt;] rawv6_recvmsg+0xad/0x240
[  108.067010]  [&lt;ffffffff818c4b04&gt;] sock_common_recvmsg+0x34/0x50
[  108.067010]  [&lt;ffffffff818bc8ec&gt;] sock_recvmsg+0xbc/0xf0
[  108.067010]  [&lt;ffffffff818bf31e&gt;] sys_recvfrom+0xde/0x150
[  108.067010]  [&lt;ffffffff81ca4329&gt;] system_call_fastpath+0x16/0x1b

Reported-by: Tommi Rantala &lt;tt.rantala@gmail.com&gt;
Tested-by: Tommi Rantala &lt;tt.rantala@gmail.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Pavel Emelyanov &lt;xemul@parallels.com&gt;
Acked-by: Pavel Emelyanov &lt;xemul@parallels.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>bridge: set priority of STP packets</title>
<updated>2013-02-28T14:59:05Z</updated>
<author>
<name>Stephen Hemminger</name>
<email>stephen@networkplumber.org</email>
</author>
<published>2013-02-11T08:22:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6e95f970d1cb6801b5f26d2c167fb1e0ad6c5dba'/>
<id>urn:sha1:6e95f970d1cb6801b5f26d2c167fb1e0ad6c5dba</id>
<content type='text'>
[ Upstream commit 547b4e718115eea74087e28d7fa70aec619200db ]

Spanning Tree Protocol packets should have always been marked as
control packets, this causes them to get queued in the high prirority
FIFO. As Radia Perlman mentioned in her LCA talk, STP dies if bridge
gets overloaded and can't communicate. This is a long-standing bug back
to the first versions of Linux bridge.

Signed-off-by: Stephen Hemminger &lt;stephen@networkplumber.org&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>bridge: Pull ip header into skb-&gt;data before looking into ip header.</title>
<updated>2013-02-14T18:49:07Z</updated>
<author>
<name>Sarveshwar Bandi</name>
<email>sarveshwar.bandi@emulex.com</email>
</author>
<published>2012-10-10T01:15:01Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=94fab0a18e9cbec420c58c7b12b93acf1663c3fd'/>
<id>urn:sha1:94fab0a18e9cbec420c58c7b12b93acf1663c3fd</id>
<content type='text'>
[ Upstream commit 6caab7b0544e83e6c160b5e80f5a4a7dd69545c7 ]

If lower layer driver leaves the ip header in the skb fragment, it needs to
be first pulled into skb-&gt;data before inspecting ip header length or ip version
number.

Signed-off-by: Sarveshwar Bandi &lt;sarveshwar.bandi@emulex.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>tcp: fix for zero packets_in_flight was too broad</title>
<updated>2013-02-14T18:49:06Z</updated>
<author>
<name>Ilpo Järvinen</name>
<email>ilpo.jarvinen@helsinki.fi</email>
</author>
<published>2013-02-04T02:14:25Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f641de91169472dc398fbd971cef380ad8d0f787'/>
<id>urn:sha1:f641de91169472dc398fbd971cef380ad8d0f787</id>
<content type='text'>
[ Upstream commit 6731d2095bd4aef18027c72ef845ab1087c3ba63 ]

There are transients during normal FRTO procedure during which
the packets_in_flight can go to zero between write_queue state
updates and firing the resulting segments out. As FRTO processing
occurs during that window the check must be more precise to
not match "spuriously" :-). More specificly, e.g., when
packets_in_flight is zero but FLAG_DATA_ACKED is true the problematic
branch that set cwnd into zero would not be taken and new segments
might be sent out later.

Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@helsinki.fi&gt;
Tested-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Neal Cardwell &lt;ncardwell@google.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>tcp: frto should not set snd_cwnd to 0</title>
<updated>2013-02-14T18:49:06Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2013-02-03T09:13:05Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2813296332187d222b96363fe29f10929f7a5228'/>
<id>urn:sha1:2813296332187d222b96363fe29f10929f7a5228</id>
<content type='text'>
[ Upstream commit 2e5f421211ff76c17130b4597bc06df4eeead24f ]

Commit 9dc274151a548 (tcp: fix ABC in tcp_slow_start())
uncovered a bug in FRTO code :
tcp_process_frto() is setting snd_cwnd to 0 if the number
of in flight packets is 0.

As Neal pointed out, if no packet is in flight we lost our
chance to disambiguate whether a loss timeout was spurious.

We should assume it was a proper loss.

Reported-by: Pasi Kärkkäinen &lt;pasik@iki.fi&gt;
Signed-off-by: Neal Cardwell &lt;ncardwell@google.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;
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>net: sctp: sctp_endpoint_free: zero out secret key data</title>
<updated>2013-02-14T18:49:06Z</updated>
<author>
<name>Daniel Borkmann</name>
<email>dborkman@redhat.com</email>
</author>
<published>2013-02-08T03:04:35Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d6f5498856f31246818bbe4ebfa710ce92730a37'/>
<id>urn:sha1:d6f5498856f31246818bbe4ebfa710ce92730a37</id>
<content type='text'>
[ Upstream commit b5c37fe6e24eec194bb29d22fdd55d73bcc709bf ]

On sctp_endpoint_destroy, previously used sensitive keying material
should be zeroed out before the memory is returned, as we already do
with e.g. auth keys when released.

Signed-off-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Acked-by: Vlad Yasevich &lt;vyasevic@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>
</feed>
