<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/mac80211, branch v3.0.22</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>mac80211: timeout a single frame in the rx reorder buffer</title>
<updated>2012-02-20T20:48:11+00:00</updated>
<author>
<name>Eliad Peller</name>
<email>eliad@wizery.com</email>
</author>
<published>2012-02-01T16:48:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=36935521cd67e3df9a1db71591cf224252d6082c'/>
<id>36935521cd67e3df9a1db71591cf224252d6082c</id>
<content type='text'>
commit 07ae2dfcf4f7143ce191c6436da1c33f179af0d6 upstream.

The current code checks for stored_mpdu_num &gt; 1, causing
the reorder_timer to be triggered indefinitely, but the
frame is never timed-out (until the next packet is received)

Signed-off-by: Eliad Peller &lt;eliad@wizery.com&gt;
Acked-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.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 07ae2dfcf4f7143ce191c6436da1c33f179af0d6 upstream.

The current code checks for stored_mpdu_num &gt; 1, causing
the reorder_timer to be triggered indefinitely, but the
frame is never timed-out (until the next packet is received)

Signed-off-by: Eliad Peller &lt;eliad@wizery.com&gt;
Acked-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix rx-&gt;key NULL pointer dereference in promiscuous mode</title>
<updated>2012-01-26T01:24:43+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2012-01-11T08:26:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b9e11747e1227d7ad67c5b80be4b206e4059687e'/>
<id>b9e11747e1227d7ad67c5b80be4b206e4059687e</id>
<content type='text'>
commit 1140afa862842ac3e56678693050760edc4ecde9 upstream.

Since:

commit 816c04fe7ef01dd9649f5ccfe796474db8708be5
Author: Christian Lamparter &lt;chunkeey@googlemail.com&gt;
Date:   Sat Apr 30 15:24:30 2011 +0200

    mac80211: consolidate MIC failure report handling

is possible to that we dereference rx-&gt;key == NULL when driver set
RX_FLAG_MMIC_STRIPPED and not RX_FLAG_IV_STRIPPED and we are in
promiscuous mode. This happen with rt73usb and rt61pci at least.

Before the commit we always check rx-&gt;key against NULL, so I assume
fix should be done in mac80211 (also mic_fail path has similar check).

References:
https://bugzilla.redhat.com/show_bug.cgi?id=769766
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-January/004395.html

Reported-by: Stuart D Gathman &lt;stuart@gathman.org&gt;
Reported-by: Kai Wohlfahrt &lt;kai.scorpio@gmail.com&gt;
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

Since:

commit 816c04fe7ef01dd9649f5ccfe796474db8708be5
Author: Christian Lamparter &lt;chunkeey@googlemail.com&gt;
Date:   Sat Apr 30 15:24:30 2011 +0200

    mac80211: consolidate MIC failure report handling

is possible to that we dereference rx-&gt;key == NULL when driver set
RX_FLAG_MMIC_STRIPPED and not RX_FLAG_IV_STRIPPED and we are in
promiscuous mode. This happen with rt73usb and rt61pci at least.

Before the commit we always check rx-&gt;key against NULL, so I assume
fix should be done in mac80211 (also mic_fail path has similar check).

References:
https://bugzilla.redhat.com/show_bug.cgi?id=769766
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-January/004395.html

Reported-by: Stuart D Gathman &lt;stuart@gathman.org&gt;
Reported-by: Kai Wohlfahrt &lt;kai.scorpio@gmail.com&gt;
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix another race in aggregation start</title>
<updated>2012-01-06T22:13:48+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-12-07T08:02:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=afa2450ce311b3182c737c3fda59bb557da93409'/>
<id>afa2450ce311b3182c737c3fda59bb557da93409</id>
<content type='text'>
commit 15062e6a8524f5977f2cbdf6e3eb2f144262f74e upstream.

Emmanuel noticed that when mac80211 stops the queues
for aggregation that can leave a packet pending. This
packet will be given to the driver after the AMPDU
callback, but as a non-aggregated packet which messes
up the sequence number etc.

I also noticed by looking at the code that if packets
are being processed while we clear the WANT_START bit,
they might see it cleared already and queue up on
tid_tx-&gt;pending. If the driver then rejects the new
aggregation session we leak the packet.

Fix both of these issues by changing this code to not
stop the queues at all. Instead, let packets queue up
on the tid_tx-&gt;pending queue instead of letting them
get to the driver, and add code to recover properly
in case the driver rejects the session.

(The patch looks large because it has to move two
functions to before their new use.)

Reported-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@suse.de&gt;

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

Emmanuel noticed that when mac80211 stops the queues
for aggregation that can leave a packet pending. This
packet will be given to the driver after the AMPDU
callback, but as a non-aggregated packet which messes
up the sequence number etc.

I also noticed by looking at the code that if packets
are being processed while we clear the WANT_START bit,
they might see it cleared already and queue up on
tid_tx-&gt;pending. If the driver then rejects the new
aggregation session we leak the packet.

