<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/net, branch v3.18.4</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>cfg80211: Fix 160 MHz channels with 80+80 and 160 MHz drivers</title>
<updated>2015-01-27T16:29:36+00:00</updated>
<author>
<name>Jouni Malinen</name>
<email>jouni@qca.qualcomm.com</email>
</author>
<published>2014-12-11T21:48:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=fff824488bc9831fd9eadf4b748f43416d13cdeb'/>
<id>fff824488bc9831fd9eadf4b748f43416d13cdeb</id>
<content type='text'>
commit 08f6f147773b23b765b94633a8eaa82e7defcf4c upstream.

The VHT supported channel width field is a two bit integer, not a
bitfield. cfg80211_chandef_usable() was interpreting it incorrectly and
ended up rejecting 160 MHz channel width if the driver indicated support
for both 160 and 80+80 MHz channels.

Fixes: 3d9d1d6656a73 ("nl80211/cfg80211: support VHT channel configuration")
       (however, no real drivers had 160 MHz support it until 3.16)
Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 08f6f147773b23b765b94633a8eaa82e7defcf4c upstream.

The VHT supported channel width field is a two bit integer, not a
bitfield. cfg80211_chandef_usable() was interpreting it incorrectly and
ended up rejecting 160 MHz channel width if the driver indicated support
for both 160 and 80+80 MHz channels.

Fixes: 3d9d1d6656a73 ("nl80211/cfg80211: support VHT channel configuration")
       (however, no real drivers had 160 MHz support it until 3.16)
Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: avoid mem leak on driver hint set</title>
<updated>2015-01-27T16:29:36+00:00</updated>
<author>
<name>Arik Nemtsov</name>
<email>arik@wizery.com</email>
</author>
<published>2014-12-04T10:22:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=a7b2c7ffae7c8a48a2064adfea0eecfadc042b08'/>
<id>a7b2c7ffae7c8a48a2064adfea0eecfadc042b08</id>
<content type='text'>
commit 34f05f543f02350e920bddb7660ffdd4697aaf60 upstream.

In the already-set and intersect case of a driver-hint, the previous
wiphy regdomain was not freed before being reset with a copy of the
cfg80211 regdomain.

Signed-off-by: Arik Nemtsov &lt;arikx.nemtsov@intel.com&gt;
Acked-by: Luis R. Rodriguez &lt;mcgrof@suse.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 34f05f543f02350e920bddb7660ffdd4697aaf60 upstream.

In the already-set and intersect case of a driver-hint, the previous
wiphy regdomain was not freed before being reset with a copy of the
cfg80211 regdomain.

Signed-off-by: Arik Nemtsov &lt;arikx.nemtsov@intel.com&gt;
Acked-by: Luis R. Rodriguez &lt;mcgrof@suse.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: don't WARN about two consecutive Country IE hint</title>
<updated>2015-01-27T16:29:36+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2014-12-02T07:53:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=0a57c26d6410712a5b4ed42d961284d2204b4a7c'/>
<id>0a57c26d6410712a5b4ed42d961284d2204b4a7c</id>
<content type='text'>
commit 70dcec5a488a7b81779190ac8089475fe4b8b962 upstream.

This can happen and there is no point in added more
detection code lower in the stack. Catching these in one
single point (cfg80211) is enough. Stop WARNING about this
case.

This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=89001

Fixes: 2f1c6c572d7b ("cfg80211: process non country IE conflicting first")
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 70dcec5a488a7b81779190ac8089475fe4b8b962 upstream.

This can happen and there is no point in added more
detection code lower in the stack. Catching these in one
single point (cfg80211) is enough. Stop WARNING about this
case.

This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=89001

Fixes: 2f1c6c572d7b ("cfg80211: process non country IE conflicting first")
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>nl80211: check matches array length before acessing it</title>
<updated>2015-01-27T16:29:36+00:00</updated>
<author>
<name>Luciano Coelho</name>
<email>luciano.coelho@intel.com</email>
</author>
<published>2014-12-01T09:32:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=65a39b355999b72e9cd325de29870a39cc3c3686'/>
<id>65a39b355999b72e9cd325de29870a39cc3c3686</id>
<content type='text'>
commit f89f46cf3a23d8d7c98f924a461fd931e1331746 upstream.

