<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/net, branch v3.6.3</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.6.3</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.6.3'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2012-10-21T16:32:41+00:00</updated>
<entry>
<title>pktgen: fix crash when generating IPv6 packets</title>
<updated>2012-10-21T16:32:41+00:00</updated>
<author>
<name>Amerigo Wang</name>
<email>amwang@redhat.com</email>
</author>
<published>2012-10-09T17:48:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ac43c058283e037c5acdee95ada41075e0e2dde5'/>
<id>urn:sha1:ac43c058283e037c5acdee95ada41075e0e2dde5</id>
<content type='text'>
commit 5aa8b572007c4bca1e6d3dd4c4820f1ae49d6bb2 upstream.

For IPv6, sizeof(struct ipv6hdr) = 40, thus the following
expression will result negative:

        datalen = pkt_dev-&gt;cur_pkt_size - 14 -
                  sizeof(struct ipv6hdr) - sizeof(struct udphdr) -
                  pkt_dev-&gt;pkt_overhead;

And,  the check "if (datalen &lt; sizeof(struct pktgen_hdr))" will be
passed as "datalen" is promoted to unsigned, therefore will cause
a crash later.

This is a quick fix by checking if "datalen" is negative. The following
patch will increase the default value of 'min_pkt_size' for IPv6.

This bug should exist for a long time, so Cc -stable too.

Signed-off-by: Cong Wang &lt;amwang@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>mac80211: use ieee80211_free_txskb to fix possible skb leaks</title>
<updated>2012-10-21T16:32:41+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2012-10-08T12:39:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fd39be7ff6f81f2dc91ba6e5f87944abef5b4802'/>
<id>urn:sha1:fd39be7ff6f81f2dc91ba6e5f87944abef5b4802</id>
<content type='text'>
commit c3e7724b6bc2f25e46c38dbe68f09d71fafeafb8 upstream.

A few places free skbs using dev_kfree_skb even though they're called
after ieee80211_subif_start_xmit might have cloned it for tracking tx
status. Use ieee80211_free_txskb here to prevent skb leaks.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>SUNRPC: Ensure that the TCP socket is closed when in CLOSE_WAIT</title>
<updated>2012-10-21T16:32:40+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2012-09-12T20:49:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6324a752e0113df97f8a59902fcb22c38eede27f'/>
<id>urn:sha1:6324a752e0113df97f8a59902fcb22c38eede27f</id>
<content type='text'>
commit a519fc7a70d1a918574bb826cc6905b87b482eb9 upstream.

Instead of doing a shutdown() call, we need to do an actual close().
Ditto if/when the server is sending us junk RPC headers.

Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Tested-by: Simon Kirby &lt;sim@hostway.ca&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ipv6: del unreachable route when an addr is deleted on lo</title>
<updated>2012-10-12T20:50:22+00:00</updated>
<author>
<name>Nicolas Dichtel</name>
<email>nicolas.dichtel@6wind.com</email>
</author>
<published>2012-09-26T00:04:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=13d536a0bb25c10e183bc022a1b88dc097aad15d'/>
<id>urn:sha1:13d536a0bb25c10e183bc022a1b88dc097aad15d</id>
<content type='text'>
[ Upstream commit 64c6d08e6490fb18cea09bb03686c149946bd818 ]

When an address is added on loopback (ip -6 a a 2002::1/128 dev lo), two routes
are added:
 - one in the local table:
    local 2002::1 via :: dev lo  proto none  metric 0
 - one the in main table (for the prefix):
    unreachable 2002::1 dev lo  proto kernel  metric 256  error -101

When the address is deleted, the route inserted in the main table remains
because we use rt6_lookup(), which returns NULL when dst-&gt;error is set, which
is the case here! Thus, it is better to use ip6_route_lookup() to avoid this
kind of filter.

Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.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: release reference of ip6_null_entry's dst entry in __ip6_del_rt</title>
<updated>2012-10-12T20:50:21+00:00</updated>
<author>
<name>Gao feng</name>
<email>gaofeng@cn.fujitsu.com</email>
</author>
<published>2012-09-19T19:25:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0f1bf6e2dc225d9bfce3be0be0b2f22956bcb313'/>
<id>urn:sha1:0f1bf6e2dc225d9bfce3be0be0b2f22956bcb313</id>
<content type='text'>
[ Upstream commit 6825a26c2dc21eb4f8df9c06d3786ddec97cf53b ]

as we hold dst_entry before we call __ip6_del_rt,
so we should alse call dst_release not only return
-ENOENT when the rt6_info is ip6_null_entry.

and we already hold the dst entry, so I think it's
safe to call dst_release out of the write-read lock.