Fix both of these issues by changing this code to not
stop the queues at all. Instead, let packets queue up
on the tid_tx-&gt;pending queue instead of letting them
get to the driver, and add code to recover properly
in case the driver rejects the session.

(The patch looks large because it has to move two
functions to before their new use.)

Reported-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@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix race condition caused by late addBA response</title>
<updated>2011-12-21T20:57:38+00:00</updated>
<author>
<name>Nikolay Martynov</name>
<email>mar.kolya@gmail.com</email>
</author>
<published>2011-12-10T16:31:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5009514a0967db0060656c70de812b8643417da7'/>
<id>5009514a0967db0060656c70de812b8643417da7</id>
<content type='text'>
Upstream commit d305a6557b2c4dca0110f05ffe745b1ef94adb80.

If addBA responses comes in just after addba_resp_timer has
expired mac80211 will still accept it and try to open the
aggregation session. This causes drivers to be confused and
in some cases even crash.

This patch fixes the race condition and makes sure that if
addba_resp_timer has expired addBA response is not longer
accepted and we do not try to open half-closed session.

Signed-off-by: Nikolay Martynov &lt;mar.kolya@gmail.com&gt;
[some adjustments]
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@suse.de&gt;

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

If addBA responses comes in just after addba_resp_timer has
expired mac80211 will still accept it and try to open the
aggregation session. This causes drivers to be confused and
in some cases even crash.

This patch fixes the race condition and makes sure that if
addba_resp_timer has expired addBA response is not longer
accepted and we do not try to open half-closed session.

Signed-off-by: Nikolay Martynov &lt;mar.kolya@gmail.com&gt;
[some adjustments]
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@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix race between the AGG SM and the Tx data path</title>
<updated>2011-12-09T16:52:33+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2011-11-27T13:29:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=20f8d725863ca926a199cab1bc5cf31f8bf53cb0'/>
<id>20f8d725863ca926a199cab1bc5cf31f8bf53cb0</id>
<content type='text'>
commit 2a1e0fd175dcfd72096ba9291d31e3b1b5342e60 upstream.

When a packet is supposed to sent be as an a-MPDU, mac80211 sets
IEEE80211_TX_CTL_AMPDU to let the driver know. On the other
hand, mac80211 configures the driver for aggregration with the
ampdu_action callback.
There is race between these two mechanisms since the following
scenario can occur when the BA agreement is torn down:

Tx softIRQ	 			drv configuration
==========				=================

check OPERATIONAL bit
Set the TX_CTL_AMPDU bit in the packet

					clear OPERATIONAL bit
					stop Tx AGG
Pass Tx packet to the driver.

In that case the driver would get a packet with TX_CTL_AMPDU set
although it has already been notified that the BA session has been
torn down.

To fix this, we need to synchronize all the Qdisc activity after we
cleared the OPERATIONAL bit. After that step, all the following
packets will be buffered until the driver reports it is ready to get
new packets for this RA / TID. This buffering allows not to run into
another race that would send packets with TX_CTL_AMPDU unset while
the driver hasn't been requested to tear down the BA session yet.

This race occurs in practice and iwlwifi complains with a WARN_ON
when it happens.

Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Reviewed-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

When a packet is supposed to sent be as an a-MPDU, mac80211 sets
IEEE80211_TX_CTL_AMPDU to let the driver know. On the other
hand, mac80211 configures the driver for aggregration with the
ampdu_action callback.
There is race between these two mechanisms since the following
scenario can occur when the BA agreement is torn down:

Tx softIRQ	 			drv configuration
==========				=================

check OPERATIONAL bit
Set the TX_CTL_AMPDU bit in the packet

					clear OPERATIONAL bit
					stop Tx AGG
Pass Tx packet to the driver.

In that case the driver would get a packet with TX_CTL_AMPDU set
although it has already been notified that the BA session has been
torn down.

To fix this, we need to synchronize all the Qdisc activity after we
cleared the OPERATIONAL bit. After that step, all the following
packets will be buffered until the driver reports it is ready to get
new packets for this RA / TID. This buffering allows not to run into
another race that would send packets with TX_CTL_AMPDU unset while
the driver hasn't been requested to tear down the BA session yet.

This race occurs in practice and iwlwifi complains with a WARN_ON
when it happens.

Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Reviewed-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: don't stop a single aggregation session twice</title>
<updated>2011-12-09T16:52:33+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-11-24T19:06:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=64a1b241dd84ed6b12b62bbb67b380609bdd50b2'/>
<id>64a1b241dd84ed6b12b62bbb67b380609bdd50b2</id>
<content type='text'>
commit 24f50a9d165745fd0701c6e089d35f58a229ea69 upstream.

Nikolay noticed (by code review) that mac80211 can
attempt to stop an aggregation session while it is
already being stopped. So to fix it, check whether
stop is already being done and bail out if so.