If the userspace passes a malformed sched scan request (or a net
detect wowlan configuration) by adding a NL80211_ATTR_SCHED_SCAN_MATCH
attribute without any nested matchsets, a NULL pointer dereference
will occur.  Fix this by checking that we do have matchsets in our
array before trying to access it.

BUG: unable to handle kernel NULL pointer dereference at 0000000000000024
IP: [&lt;ffffffffa002fd69&gt;] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211]
PGD 865c067 PUD 865b067 PMD 0
Oops: 0002 [#1] SMP
Modules linked in: iwlmvm(O) iwlwifi(O) mac80211(O) cfg80211(O) compat(O) [last unloaded: compat]
CPU: 2 PID: 2442 Comm: iw Tainted: G           O   3.17.2 #31
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task: ffff880013800790 ti: ffff880008d80000 task.ti: ffff880008d80000
RIP: 0010:[&lt;ffffffffa002fd69&gt;]  [&lt;ffffffffa002fd69&gt;] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211]
RSP: 0018:ffff880008d838d0  EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 000000000000143c RSI: 0000000000000000 RDI: ffff880008ee8dd0
RBP: ffff880008d83948 R08: 0000000000000002 R09: 0000000000000019
R10: ffff88001d1b3c40 R11: 0000000000000002 R12: ffff880019e85e00
R13: 00000000fffffed4 R14: ffff880009757800 R15: 0000000000001388
FS:  00007fa3b6d13700(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000024 CR3: 0000000008670000 CR4: 00000000000006e0
Stack:
 ffff880009757800 ffff880000000001 0000000000000000 ffff880008ee84e0
 0000000000000000 ffff880009757800 00000000fffffed4 ffff880008d83948
 ffffffff814689c9 ffff880009757800 ffff880008ee8000 0000000000000000
Call Trace:
 [&lt;ffffffff814689c9&gt;] ? nla_parse+0xb9/0x120
 [&lt;ffffffffa00306de&gt;] nl80211_set_wowlan+0x75e/0x960 [cfg80211]
 [&lt;ffffffff810bf3d5&gt;] ? mark_held_locks+0x75/0xa0
 [&lt;ffffffff8161a77b&gt;] genl_family_rcv_msg+0x18b/0x360
 [&lt;ffffffff810bf66d&gt;] ? trace_hardirqs_on+0xd/0x10
 [&lt;ffffffff8161a9d4&gt;] genl_rcv_msg+0x84/0xc0
 [&lt;ffffffff8161a950&gt;] ? genl_family_rcv_msg+0x360/0x360
 [&lt;ffffffff81618e79&gt;] netlink_rcv_skb+0xa9/0xd0
 [&lt;ffffffff81619458&gt;] genl_rcv+0x28/0x40
 [&lt;ffffffff816184a5&gt;] netlink_unicast+0x105/0x180
 [&lt;ffffffff8161886f&gt;] netlink_sendmsg+0x34f/0x7a0
 [&lt;ffffffff8105a097&gt;] ? kvm_clock_read+0x27/0x40
 [&lt;ffffffff815c644d&gt;] sock_sendmsg+0x8d/0xc0
 [&lt;ffffffff811a75c9&gt;] ? might_fault+0xb9/0xc0
 [&lt;ffffffff811a756e&gt;] ? might_fault+0x5e/0xc0
 [&lt;ffffffff815d5d26&gt;] ? verify_iovec+0x56/0xe0
 [&lt;ffffffff815c73e0&gt;] ___sys_sendmsg+0x3d0/0x3e0
 [&lt;ffffffff810a7be8&gt;] ? sched_clock_cpu+0x98/0xd0
 [&lt;ffffffff810611b4&gt;] ? __do_page_fault+0x254/0x580
 [&lt;ffffffff810bb39f&gt;] ? up_read+0x1f/0x40
 [&lt;ffffffff810611b4&gt;] ? __do_page_fault+0x254/0x580
 [&lt;ffffffff812146ed&gt;] ? __fget_light+0x13d/0x160
 [&lt;ffffffff815c7b02&gt;] __sys_sendmsg+0x42/0x80
 [&lt;ffffffff815c7b52&gt;] SyS_sendmsg+0x12/0x20
 [&lt;ffffffff81751f69&gt;] system_call_fastpath+0x16/0x1b

Fixes: ea73cbce4e1f ("nl80211: fix scheduled scan RSSI matchset attribute confusion")
Signed-off-by: Luciano Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f89f46cf3a23d8d7c98f924a461fd931e1331746 upstream.

If the userspace passes a malformed sched scan request (or a net
detect wowlan configuration) by adding a NL80211_ATTR_SCHED_SCAN_MATCH
attribute without any nested matchsets, a NULL pointer dereference
will occur.  Fix this by checking that we do have matchsets in our
array before trying to access it.

BUG: unable to handle kernel NULL pointer dereference at 0000000000000024
IP: [&lt;ffffffffa002fd69&gt;] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211]
PGD 865c067 PUD 865b067 PMD 0
Oops: 0002 [#1] SMP
Modules linked in: iwlmvm(O) iwlwifi(O) mac80211(O) cfg80211(O) compat(O) [last unloaded: compat]
CPU: 2 PID: 2442 Comm: iw Tainted: G           O   3.17.2 #31
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task: ffff880013800790 ti: ffff880008d80000 task.ti: ffff880008d80000
RIP: 0010:[&lt;ffffffffa002fd69&gt;]  [&lt;ffffffffa002fd69&gt;] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211]
RSP: 0018:ffff880008d838d0  EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 000000000000143c RSI: 0000000000000000 RDI: ffff880008ee8dd0
RBP: ffff880008d83948 R08: 0000000000000002 R09: 0000000000000019
R10: ffff88001d1b3c40 R11: 0000000000000002 R12: ffff880019e85e00
R13: 00000000fffffed4 R14: ffff880009757800 R15: 0000000000001388
FS:  00007fa3b6d13700(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000024 CR3: 0000000008670000 CR4: 00000000000006e0
Stack:
 ffff880009757800 ffff880000000001 0000000000000000 ffff880008ee84e0
 0000000000000000 ffff880009757800 00000000fffffed4 ffff880008d83948
 ffffffff814689c9 ffff880009757800 ffff880008ee8000 0000000000000000
Call Trace:
 [&lt;ffffffff814689c9&gt;] ? nla_parse+0xb9/0x120
 [&lt;ffffffffa00306de&gt;] nl80211_set_wowlan+0x75e/0x960 [cfg80211]
 [&lt;ffffffff810bf3d5&gt;] ? mark_held_locks+0x75/0xa0
 [&lt;ffffffff8161a77b&gt;] genl_family_rcv_msg+0x18b/0x360
 [&lt;ffffffff810bf66d&gt;] ? trace_hardirqs_on+0xd/0x10
 [&lt;ffffffff8161a9d4&gt;] genl_rcv_msg+0x84/0xc0
 [&lt;ffffffff8161a950&gt;] ? genl_family_rcv_msg+0x360/0x360
 [&lt;ffffffff81618e79&gt;] netlink_rcv_skb+0xa9/0xd0
 [&lt;ffffffff81619458&gt;] genl_rcv+0x28/0x40
 [&lt;ffffffff816184a5&gt;] netlink_unicast+0x105/0x180
 [&lt;ffffffff8161886f&gt;] netlink_sendmsg+0x34f/0x7a0
 [&lt;ffffffff8105a097&gt;] ? kvm_clock_read+0x27/0x40
 [&lt;ffffffff815c644d&gt;] sock_sendmsg+0x8d/0xc0
 [&lt;ffffffff811a75c9&gt;] ? might_fault+0xb9/0xc0
 [&lt;ffffffff811a756e&gt;] ? might_fault+0x5e/0xc0
 [&lt;ffffffff815d5d26&gt;] ? verify_iovec+0x56/0xe0
 [&lt;ffffffff815c73e0&gt;] ___sys_sendmsg+0x3d0/0x3e0
 [&lt;ffffffff810a7be8&gt;] ? sched_clock_cpu+0x98/0xd0
 [&lt;ffffffff810611b4&gt;] ? __do_page_fault+0x254/0x580
 [&lt;ffffffff810bb39f&gt;] ? up_read+0x1f/0x40
 [&lt;ffffffff810611b4&gt;] ? __do_page_fault+0x254/0x580
 [&lt;ffffffff812146ed&gt;] ? __fget_light+0x13d/0x160
 [&lt;ffffffff815c7b02&gt;] __sys_sendmsg+0x42/0x80
 [&lt;ffffffff815c7b52&gt;] SyS_sendmsg+0x12/0x20
 [&lt;ffffffff81751f69&gt;] system_call_fastpath+0x16/0x1b

Fixes: ea73cbce4e1f ("nl80211: fix scheduled scan RSSI matchset attribute confusion")
Signed-off-by: Luciano Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>tcp: Do not apply TSO segment limit to non-TSO packets</title>
<updated>2015-01-27T16:29:33+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2014-12-31T13:39:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=04e5427dbe91e600cf5c03e7e97095ce3865af92'/>
<id>04e5427dbe91e600cf5c03e7e97095ce3865af92</id>
<content type='text'>
[ Upstream commit 843925f33fcc293d80acf2c5c8a78adf3344d49b ]

Thomas Jarosch reported IPsec TCP stalls when a PMTU event occurs.

In fact the problem was completely unrelated to IPsec.  The bug is
also reproducible if you just disable TSO/GSO.

The problem is that when the MSS goes down, existing queued packet
on the TX queue that have not been transmitted yet all look like
TSO packets and get treated as such.

This then triggers a bug where tcp_mss_split_point tells us to
generate a zero-sized packet on the TX queue.  Once that happens
we're screwed because the zero-sized packet can never be removed
by ACKs.

Fixes: 1485348d242 ("tcp: Apply device TSO segment limit earlier")
Reported-by: Thomas Jarosch &lt;thomas.jarosch@intra2net.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;

Cheers,
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 843925f33fcc293d80acf2c5c8a78adf3344d49b ]

