<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/net, branch v3.4.4</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/net?h=v3.4.4</id>
<link rel='self' href='https://git.amat.us/linux/atom/net?h=v3.4.4'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-06-22T18:37:15Z</updated>
<entry>
<title>9p: BUG before corrupting memory</title>
<updated>2012-06-22T18:37:15Z</updated>
<author>
<name>Sasha Levin</name>
<email>levinsasha928@gmail.com</email>
</author>
<published>2012-06-11T15:18:13Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=eef458cb6f020f165de00a5e284048be49e9ee27'/>
<id>urn:sha1:eef458cb6f020f165de00a5e284048be49e9ee27</id>
<content type='text'>
commit 5fcb08befaf57faa1b00e514915c1660252b8c26 upstream.

The BUG_ON() in pack_sg_list() would get triggered only one time after we've
corrupted some memory by sg_set_buf() into an invalid sg buffer.

I'm still working on figuring out why I manage to trigger that bug...

Signed-off-by: Sasha Levin &lt;levinsasha928@gmail.com&gt;
Signed-off-by: Eric Van Hensbergen &lt;ericvh@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>rpc_pipefs: allow rpc_purge_list to take a NULL waitq pointer</title>
<updated>2012-06-22T18:36:55Z</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@redhat.com</email>
</author>
<published>2012-06-11T14:03:42Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b7013d0a16b881481dc25ba4d42c5203bebe5ff1'/>
<id>urn:sha1:b7013d0a16b881481dc25ba4d42c5203bebe5ff1</id>
<content type='text'>
commit 92123e068efa310b09e9943ac1cfd10ff6b6d2e4 upstream.

In the event that we don't have a dentry for a rpc_pipefs pipe, we still
need to allow the queue_timeout job to clean out the queue. There's just
no waitq to wake up in that event.

Reported-by: Hans de Bruin &lt;jmdebruin@xmsnet.nl&gt;
Reported-by: Joerg Platte &lt;jplatte@naasa.net&gt;
Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>NFSv4.1: Fix a request leak on the back channel</title>
<updated>2012-06-22T18:36:54Z</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2012-05-31T19:26:38Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5f1d81e9fb6c05e8ab89a610bb63cdc8f0f66d81'/>
<id>urn:sha1:5f1d81e9fb6c05e8ab89a610bb63cdc8f0f66d81</id>
<content type='text'>
commit b3b02ae5865c2dcd506322e0fc6def59a042e72f upstream.

If the call to svc_process_common() fails, then the request
needs to be freed before we can exit bc_svc_process.

Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cfg80211: fix interface combinations check</title>
<updated>2012-06-17T18:21:26Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2012-06-05T10:16:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6fa9c3400dd4cbf30c597dbde5d6abbc12b9764d'/>
<id>urn:sha1:6fa9c3400dd4cbf30c597dbde5d6abbc12b9764d</id>
<content type='text'>
commit 463454b5dbd8dbab6e2fc6c557329e5b811b9c32 upstream.

If a given interface combination doesn't contain
a required interface type then we missed checking
that and erroneously allowed it even though iface
type wasn't there at all. Add a check that makes
sure that all interface types are accounted for.

Reported-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&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>mac80211: fix non RCU-safe sta_list manipulation</title>
<updated>2012-06-17T18:21:25Z</updated>
<author>
<name>Arik Nemtsov</name>
<email>arik@wizery.com</email>
</author>
<published>2012-06-03T20:32:32Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=073e100877a39f36163398cde868e98fa6d3f0a1'/>
<id>urn:sha1:073e100877a39f36163398cde868e98fa6d3f0a1</id>
<content type='text'>
commit 794454ce72a298de6f4536ade597bdcc7dcde7c7 upstream.

sta_info_cleanup locks the sta_list using rcu_read_lock however
the delete operation isn't rcu safe. A race between sta_info_cleanup
timer being called and a STA being removed can occur which leads
to a panic while traversing sta_list. Fix this by switching to the
RCU-safe versions.

Reported-by: Eyal Shapira &lt;eyal@wizery.com&gt;
Signed-off-by: Arik Nemtsov &lt;arik@wizery.com&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>mac80211: clean up remain-on-channel on interface stop</title>
<updated>2012-06-17T18:21:25Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2012-05-31T13:09:27Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d4bb7f49f4d5ea7a287899178df55b4725bb32d2'/>
<id>urn:sha1:d4bb7f49f4d5ea7a287899178df55b4725bb32d2</id>
<content type='text'>
commit 71ecfa1893034eeb1c93e02e22ee2ad26d080858 upstream.

When any interface goes down, it could be the one that we
were doing a remain-on-channel with. We therefore need to
cancel the remain-on-channel and flush the related work
structs so they don't run after the interface has been
removed or even destroyed.

It's also possible in this case that an off-channel SKB
was never transmitted, so free it if this is the case.
Note that this can also happen if the driver finishes
the off-channel period without ever starting it.

