<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/net/mac80211, branch linux-4.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2018-05-23T01:36:22Z</updated>
<entry>
<title>mac80211: bail out from prep_connection() if a reconfig is ongoing</title>
<updated>2018-05-23T01:36:22Z</updated>
<author>
<name>Luca Coelho</name>
<email>luciano.coelho@intel.com</email>
</author>
<published>2017-05-02T14:56:21Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=20d3790f2a66abb36f8fcc984dfadd53c9a7e2de'/>
<id>urn:sha1:20d3790f2a66abb36f8fcc984dfadd53c9a7e2de</id>
<content type='text'>
[ Upstream commit f8860ce836f2d502b07ef99559707fe55d90f5bc ]

If ieee80211_hw_restart() is called during authentication, the
authentication process will continue, causing the driver to be called
in a wrong state.  This ultimately causes an oops in the iwlwifi
driver (at least).

This fixes bugzilla 195299 partly.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195299
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>mac80211: don't parse encrypted management frames in ieee80211_frame_acked</title>
<updated>2018-05-23T01:33:50Z</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2017-04-26T07:58:51Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=942a590aa716cfa6ba20bd3cf4d62d723b769345'/>
<id>urn:sha1:942a590aa716cfa6ba20bd3cf4d62d723b769345</id>
<content type='text'>
[ Upstream commit cf147085fdda044622973a12e4e06f1c753ab677 ]

ieee80211_frame_acked is called when a frame is acked by
the peer. In case this is a management frame, we check
if this an SMPS frame, in which case we can update our
antenna configuration.

When we parse the management frame we look at the category
in case it is an action frame. That byte sits after the IV
in case the frame was encrypted. This means that if the
frame was encrypted, we basically look at the IV instead
of looking at the category. It is then theorically
possible that we think that an SMPS action frame was acked
where really we had another frame that was encrypted.

Since the only management frame whose ack needs to be
tracked is the SMPS action frame, and that frame is not
a robust management frame, it will never be encrypted.
The easiest way to fix this problem is then to not look
at frames that were encrypted.

Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>mac80211: remove BUG() when interface type is invalid</title>
<updated>2018-05-23T01:33:47Z</updated>
<author>
<name>Luca Coelho</name>
<email>luciano.coelho@intel.com</email>
</author>
<published>2017-10-29T09:51:10Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=38a1080acf6c51f5431bf6a16fad2164d4ac84e4'/>
<id>urn:sha1:38a1080acf6c51f5431bf6a16fad2164d4ac84e4</id>
<content type='text'>
[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]

In the ieee80211_setup_sdata() we check if the interface type is valid
and, if not, call BUG().  This should never happen, but if there is
something wrong with the code, it will not be caught until the bug
happens when an interface is being set up.  Calling BUG() is too
extreme for this and a WARN_ON() would be better used instead.  Change
that.

Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>cfg80211: fix cfg80211_beacon_dup</title>
<updated>2018-03-04T15:28:34Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2018-02-02T15:31:23Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=953eb3c3136bb7f881b50e004a5153c068ef84a7'/>
<id>urn:sha1:953eb3c3136bb7f881b50e004a5153c068ef84a7</id>
<content type='text'>
[ Upstream commit bee92d06157fc39d5d7836a061c7d41289a55797 ]

gcc-8 warns about some obviously incorrect code:

net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]

From the context, I conclude that we want to copy from beacon into
new_beacon, as we do in the rest of the function.

Cc: stable@vger.kernel.org
Fixes: 73da7d5bab79 ("mac80211: add channel switch command and beacon callbacks")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>mac80211: fix the update of path metric for RANN frame</title>
<updated>2018-03-01T03:09:46Z</updated>
<author>
<name>Chun-Yeow Yeoh</name>
<email>yeohchunyeow@gmail.com</email>
</author>
<published>2017-11-14T15:20:05Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e1caa64a6ef0a060f409e135572ca614e9585233'/>
<id>urn:sha1:e1caa64a6ef0a060f409e135572ca614e9585233</id>
<content type='text'>
[ Upstream commit fbbdad5edf0bb59786a51b94a9d006bc8c2da9a2 ]

The previous path metric update from RANN frame has not considered
the own link metric toward the transmitting mesh STA. Fix this.