Thomas Jarosch reported IPsec TCP stalls when a PMTU event occurs.

In fact the problem was completely unrelated to IPsec.  The bug is
also reproducible if you just disable TSO/GSO.

The problem is that when the MSS goes down, existing queued packet
on the TX queue that have not been transmitted yet all look like
TSO packets and get treated as such.

This then triggers a bug where tcp_mss_split_point tells us to
generate a zero-sized packet on the TX queue.  Once that happens
we're screwed because the zero-sized packet can never be removed
by ACKs.

Fixes: 1485348d242 ("tcp: Apply device TSO segment limit earlier")
Reported-by: Thomas Jarosch &lt;thomas.jarosch@intra2net.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;

Cheers,
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: Generalize ndo_gso_check to ndo_features_check</title>
<updated>2015-01-27T16:29:33+00:00</updated>
<author>
<name>Jesse Gross</name>
<email>jesse@nicira.com</email>
</author>
<published>2014-12-24T06:37:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=12d5e0bb53dab45bcebeb7fc0dafc88d2b618468'/>
<id>12d5e0bb53dab45bcebeb7fc0dafc88d2b618468</id>
<content type='text'>
[ Upstream commit 5f35227ea34bb616c436d9da47fc325866c428f3 ]

GSO isn't the only offload feature with restrictions that
potentially can't be expressed with the current features mechanism.
Checksum is another although it's a general issue that could in
theory apply to anything. Even if it may be possible to
implement these restrictions in other ways, it can result in
duplicate code or inefficient per-packet behavior.