Also move setting the STOPPING state into the lock
so things are properly atomic.

Reported-by: Nikolay Martynov &lt;mar.kolya@gmail.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@suse.de&gt;

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

Nikolay noticed (by code review) that mac80211 can
attempt to stop an aggregation session while it is
already being stopped. So to fix it, check whether
stop is already being done and bail out if so.

Also move setting the STOPPING state into the lock
so things are properly atomic.

Reported-by: Nikolay Martynov &lt;mar.kolya@gmail.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@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix bug in ieee80211_build_probe_req</title>
<updated>2011-11-26T17:09:54+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-11-08T12:04:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ae1e9df381d5197015356e22de9d7acaf646a9ab'/>
<id>ae1e9df381d5197015356e22de9d7acaf646a9ab</id>
<content type='text'>
commit 5b2bbf75a24d6b06afff6de0eb4819413fd81971 upstream.

ieee80211_probereq_get() can return NULL in
which case we should clean up &amp; return NULL
in ieee80211_build_probe_req() as well.

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@suse.de&gt;

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

ieee80211_probereq_get() can return NULL in
which case we should clean up &amp; return NULL
in ieee80211_build_probe_req() as well.

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@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix NULL dereference in radiotap code</title>
<updated>2011-11-26T17:09:54+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-11-08T11:28:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=492d7eff2def54c6e5521ee82764ca22025e7030'/>
<id>492d7eff2def54c6e5521ee82764ca22025e7030</id>
<content type='text'>
commit f8d1ccf15568268c76f913b45ecdd33134387f1a upstream.

When receiving failed PLCP frames is enabled, there
won't be a rate pointer when we add the radiotap
header and thus the kernel will crash. Fix this by
not assuming the rate pointer is always valid. It's
still always valid for frames that have good PLCP
though, and that is checked &amp; enforced.

This was broken by my
commit fc88518916793af8ad6a02e05ff254d95c36d875
Author: Johannes Berg &lt;johannes.berg@intel.com&gt;
Date:   Fri Jul 30 13:23:12 2010 +0200

    mac80211: don't check rates on PLCP error frames

where I removed the check in this case but didn't
take into account that the rate info would be used.

Reported-by: Xiaokang Qin &lt;xiaokang.qin@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@suse.de&gt;

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

When receiving failed PLCP frames is enabled, there
won't be a rate pointer when we add the radiotap
header and thus the kernel will crash. Fix this by
not assuming the rate pointer is always valid. It's
still always valid for frames that have good PLCP
though, and that is checked &amp; enforced.

This was broken by my
commit fc88518916793af8ad6a02e05ff254d95c36d875
Author: Johannes Berg &lt;johannes.berg@intel.com&gt;
Date:   Fri Jul 30 13:23:12 2010 +0200

    mac80211: don't check rates on PLCP error frames

where I removed the check in this case but didn't
take into account that the rate info would be used.

Reported-by: Xiaokang Qin &lt;xiaokang.qin@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@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: disable powersave for broken APs</title>
<updated>2011-11-11T17:37:13+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-10-28T09:59:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=041f9e20b7f794fd7b4932e05d0c938a9ebbf658'/>
<id>041f9e20b7f794fd7b4932e05d0c938a9ebbf658</id>
<content type='text'>
commit 05cb91085760ca378f28fc274fbf77fc4fd9886c upstream.

Only AID values 1-2007 are valid, but some APs have been
found to send random bogus values, in the reported case an
AP that was sending the AID field value 0xffff, an AID of
0x3fff (16383).

There isn't much we can do but disable powersave since
there's no way it can work properly in this case.

Reported-by: Bill C Riemers &lt;briemers@redhat.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@suse.de&gt;

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

Only AID values 1-2007 are valid, but some APs have been
found to send random bogus values, in the reported case an
AP that was sending the AID field value 0xffff, an AID of
0x3fff (16383).

There isn't much we can do but disable powersave since
there's no way it can work properly in this case.

Reported-by: Bill C Riemers &lt;briemers@redhat.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@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: config hw when going back on-channel</title>
<updated>2011-11-11T17:37:12+00:00</updated>
<author>
<name>Eliad Peller</name>
<email>eliad@wizery.com</email>
</author>
<published>2011-10-20T17:05:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=42c6d01ce89d43598fc804cf7c141d3252fe93b5'/>
<id>42c6d01ce89d43598fc804cf7c141d3252fe93b5</id>
<content type='text'>
commit 6911bf0453e0d6ea8eb694a4ce67a68d071c538e upstream.

When going back on-channel, we should reconfigure
the hw iff the hardware is not already configured
to the operational channel.

Signed-off-by: Eliad Peller &lt;eliad@wizery.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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

When going back on-channel, we should reconfigure
the hw iff the hardware is not already configured
to the operational channel.

Signed-off-by: Eliad Peller &lt;eliad@wizery.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
</feed>
