<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/mac80211/key.c, branch linux-3.2.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>mac80211: Fix null dereference in ieee80211_key_link()</title>
<updated>2017-11-26T13:51:11+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2017-11-22T02:04:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2c0a646da94d4e334e4070286e0361f91cd4f016'/>
<id>2c0a646da94d4e334e4070286e0361f91cd4f016</id>
<content type='text'>
Commit ef810e7c3d2a ("mac80211: accept key reinstall without changing
anything") moved the initialisation of key-&gt;sdata later in
ieee80211_key_link().  In the upstream commit fdf7cb4185b6 this was
fine, but in this version of the function there is additional code
which relies on key-&gt;sdata.  Change this to use the value that will be
(conditionally) assigned to it later.

Cc: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit ef810e7c3d2a ("mac80211: accept key reinstall without changing
anything") moved the initialisation of key-&gt;sdata later in
ieee80211_key_link().  In the upstream commit fdf7cb4185b6 this was
fine, but in this version of the function there is additional code
which relies on key-&gt;sdata.  Change this to use the value that will be
(conditionally) assigned to it later.

Cc: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: don't compare TKIP TX MIC key in reinstall prevention</title>
<updated>2017-11-26T13:51:11+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2017-10-24T19:12:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3599fa6eb4415945063710c7be20c74ce6f2e3b4'/>
<id>3599fa6eb4415945063710c7be20c74ce6f2e3b4</id>
<content type='text'>
commit cfbb0d90a7abb289edc91833d0905931f8805f12 upstream.

For the reinstall prevention, the code I had added compares the
whole key. It turns out though that iwlwifi firmware doesn't
provide the TKIP TX MIC key as it's not needed in client mode,
and thus the comparison will always return false.

For client mode, thus always zero out the TX MIC key part before
doing the comparison in order to avoid accepting the reinstall
of the key with identical encryption and RX MIC key, but not the
same TX MIC key (since the supplicant provides the real one.)

Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
[bwh: Backported to 3.2:
 - Keep using memcmp() as we don't have crypto_memneq()
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cfbb0d90a7abb289edc91833d0905931f8805f12 upstream.

For the reinstall prevention, the code I had added compares the
whole key. It turns out though that iwlwifi firmware doesn't
provide the TKIP TX MIC key as it's not needed in client mode,
and thus the comparison will always return false.

For client mode, thus always zero out the TX MIC key part before
doing the comparison in order to avoid accepting the reinstall
of the key with identical encryption and RX MIC key, but not the
same TX MIC key (since the supplicant provides the real one.)

Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
[bwh: Backported to 3.2:
 - Keep using memcmp() as we don't have crypto_memneq()
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: accept key reinstall without changing anything</title>
<updated>2017-11-11T13:34:38+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2017-09-05T12:54:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ef810e7c3d2a8fb3bbd23726599c487c30ea747e'/>
<id>ef810e7c3d2a8fb3bbd23726599c487c30ea747e</id>
<content type='text'>
commit fdf7cb4185b60c68e1a75e61691c4afdc15dea0e upstream.

When a key is reinstalled we can reset the replay counters
etc. which can lead to nonce reuse and/or replay detection
being impossible, breaking security properties, as described
in the "KRACK attacks".

In particular, CVE-2017-13080 applies to GTK rekeying that
happened in firmware while the host is in D3, with the second
part of the attack being done after the host wakes up. In
this case, the wpa_supplicant mitigation isn't sufficient
since wpa_supplicant doesn't know the GTK material.

In case this happens, simply silently accept the new key
coming from userspace but don't take any action on it since
it's the same key; this keeps the PN replay counters intact.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
[bwh: Backported to 3.2:
 - Use __ieee80211_key_free() instead of ieee80211_key_free_unused()
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit fdf7cb4185b60c68e1a75e61691c4afdc15dea0e upstream.

When a key is reinstalled we can reset the replay counters
etc. which can lead to nonce reuse and/or replay detection
being impossible, breaking security properties, as described
in the "KRACK attacks".

In particular, CVE-2017-13080 applies to GTK rekeying that
happened in firmware while the host is in D3, with the second
part of the attack being done after the host wakes up. In
this case, the wpa_supplicant mitigation isn't sufficient
since wpa_supplicant doesn't know the GTK material.

In case this happens, simply silently accept the new key
coming from userspace but don't take any action on it since
it's the same key; this keeps the PN replay counters intact.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
[bwh: Backported to 3.2:
 - Use __ieee80211_key_free() instead of ieee80211_key_free_unused()
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: Add export.h for EXPORT_SYMBOL/THIS_MODULE to non-modules</title>
<updated>2011-10-31T23:30:30+00:00</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2011-07-15T15:47:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bc3b2d7fb9b014d75ebb79ba371a763dbab5e8cf'/>
<id>bc3b2d7fb9b014d75ebb79ba371a763dbab5e8cf</id>
<content type='text'>
These files are non modular, but need to export symbols using
the macros now living in export.h -- call out the include so
that things won't break when we remove the implicit presence
of module.h from everywhere.

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These files are non modular, but need to export symbols using
the macros now living in export.h -- call out the include so
that things won't break when we remove the implicit presence
of module.h from everywhere.

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: optimise station flags</title>
<updated>2011-09-30T19:57:19+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-09-29T14:04:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c2c98fdeb5c897499644eb247285c8e3dacc6450'/>
<id>c2c98fdeb5c897499644eb247285c8e3dacc6450</id>
<content type='text'>
The flaglock in struct sta_info has long been
something that I wanted to get rid of, this
finally does the conversion to atomic bitops.

The conversion itself is straight-forward in
most places, a few things needed to change a
bit since we can no longer use multiple bits
at the same time.

On x86-64, this is a fairly significant code
size reduction:
   text	   data	    bss	    dec	    hex
 427861	  23648	   1008	 452517	  6e7a5	before
 425383	  23648	    976	 450007	  6ddd7	after

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The flaglock in struct sta_info has long been
something that I wanted to get rid of, this
finally does the conversion to atomic bitops.

The conversion itself is straight-forward in
most places, a few things needed to change a
bit since we can no longer use multiple bits
at the same time.

On x86-64, this is a fairly significant code
size reduction:
   text	   data	    bss	    dec	    hex
 427861	  23648	   1008	 452517	  6e7a5	before
 425383	  23648	    976	 450007	  6ddd7	after

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: let key iteration get keys in install order</title>
<updated>2011-07-15T17:38:33+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-07-13T17:50:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f850e00fcd7767d01101e2f0a6d464bee8e48b47'/>
<id>f850e00fcd7767d01101e2f0a6d464bee8e48b47</id>
<content type='text'>
ieee80211_iter_keys() currently returns keys in
the backward order they were installed in, which
is a bit confusing. Add them to the tail of the
key list to make sure iterations go in the same
order that keys were originally installed in.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ieee80211_iter_keys() currently returns keys in
the backward order they were installed in, which
is a bit confusing. Add them to the tail of the
key list to make sure iterations go in the same
order that keys were originally installed in.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: allow drivers to access key sequence counter</title>
<updated>2011-07-08T15:42:22+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-07-07T16:58:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3ea542d3c2862142ae511fac5ce2dfc7419dcc53'/>
<id>3ea542d3c2862142ae511fac5ce2dfc7419dcc53</id>
<content type='text'>
In order to implement GTK rekeying, the device needs
to be able to encrypt frames with the right PN/IV and
check the PN/IV in RX frames. To be able to tell it
about all those counters, we need to be able to get
them from mac80211, this adds the required API.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In order to implement GTK rekeying, the device needs
to be able to encrypt frames with the right PN/IV and
check the PN/IV in RX frames. To be able to tell it
about all those counters, we need to be able to get
them from mac80211, this adds the required API.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix TKIP races, make API easier to use</title>
<updated>2011-07-08T15:11:19+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-07-07T20:28:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=523b02ea23b175dd3e46e3daf1bc9354376640a3'/>
<id>523b02ea23b175dd3e46e3daf1bc9354376640a3</id>
<content type='text'>
Our current TKIP code races against itself on TX
since we can process multiple packets at the same
time on different ACs, but they all share the TX
context for TKIP. This can lead to bad IVs etc.

Also, the crypto offload helper code just obtains
the P1K/P2K from the cache, and can update it as
well, but there's no guarantee that packets are
really processed in order.

To fix these issues, first introduce a spinlock
that will protect the IV16/IV32 values in the TX
context. This first step makes sure that we don't
assign the same IV multiple times or get confused
in other ways.

Secondly, change the way the P1K cache works. I
add a field "p1k_iv32" that stores the value of
the IV32 when the P1K was last recomputed, and
if different from the last time, then a new P1K
is recomputed. This can cause the P1K computation
to flip back and forth if packets are processed
out of order. All this also happens under the new
spinlock.

Finally, because there are argument differences,
split up the ieee80211_get_tkip_key() API into
ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
and give them the correct arguments.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Our current TKIP code races against itself on TX
since we can process multiple packets at the same
time on different ACs, but they all share the TX
context for TKIP. This can lead to bad IVs etc.

Also, the crypto offload helper code just obtains
the P1K/P2K from the cache, and can update it as
well, but there's no guarantee that packets are
really processed in order.

To fix these issues, first introduce a spinlock
that will protect the IV16/IV32 values in the TX
context. This first step makes sure that we don't
assign the same IV multiple times or get confused
in other ways.

Secondly, change the way the P1K cache works. I
add a field "p1k_iv32" that stores the value of
the IV32 when the P1K was last recomputed, and
if different from the last time, then a new P1K
is recomputed. This can cause the P1K computation
to flip back and forth if packets are processed
out of order. All this also happens under the new
spinlock.

Finally, because there are argument differences,
split up the ieee80211_get_tkip_key() API into
ieee80211_get_tkip_p1k() and ieee80211_get_tkip_p2k()
and give them the correct arguments.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: support GTK rekey offload</title>
<updated>2011-07-06T19:05:43+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-07-05T14:35:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c68f4b892c241bdddeb6f1c1864ac26197229471'/>
<id>c68f4b892c241bdddeb6f1c1864ac26197229471</id>
<content type='text'>
This adds the necessary mac80211 APIs to support
GTK rekey offload, mirroring the functionality
from cfg80211.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This adds the necessary mac80211 APIs to support
GTK rekey offload, mirroring the functionality
from cfg80211.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: allow driver to iterate keys</title>
<updated>2011-07-06T19:05:41+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-07-05T14:35:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=830af02f24fbc087999b757b8eca51829c67fa6f'/>
<id>830af02f24fbc087999b757b8eca51829c67fa6f</id>
<content type='text'>
When in suspend/wowlan, devices might implement crypto
offload differently (more features), and might require
reprogramming keys for the WoWLAN (as it is the case
for Intel devices that use another uCode image). Thus
allow the driver to iterate all keys in this context.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When in suspend/wowlan, devices might implement crypto
offload differently (more features), and might require
reprogramming keys for the WoWLAN (as it is the case
for Intel devices that use another uCode image). Thus
allow the driver to iterate all keys in this context.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