Reported-by: Michael65535
Signed-off-by: Chun-Yeow Yeoh &lt;yeohchunyeow@gmail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>mac80211: Fix addition of mesh configuration element</title>
<updated>2018-01-17T17:55:32Z</updated>
<author>
<name>Ilan peer</name>
<email>ilan.peer@intel.com</email>
</author>
<published>2016-12-26T16:17:36Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8445dd361d31cebdb8ecaaf356258bf27ebe4cce'/>
<id>urn:sha1:8445dd361d31cebdb8ecaaf356258bf27ebe4cce</id>
<content type='text'>
[ Upstream commit 57629915d568c522ac1422df7bba4bee5b5c7a7c ]

The code was setting the capabilities byte to zero,
after it was already properly set previously. Fix it.

The bug was found while debugging hwsim mesh tests failures
that happened since the commit mentioned below.

Fixes: 76f43b4c0a93 ("mac80211: Remove invalid flag operations in mesh TSF synchronization")
Signed-off-by: Ilan Peer &lt;ilan.peer@intel.com&gt;
Reviewed-by: Masashi Honma &lt;masashi.honma@gmail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>mac80211: Suppress NEW_PEER_CANDIDATE event if no room</title>
<updated>2017-12-08T23:01:10Z</updated>
<author>
<name>Masashi Honma</name>
<email>masashi.honma@gmail.com</email>
</author>
<published>2016-11-30T00:06:04Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a60c66435e3f9002cc777d49f875742f2268b063'/>
<id>urn:sha1:a60c66435e3f9002cc777d49f875742f2268b063</id>
<content type='text'>
[ Upstream commit 11197d006bcfabf0173a7820a163fcaac420d10e ]

Previously, kernel sends NEW_PEER_CANDIDATE event to user land even if
the found peer does not have any room to accept other peer. This causes
continuous connection trials.

Signed-off-by: Masashi Honma &lt;masashi.honma@gmail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>mac80211: Remove invalid flag operations in mesh TSF synchronization</title>
<updated>2017-12-08T23:01:10Z</updated>
<author>
<name>Masashi Honma</name>
<email>masashi.honma@gmail.com</email>
</author>
<published>2016-12-08T01:15:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ff212c6eceb041f02cefb8c707b9165f4d1cb3c4'/>
<id>urn:sha1:ff212c6eceb041f02cefb8c707b9165f4d1cb3c4</id>
<content type='text'>
[ Upstream commit 76f43b4c0a9337af22827d78de4f2b8fd5328489 ]

mesh_sync_offset_adjust_tbtt() implements Extensible synchronization
framework ([1] 13.13.2 Extensible synchronization framework). It shall
not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh
Capability), since it is used only for MBCA ([1] 13.13.4 Mesh beacon
collision avoidance, see 13.13.4.4.3 TBTT scanning and adjustment
procedures for detail). So this patch remove the flag operations.

[1] IEEE Std 802.11 2012

Signed-off-by: Masashi Honma &lt;masashi.honma@gmail.com&gt;
[remove adjusting_tbtt entirely, since it's now unused]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;

Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>mac80211: don't compare TKIP TX MIC key in reinstall prevention</title>
<updated>2017-12-07T02:20:05Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2017-10-24T19:12:13Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ffff8defb5b4bc855a55ba160a3efeefb51e55fd'/>
<id>urn:sha1:ffff8defb5b4bc855a55ba160a3efeefb51e55fd</id>
<content type='text'>
[ Upstream commit cfbb0d90a7abb289edc91833d0905931f8805f12 ]

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;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
<entry>
<title>mac80211: use constant time comparison with keys</title>
<updated>2017-12-07T02:20:05Z</updated>
<author>
<name>Jason A. Donenfeld</name>
<email>Jason@zx2c4.com</email>
</author>
<published>2017-10-17T18:32:07Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=db6a015e846a747a4b8a96daad1d9ff59454c0cc'/>
<id>urn:sha1:db6a015e846a747a4b8a96daad1d9ff59454c0cc</id>
<content type='text'>
[ Upstream commit 2bdd713b92a9cade239d3c7d15205a09f556624d ]

Otherwise we risk leaking information via timing side channel.

Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
</entry>
</feed>