This generalizes ndo_gso_check so that drivers can remove any
features that don't make sense for a given packet, similar to
netif_skb_features(). It also converts existing driver
restrictions to the new format, completing the work that was
done to support tunnel protocols since the issues apply to
checksums as well.

By actually removing features from the set that are used to do
offloading, it solves another problem with the existing
interface. In these cases, GSO would run with the original set
of features and not do anything because it appears that
segmentation is not required.

CC: Tom Herbert &lt;therbert@google.com&gt;
CC: Joe Stringer &lt;joestringer@nicira.com&gt;
CC: Eric Dumazet &lt;edumazet@google.com&gt;
CC: Hayes Wang &lt;hayeswang@realtek.com&gt;
Signed-off-by: Jesse Gross &lt;jesse@nicira.com&gt;
Acked-by:  Tom Herbert &lt;therbert@google.com&gt;
Fixes: 04ffcb255f22 ("net: Add ndo_gso_check")
Tested-by: Hayes Wang &lt;hayeswang@realtek.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 5f35227ea34bb616c436d9da47fc325866c428f3 ]

GSO isn't the only offload feature with restrictions that
potentially can't be expressed with the current features mechanism.
Checksum is another although it's a general issue that could in
theory apply to anything. Even if it may be possible to
implement these restrictions in other ways, it can result in
duplicate code or inefficient per-packet behavior.