Signed-off-by: Gao feng &lt;gaofeng@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>8021q: fix mac_len recomputation in vlan_untag()</title>
<updated>2012-10-12T20:50:21+00:00</updated>
<author>
<name>Antonio Quartulli</name>
<email>ordex@autistici.org</email>
</author>
<published>2012-10-02T06:14:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=57d8849c5fa2aa2e0b91aa2f822c6a41b2d879d4'/>
<id>urn:sha1:57d8849c5fa2aa2e0b91aa2f822c6a41b2d879d4</id>
<content type='text'>
[ Upstream commit 5316cf9a5197eb80b2800e1acadde287924ca975 ]

skb_reset_mac_len() relies on the value of the skb-&gt;network_header pointer,
therefore we must wait for such pointer to be recalculated before computing
the new mac_len value.

Signed-off-by: Antonio Quartulli &lt;ordex@autistici.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>ipv4: add a fib_type to fib_info</title>
<updated>2012-10-12T20:50:21+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2012-10-04T01:25:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=52fc5048534e9d4127622fa5a269a92f3bb5218b'/>
<id>urn:sha1:52fc5048534e9d4127622fa5a269a92f3bb5218b</id>
<content type='text'>
[ Upstream commit f4ef85bbda96324785097356336bc79cdd37db0a ]

commit d2d68ba9fe8 (ipv4: Cache input routes in fib_info nexthops.)
introduced a regression for forwarding.

This was hard to reproduce but the symptom was that packets were
delivered to local host instead of being forwarded.

David suggested to add fib_type to fib_info so that we dont
inadvertently share same fib_info for different purposes.

With help from Julian Anastasov who provided very helpful
hints, reproduced here :

&lt;quote&gt;
        Can it be a problem related to fib_info reuse
from different routes. For example, when local IP address
is created for subnet we have:

broadcast 192.168.0.255 dev DEV  proto kernel  scope link  src
192.168.0.1
192.168.0.0/24 dev DEV  proto kernel  scope link  src 192.168.0.1
local 192.168.0.1 dev DEV  proto kernel  scope host  src 192.168.0.1

        The "dev DEV  proto kernel  scope link  src 192.168.0.1" is
a reused fib_info structure where we put cached routes.
The result can be same fib_info for 192.168.0.255 and
192.168.0.0/24. RTN_BROADCAST is cached only for input
routes. Incoming broadcast to 192.168.0.255 can be cached
and can cause problems for traffic forwarded to 192.168.0.0/24.
So, this patch should solve the problem because it
separates the broadcast from unicast traffic.

        And the ip_route_input_slow caching will work for
local and broadcast input routes (above routes 1 and 3) just
because they differ in scope and use different fib_info.

&lt;/quote&gt;

Many thanks to Chris Clayton for his patience and help.

Reported-by: Chris Clayton &lt;chris2553@googlemail.com&gt;
Bisected-by: Chris Clayton &lt;chris2553@googlemail.com&gt;
Reported-by: Dave Jones &lt;davej@redhat.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Julian Anastasov &lt;ja@ssi.bg&gt;
Tested-by: Chris Clayton &lt;chris2553@googlemail.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>inetpeer: fix token initialization</title>
<updated>2012-09-27T23:27:39+00:00</updated>
<author>
<name>Nicolas Dichtel</name>
<email>nicolas.dichtel@6wind.com</email>
</author>
<published>2012-09-27T04:11:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bc9259a8bae9e814fc1f775a1b3effa13e6ad330'/>
<id>urn:sha1:bc9259a8bae9e814fc1f775a1b3effa13e6ad330</id>
<content type='text'>
When jiffies wraps around (for example, 5 minutes after the boot, see
INITIAL_JIFFIES) and peer has just been created, now - peer-&gt;rate_last can be
&lt; XRLIM_BURST_FACTOR * timeout, so token is not set to the maximum value, thus
some icmp packets can be unexpectedly dropped.

Fix this case by initializing last_rate to 60 seconds in the past.

Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
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>l2tp: fix return value check</title>
<updated>2012-09-27T17:18:19+00:00</updated>
<author>
<name>Wei Yongjun</name>
<email>yongjun_wei@trendmicro.com.cn</email>
</author>
<published>2012-09-24T18:29:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7f8436a1269eaaf2d0b1054a325eddf4e14cb80d'/>
<id>urn:sha1:7f8436a1269eaaf2d0b1054a325eddf4e14cb80d</id>
<content type='text'>
In case of error, the function genlmsg_put() returns NULL pointer
not ERR_PTR(). The IS_ERR() test in the return value check should
be replaced with NULL test.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun &lt;yongjun_wei@trendmicro.com.cn&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://1984.lsi.us.es/nf</title>
<updated>2012-09-27T17:16:14+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2012-09-27T17:16:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=392b408782324e62709f080a84de2866f7b125d4'/>
<id>urn:sha1:392b408782324e62709f080a84de2866f7b125d4</id>
<content type='text'>
Pablo Neira Ayuso says:

====================
If time allows, I'd appreciate if you can take the following fix
for the xt_limit match.

As Jan indicates, random things may occur while using the xt_limit
match due to use of uninitialized memory.
====================

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