Reported-by: Nirav Shah &lt;nirav.j2.shah@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&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>mac80211: fix error in station state transitions during reconfig</title>
<updated>2012-06-17T18:21:25Z</updated>
<author>
<name>Meenakshi Venkataraman</name>
<email>meenakshi.venkataraman@intel.com</email>
</author>
<published>2012-05-30T09:39:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=721632c39add11e5d5fa5dd8b956dcae63d02b17'/>
<id>urn:sha1:721632c39add11e5d5fa5dd8b956dcae63d02b17</id>
<content type='text'>
commit bd34ab62a3297bd7685da11b0cbe05ae4cd8b02c upstream.

As part of hardware reconfig mac80211 tries
to restore the station state to its values
before the hardware reconfig, but it only
goes to the last-state - 1. Fix this
off-by-one error.

Signed-off-by: Meenakshi Venkataraman &lt;meenakshi.venkataraman@intel.com&gt;
Reviewed-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&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>xfrm: take net hdr len into account for esp payload size calculation</title>
<updated>2012-06-09T15:36:15Z</updated>
<author>
<name>Benjamin Poirier</name>
<email>bpoirier@suse.de</email>
</author>
<published>2012-05-24T11:32:38Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=978041f2a946a4616f7cdb60f6d453ffa83298c1'/>
<id>urn:sha1:978041f2a946a4616f7cdb60f6d453ffa83298c1</id>
<content type='text'>
[ Upstream commit 91657eafb64b4cb53ec3a2fbc4afc3497f735788 ]

Corrects the function that determines the esp payload size. The calculations
done in esp{4,6}_get_mtu() lead to overlength frames in transport mode for
certain mtu values and suboptimal frames for others.

According to what is done, mainly in esp{,6}_output() and tcp_mtu_to_mss(),
net_header_len must be taken into account before doing the alignment
calculation.

Signed-off-by: Benjamin Poirier &lt;bpoirier@suse.de&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>l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case</title>
<updated>2012-06-09T15:36:15Z</updated>
<author>
<name>James Chapman</name>
<email>jchapman@katalix.com</email>
</author>
<published>2012-05-29T23:13:23Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ea1ae37f4a2c41ea684f2e725332147eb6496026'/>
<id>urn:sha1:ea1ae37f4a2c41ea684f2e725332147eb6496026</id>
<content type='text'>
[ Upstream commit c51ce49735c183ef2592db70f918ee698716276b ]

An application may call connect() to disconnect a socket using an
address with family AF_UNSPEC. The L2TP IP sockets were not handling
this case when the socket is not bound and an attempt to connect()
using AF_UNSPEC in such cases would result in an oops. This patch
addresses the problem by protecting the sk_prot-&gt;disconnect() call
against trying to unhash the socket before it is bound.

The patch also adds more checks that the sockaddr supplied to bind()
and connect() calls is valid.

 RIP: 0010:[&lt;ffffffff82e133b0&gt;]  [&lt;ffffffff82e133b0&gt;] inet_unhash+0x50/0xd0
 RSP: 0018:ffff88001989be28  EFLAGS: 00010293
 Stack:
  ffff8800407a8000 0000000000000000 ffff88001989be78 ffffffff82e3a249
  ffffffff82e3a050 ffff88001989bec8 ffff88001989be88 ffff8800407a8000
  0000000000000010 ffff88001989bec8 ffff88001989bea8 ffffffff82e42639
 Call Trace:
 [&lt;ffffffff82e3a249&gt;] udp_disconnect+0x1f9/0x290
 [&lt;ffffffff82e42639&gt;] inet_dgram_connect+0x29/0x80
 [&lt;ffffffff82d012fc&gt;] sys_connect+0x9c/0x100

Reported-by: Sasha Levin &lt;levinsasha928@gmail.com&gt;
Signed-off-by: James Chapman &lt;jchapman@katalix.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: fix incorrect ipsec fragment</title>
<updated>2012-06-09T15:36:15Z</updated>
<author>
<name>Gao feng</name>
<email>gaofeng@cn.fujitsu.com</email>
</author>
<published>2012-05-26T01:30:53Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=be078c8003469b75aa9119254c163b2961321744'/>
<id>urn:sha1:be078c8003469b75aa9119254c163b2961321744</id>
<content type='text'>
[ Upstream commit 0c1833797a5a6ec23ea9261d979aa18078720b74 ]

Since commit ad0081e43a
"ipv6: Fragment locally generated tunnel-mode IPSec6 packets as needed"
the fragment of packets is incorrect.
because tunnel mode needs IPsec headers and trailer for all fragments,
while on transport mode it is sufficient to add the headers to the
first fragment and the trailer to the last.

so modify mtu and maxfraglen base on ipsec mode and if fragment is first
or last.

with my test,it work well(every fragment's size is the mtu)
and does not trigger slow fragment path.

Changes from v1:
	though optimization, mtu_prev and maxfraglen_prev can be delete.
	replace xfrm mode codes with dst_entry's new frag DST_XFRM_TUNNEL.
	add fuction ip6_append_data_mtu to make codes clearer.

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>
</feed>