This generalizes ndo_gso_check so that drivers can remove any
features that don't make sense for a given packet, similar to
netif_skb_features(). It also converts existing driver
restrictions to the new format, completing the work that was
done to support tunnel protocols since the issues apply to
checksums as well.

By actually removing features from the set that are used to do
offloading, it solves another problem with the existing
interface. In these cases, GSO would run with the original set
of features and not do anything because it appears that
segmentation is not required.

CC: Tom Herbert &lt;therbert@google.com&gt;
CC: Joe Stringer &lt;joestringer@nicira.com&gt;
CC: Eric Dumazet &lt;edumazet@google.com&gt;
CC: Hayes Wang &lt;hayeswang@realtek.com&gt;
Signed-off-by: Jesse Gross &lt;jesse@nicira.com&gt;
Acked-by:  Tom Herbert &lt;therbert@google.com&gt;
Fixes: 04ffcb255f22 ("net: Add ndo_gso_check")
Tested-by: Hayes Wang &lt;hayeswang@realtek.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net/core: Handle csum for CHECKSUM_COMPLETE VXLAN forwarding</title>
<updated>2015-01-27T16:29:33+00:00</updated>
<author>
<name>Jay Vosburgh</name>
<email>jay.vosburgh@canonical.com</email>
</author>
<published>2014-12-19T23:32:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=3890e4287ea8ce14a68a82054c9df2cd92e3eafa'/>
<id>3890e4287ea8ce14a68a82054c9df2cd92e3eafa</id>
<content type='text'>
[ Upstream commit 2c26d34bbcc0b3f30385d5587aa232289e2eed8e ]

When using VXLAN tunnels and a sky2 device, I have experienced
checksum failures of the following type:

[ 4297.761899] eth0: hw csum failure
[...]
[ 4297.765223] Call Trace:
[ 4297.765224]  &lt;IRQ&gt;  [&lt;ffffffff8172f026&gt;] dump_stack+0x46/0x58
[ 4297.765235]  [&lt;ffffffff8162ba52&gt;] netdev_rx_csum_fault+0x42/0x50
[ 4297.765238]  [&lt;ffffffff8161c1a0&gt;] ? skb_push+0x40/0x40
[ 4297.765240]  [&lt;ffffffff8162325c&gt;] __skb_checksum_complete+0xbc/0xd0
[ 4297.765243]  [&lt;ffffffff8168c602&gt;] tcp_v4_rcv+0x2e2/0x950
[ 4297.765246]  [&lt;ffffffff81666ca0&gt;] ? ip_rcv_finish+0x360/0x360

	These are reliably reproduced in a network topology of:

container:eth0 == host(OVS VXLAN on VLAN) == bond0 == eth0 (sky2) -&gt; switch

	When VXLAN encapsulated traffic is received from a similarly
configured peer, the above warning is generated in the receive
processing of the encapsulated packet.  Note that the warning is
associated with the container eth0.

        The skbs from sky2 have ip_summed set to CHECKSUM_COMPLETE, and
because the packet is an encapsulated Ethernet frame, the checksum
generated by the hardware includes the inner protocol and Ethernet
headers.

	The receive code is careful to update the skb-&gt;csum, except in
__dev_forward_skb, as called by dev_forward_skb.  __dev_forward_skb
calls eth_type_trans, which in turn calls skb_pull_inline(skb, ETH_HLEN)
to skip over the Ethernet header, but does not update skb-&gt;csum when
doing so.

	This patch resolves the problem by adding a call to
skb_postpull_rcsum to update the skb-&gt;csum after the call to
eth_type_trans.

Signed-off-by: Jay Vosburgh &lt;jay.vosburgh@canonical.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 2c26d34bbcc0b3f30385d5587aa232289e2eed8e ]

When using VXLAN tunnels and a sky2 device, I have experienced
checksum failures of the following type:

[ 4297.761899] eth0: hw csum failure
[...]
[ 4297.765223] Call Trace:
[ 4297.765224]  &lt;IRQ&gt;  [&lt;ffffffff8172f026&gt;] dump_stack+0x46/0x58
[ 4297.765235]  [&lt;ffffffff8162ba52&gt;] netdev_rx_csum_fault+0x42/0x50
[ 4297.765238]  [&lt;ffffffff8161c1a0&gt;] ? skb_push+0x40/0x40
[ 4297.765240]  [&lt;ffffffff8162325c&gt;] __skb_checksum_complete+0xbc/0xd0
[ 4297.765243]  [&lt;ffffffff8168c602&gt;] tcp_v4_rcv+0x2e2/0x950
[ 4297.765246]  [&lt;ffffffff81666ca0&gt;] ? ip_rcv_finish+0x360/0x360

	These are reliably reproduced in a network topology of:

container:eth0 == host(OVS VXLAN on VLAN) == bond0 == eth0 (sky2) -&gt; switch

	When VXLAN encapsulated traffic is received from a similarly
configured peer, the above warning is generated in the receive
processing of the encapsulated packet.  Note that the warning is
associated with the container eth0.

        The skbs from sky2 have ip_summed set to CHECKSUM_COMPLETE, and
because the packet is an encapsulated Ethernet frame, the checksum
generated by the hardware includes the inner protocol and Ethernet
headers.

	The receive code is careful to update the skb-&gt;csum, except in
__dev_forward_skb, as called by dev_forward_skb.  __dev_forward_skb
calls eth_type_trans, which in turn calls skb_pull_inline(skb, ETH_HLEN)
to skip over the Ethernet header, but does not update skb-&gt;csum when
doing so.

	This patch resolves the problem by adding a call to
skb_postpull_rcsum to update the skb-&gt;csum after the call to
eth_type_trans.

Signed-off-by: Jay Vosburgh &lt;jay.vosburgh@canonical.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: Reset secmark when scrubbing packet</title>
<updated>2015-01-27T16:29:33+00:00</updated>
<author>
<name>Thomas Graf</name>
<email>tgraf@suug.ch</email>
</author>
<published>2014-12-23T00:13:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=253ab5247813de6ce1d5efcdf9bf7cde749d8597'/>
<id>253ab5247813de6ce1d5efcdf9bf7cde749d8597</id>
<content type='text'>
[ Upstream commit b8fb4e0648a2ab3734140342002f68fb0c7d1602 ]

skb_scrub_packet() is called when a packet switches between a context
such as between underlay and overlay, between namespaces, or between
L3 subnets.

While we already scrub the packet mark, connection tracking entry,
and cached destination, the security mark/context is left intact.

It seems wrong to inherit the security context of a packet when going
from overlay to underlay or across forwarding paths.

Signed-off-by: Thomas Graf &lt;tgraf@suug.ch&gt;
Acked-by: Flavio Leitner &lt;fbl@sysclose.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit b8fb4e0648a2ab3734140342002f68fb0c7d1602 ]

skb_scrub_packet() is called when a packet switches between a context
such as between underlay and overlay, between namespaces, or between
L3 subnets.

While we already scrub the packet mark, connection tracking entry,
and cached destination, the security mark/context is left intact.

It seems wrong to inherit the security context of a packet when going
from overlay to underlay or across forwarding paths.

Signed-off-by: Thomas Graf &lt;tgraf@suug.ch&gt;
Acked-by: Flavio Leitner &lt;fbl@sysclose.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: Fix stacked vlan offload features computation</title>
<updated>2015-01-27T16:29:33+00:00</updated>
<author>
<name>Toshiaki Makita</name>
<email>makita.toshiaki@lab.ntt.co.jp</email>
</author>
<published>2014-12-22T10:04:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=29862482563a6a445174109b149f210f69094da7'/>
<id>29862482563a6a445174109b149f210f69094da7</id>
<content type='text'>
[ Upstream commit 796f2da81bead71ffc91ef70912cd8d1827bf756 ]

When vlan tags are stacked, it is very likely that the outer tag is stored
in skb-&gt;vlan_tci and skb-&gt;protocol shows the inner tag's vlan_proto.
Currently netif_skb_features() first looks at skb-&gt;protocol even if there
is the outer tag in vlan_tci, thus it incorrectly retrieves the protocol
encapsulated by the inner vlan instead of the inner vlan protocol.
This allows GSO packets to be passed to HW and they end up being
corrupted.

Fixes: 58e998c6d239 ("offloading: Force software GSO for multiple vlan tags.")
Signed-off-by: Toshiaki Makita &lt;makita.toshiaki@lab.ntt.co.jp&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 796f2da81bead71ffc91ef70912cd8d1827bf756 ]

When vlan tags are stacked, it is very likely that the outer tag is stored
in skb-&gt;vlan_tci and skb-&gt;protocol shows the inner tag's vlan_proto.
Currently netif_skb_features() first looks at skb-&gt;protocol even if there
is the outer tag in vlan_tci, thus it incorrectly retrieves the protocol
encapsulated by the inner vlan instead of the inner vlan protocol.
This allows GSO packets to be passed to HW and they end up being
corrupted.

Fixes: 58e998c6d239 ("offloading: Force software GSO for multiple vlan tags.")
Signed-off-by: Toshiaki Makita &lt;makita.toshiaki@lab.ntt.co.jp&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tcp6: don't move IP6CB before xfrm6_policy_check()</title>
<updated>2015-01-27T16:29:33+00:00</updated>
<author>
<name>Nicolas Dichtel</name>
<email>nicolas.dichtel@6wind.com</email>
</author>
<published>2014-12-22T17:22:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=060e2832a5f5f7ec2ad3a1cc2803faf44ad690ec'/>
<id>060e2832a5f5f7ec2ad3a1cc2803faf44ad690ec</id>
<content type='text'>
[ Upstream commit 2dc49d1680b534877fd20cce52557ea542bb06b6 ]

When xfrm6_policy_check() is used, _decode_session6() is called after some
intermediate functions. This function uses IP6CB(), thus TCP_SKB_CB() must be
prepared after the call of xfrm6_policy_check().

Before this patch, scenarii with IPv6 + TCP + IPsec Transport are broken.

Fixes: 971f10eca186 ("tcp: better TCP_SKB_CB layout to reduce cache line misses")
Reported-by: Huaibin Wang &lt;huaibin.wang@6wind.com&gt;
Suggested-by: Eric Dumazet &lt;edumazet@google.com&gt;
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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 2dc49d1680b534877fd20cce52557ea542bb06b6 ]

When xfrm6_policy_check() is used, _decode_session6() is called after some
intermediate functions. This function uses IP6CB(), thus TCP_SKB_CB() must be
prepared after the call of xfrm6_policy_check().

Before this patch, scenarii with IPv6 + TCP + IPsec Transport are broken.

Fixes: 971f10eca186 ("tcp: better TCP_SKB_CB layout to reduce cache line misses")
Reported-by: Huaibin Wang &lt;huaibin.wang@6wind.com&gt;
Suggested-by: Eric Dumazet &lt;edumazet@google.com&gt;
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;
</pre>
</div>
</content>
</entry>
</feed>
