<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/wireless, branch v3.0.11</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>cfg80211: fix bug on regulatory core exit on access to last_request</title>
<updated>2011-11-26T17:09:55+00:00</updated>
<author>
<name>Luis R. Rodriguez</name>
<email>mcgrof@qca.qualcomm.com</email>
</author>
<published>2011-11-08T22:28:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5c02e3ae0a16cfc2fb86549cca9898ead2b0d666'/>
<id>5c02e3ae0a16cfc2fb86549cca9898ead2b0d666</id>
<content type='text'>
commit 58ebacc66bd11be2327edcefc79de94bd6f5bb4a upstream.

Commit 4d9d88d1 by Scott James Remnant &lt;keybuk@google.com&gt; added
the .uevent() callback for the regulatory device used during
the platform device registration. The change was done to account
for queuing up udev change requests through udevadm triggers.
The change also meant that upon regulatory core exit we will now
send a uevent() but the uevent() callback, reg_device_uevent(),
also accessed last_request. Right before commiting device suicide
we free'd last_request but never set it to NULL so
platform_device_unregister() would lead to bogus kernel paging
request. Fix this and also simply supress uevents right before
we commit suicide as they are pointless.

This fix is required for kernels &gt;= v2.6.39

$ git describe --contains 4d9d88d1
v2.6.39-rc1~468^2~25^2^2~21

The impact of not having this present is that a bogus paging
access may occur (only read) upon cfg80211 unload time. You
may also get this BUG complaint below. Although Johannes
could not reproduce the issue this fix is theoretically correct.

mac80211_hwsim: unregister radios
mac80211_hwsim: closing netlink
BUG: unable to handle kernel paging request at ffff88001a06b5ab
IP: [&lt;ffffffffa030df9a&gt;] reg_device_uevent+0x1a/0x50 [cfg80211]
PGD 1836063 PUD 183a063 PMD 1ffcb067 PTE 1a06b160
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU 0
Modules linked in: cfg80211(-) [last unloaded: mac80211]

Pid: 2279, comm: rmmod Tainted: G        W   3.1.0-wl+ #663 Bochs Bochs
RIP: 0010:[&lt;ffffffffa030df9a&gt;]  [&lt;ffffffffa030df9a&gt;] reg_device_uevent+0x1a/0x50 [cfg80211]
RSP: 0000:ffff88001c5f9d58  EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88001d2eda88 RCX: ffff88001c7468fc
RDX: ffff88001a06b5a0 RSI: ffff88001c7467b0 RDI: ffff88001c7467b0
RBP: ffff88001c5f9d58 R08: 000000000000ffff R09: 000000000000ffff
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001c7467b0
R13: ffff88001d2eda78 R14: ffffffff8164a840 R15: 0000000000000001
FS:  00007f8a91d8a6e0(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff88001a06b5ab CR3: 000000001c62e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process rmmod (pid: 2279, threadinfo ffff88001c5f8000, task ffff88000023c780)
Stack:
 ffff88001c5f9d98 ffffffff812ff7e5 ffffffff8176ab3d ffff88001c7468c2
 000000000000ffff ffff88001d2eda88 ffff88001c7467b0 ffff880000114820
 ffff88001c5f9e38 ffffffff81241dc7 ffff88001c5f9db8 ffffffff81040189
Call Trace:
 [&lt;ffffffff812ff7e5&gt;] dev_uevent+0xc5/0x170
 [&lt;ffffffff81241dc7&gt;] kobject_uevent_env+0x1f7/0x490
 [&lt;ffffffff81040189&gt;] ? sub_preempt_count+0x29/0x60
 [&lt;ffffffff814cab1a&gt;] ? _raw_spin_unlock_irqrestore+0x4a/0x90
 [&lt;ffffffff81305307&gt;] ? devres_release_all+0x27/0x60
 [&lt;ffffffff8124206b&gt;] kobject_uevent+0xb/0x10
 [&lt;ffffffff812fee27&gt;] device_del+0x157/0x1b0
 [&lt;ffffffff8130377d&gt;] platform_device_del+0x1d/0x90
 [&lt;ffffffff81303b76&gt;] platform_device_unregister+0x16/0x30
 [&lt;ffffffffa030fffd&gt;] regulatory_exit+0x5d/0x180 [cfg80211]
 [&lt;ffffffffa032bec3&gt;] cfg80211_exit+0x2b/0x45 [cfg80211]
 [&lt;ffffffff8109a84c&gt;] sys_delete_module+0x16c/0x220
 [&lt;ffffffff8108a23e&gt;] ? trace_hardirqs_on_caller+0x7e/0x120
 [&lt;ffffffff814cba02&gt;] system_call_fastpath+0x16/0x1b
Code: &lt;all your base are belong to me&gt;
RIP  [&lt;ffffffffa030df9a&gt;] reg_device_uevent+0x1a/0x50 [cfg80211]
 RSP &lt;ffff88001c5f9d58&gt;
CR2: ffff88001a06b5ab
---[ end trace 147c5099a411e8c0 ]---

Reported-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Cc: Scott James Remnant &lt;keybuk@google.com&gt;
Signed-off-by: Luis R. Rodriguez &lt;mcgrof@qca.qualcomm.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 58ebacc66bd11be2327edcefc79de94bd6f5bb4a upstream.

Commit 4d9d88d1 by Scott James Remnant &lt;keybuk@google.com&gt; added
the .uevent() callback for the regulatory device used during
the platform device registration. The change was done to account
for queuing up udev change requests through udevadm triggers.
The change also meant that upon regulatory core exit we will now
send a uevent() but the uevent() callback, reg_device_uevent(),
also accessed last_request. Right before commiting device suicide
we free'd last_request but never set it to NULL so
platform_device_unregister() would lead to bogus kernel paging
request. Fix this and also simply supress uevents right before
we commit suicide as they are pointless.

This fix is required for kernels &gt;= v2.6.39

$ git describe --contains 4d9d88d1
v2.6.39-rc1~468^2~25^2^2~21

The impact of not having this present is that a bogus paging
access may occur (only read) upon cfg80211 unload time. You
may also get this BUG complaint below. Although Johannes
could not reproduce the issue this fix is theoretically correct.

mac80211_hwsim: unregister radios
mac80211_hwsim: closing netlink
BUG: unable to handle kernel paging request at ffff88001a06b5ab
IP: [&lt;ffffffffa030df9a&gt;] reg_device_uevent+0x1a/0x50 [cfg80211]
PGD 1836063 PUD 183a063 PMD 1ffcb067 PTE 1a06b160
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU 0
Modules linked in: cfg80211(-) [last unloaded: mac80211]

Pid: 2279, comm: rmmod Tainted: G        W   3.1.0-wl+ #663 Bochs Bochs
RIP: 0010:[&lt;ffffffffa030df9a&gt;]  [&lt;ffffffffa030df9a&gt;] reg_device_uevent+0x1a/0x50 [cfg80211]
RSP: 0000:ffff88001c5f9d58  EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88001d2eda88 RCX: ffff88001c7468fc
RDX: ffff88001a06b5a0 RSI: ffff88001c7467b0 RDI: ffff88001c7467b0
RBP: ffff88001c5f9d58 R08: 000000000000ffff R09: 000000000000ffff
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001c7467b0
R13: ffff88001d2eda78 R14: ffffffff8164a840 R15: 0000000000000001
FS:  00007f8a91d8a6e0(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff88001a06b5ab CR3: 000000001c62e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process rmmod (pid: 2279, threadinfo ffff88001c5f8000, task ffff88000023c780)
Stack:
 ffff88001c5f9d98 ffffffff812ff7e5 ffffffff8176ab3d ffff88001c7468c2
 000000000000ffff ffff88001d2eda88 ffff88001c7467b0 ffff880000114820
 ffff88001c5f9e38 ffffffff81241dc7 ffff88001c5f9db8 ffffffff81040189
Call Trace:
 [&lt;ffffffff812ff7e5&gt;] dev_uevent+0xc5/0x170
 [&lt;ffffffff81241dc7&gt;] kobject_uevent_env+0x1f7/0x490
 [&lt;ffffffff81040189&gt;] ? sub_preempt_count+0x29/0x60
 [&lt;ffffffff814cab1a&gt;] ? _raw_spin_unlock_irqrestore+0x4a/0x90
 [&lt;ffffffff81305307&gt;] ? devres_release_all+0x27/0x60
 [&lt;ffffffff8124206b&gt;] kobject_uevent+0xb/0x10
 [&lt;ffffffff812fee27&gt;] device_del+0x157/0x1b0
 [&lt;ffffffff8130377d&gt;] platform_device_del+0x1d/0x90
 [&lt;ffffffff81303b76&gt;] platform_device_unregister+0x16/0x30
 [&lt;ffffffffa030fffd&gt;] regulatory_exit+0x5d/0x180 [cfg80211]
 [&lt;ffffffffa032bec3&gt;] cfg80211_exit+0x2b/0x45 [cfg80211]
 [&lt;ffffffff8109a84c&gt;] sys_delete_module+0x16c/0x220
 [&lt;ffffffff8108a23e&gt;] ? trace_hardirqs_on_caller+0x7e/0x120
 [&lt;ffffffff814cba02&gt;] system_call_fastpath+0x16/0x1b
Code: &lt;all your base are belong to me&gt;
RIP  [&lt;ffffffffa030df9a&gt;] reg_device_uevent+0x1a/0x50 [cfg80211]
 RSP &lt;ffff88001c5f9d58&gt;
CR2: ffff88001a06b5ab
---[ end trace 147c5099a411e8c0 ]---

Reported-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Cc: Scott James Remnant &lt;keybuk@google.com&gt;
Signed-off-by: Luis R. Rodriguez &lt;mcgrof@qca.qualcomm.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>nl80211: fix HT capability attribute validation</title>
<updated>2011-11-26T17:09:55+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-11-03T08:27:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c1ce1705eb0778927a0b81a6eb29e8ff193aa3de'/>
<id>c1ce1705eb0778927a0b81a6eb29e8ff193aa3de</id>
<content type='text'>
commit 6c7394197af90f6a332180e33f5d025d3037d883 upstream.

Since the NL80211_ATTR_HT_CAPABILITY attribute is
used as a struct, it needs a minimum, not maximum
length. Enforce that properly. Not doing so could
potentially lead to reading after the buffer.

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 6c7394197af90f6a332180e33f5d025d3037d883 upstream.

Since the NL80211_ATTR_HT_CAPABILITY attribute is
used as a struct, it needs a minimum, not maximum
length. Enforce that properly. Not doing so could
potentially lead to reading after the buffer.

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>cfg80211: Fix validation of AKM suites</title>
<updated>2011-10-03T18:41:10+00:00</updated>
<author>
<name>Jouni Malinen</name>
<email>jouni@qca.qualcomm.com</email>
</author>
<published>2011-09-21T13:13:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=508ed7445438cb6dffa105a128333c8461bfd5e4'/>
<id>508ed7445438cb6dffa105a128333c8461bfd5e4</id>
<content type='text'>
commit 1b9ca0272ffae212e726380f66777b30a56ed7a5 upstream.

Incorrect variable was used in validating the akm_suites array from
NL80211_ATTR_AKM_SUITES. In addition, there was no explicit
validation of the array length (we only have room for
NL80211_MAX_NR_AKM_SUITES).

This can result in a buffer write overflow for stack variables with
arbitrary data from user space. The nl80211 commands using the affected
functionality require GENL_ADMIN_PERM, so this is only exposed to admin
users.

Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.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 1b9ca0272ffae212e726380f66777b30a56ed7a5 upstream.

Incorrect variable was used in validating the akm_suites array from
NL80211_ATTR_AKM_SUITES. In addition, there was no explicit
validation of the array length (we only have room for
NL80211_MAX_NR_AKM_SUITES).

This can result in a buffer write overflow for stack variables with
arbitrary data from user space. The nl80211 commands using the affected
functionality require GENL_ADMIN_PERM, so this is only exposed to admin
users.

Signed-off-by: Jouni Malinen &lt;jouni@qca.qualcomm.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>wireless: Reset beacon_found while updating regulatory</title>
<updated>2011-10-03T18:40:40+00:00</updated>
<author>
<name>Rajkumar Manoharan</name>
<email>rmanohar@qca.qualcomm.com</email>
</author>
<published>2011-09-14T08:58:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cb49a34465aff5bb9c5209e2b8e775cead9712c7'/>
<id>cb49a34465aff5bb9c5209e2b8e775cead9712c7</id>
<content type='text'>
commit aa3d7eef398dd4f29045e9889b817d5161afe03e upstream.

During the association, the regulatory is updated by country IE
that reaps the previously found beacons. The impact is that
after a STA disconnects *or* when for any reason a regulatory
domain change happens the beacon hint flag is not cleared
therefore preventing future beacon hints to be learned.
This is important as a regulatory domain change or a restore
of regulatory settings would set back the passive scan and no-ibss
flags on the channel. This is the right place to do this given that
it covers any regulatory domain change.

Reviewed-by: Luis R. Rodriguez &lt;mcgrof@gmail.com&gt;
Signed-off-by: Rajkumar Manoharan &lt;rmanohar@qca.qualcomm.com&gt;
Acked-by: Luis R. Rodriguez &lt;mcgrof@qca.qualcomm.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 aa3d7eef398dd4f29045e9889b817d5161afe03e upstream.

During the association, the regulatory is updated by country IE
that reaps the previously found beacons. The impact is that
after a STA disconnects *or* when for any reason a regulatory
domain change happens the beacon hint flag is not cleared
therefore preventing future beacon hints to be learned.
This is important as a regulatory domain change or a restore
of regulatory settings would set back the passive scan and no-ibss
flags on the channel. This is the right place to do this given that
it covers any regulatory domain change.

Reviewed-by: Luis R. Rodriguez &lt;mcgrof@gmail.com&gt;
Signed-off-by: Rajkumar Manoharan &lt;rmanohar@qca.qualcomm.com&gt;
Acked-by: Luis R. Rodriguez &lt;mcgrof@qca.qualcomm.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>cfg80211: really ignore the regulatory request</title>
<updated>2011-08-05T04:58:41+00:00</updated>
<author>
<name>Sven Neumann</name>
<email>s.neumann@raumfeld.com</email>
</author>
<published>2011-07-12T13:52:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ea530dbfb61aef022d468b597ce13c32da2fb944'/>
<id>ea530dbfb61aef022d468b597ce13c32da2fb944</id>
<content type='text'>
commit a203c2aa4cefccb879c879b8e1cad1a09a679e55 upstream.

At the beginning of wiphy_update_regulatory() a check is performed
whether the request is to be ignored. Then the request is sent to
the driver nevertheless. This happens even if last_request points
to NULL, leading to a crash in the driver:

 [&lt;bf01d864&gt;] (lbs_set_11d_domain_info+0x28/0x1e4 [libertas]) from [&lt;c03b714c&gt;] (wiphy_update_regulatory+0x4d0/0x4f4)
 [&lt;c03b714c&gt;] (wiphy_update_regulatory+0x4d0/0x4f4) from [&lt;c03b4008&gt;] (wiphy_register+0x354/0x420)
 [&lt;c03b4008&gt;] (wiphy_register+0x354/0x420) from [&lt;bf01b17c&gt;] (lbs_cfg_register+0x80/0x164 [libertas])
 [&lt;bf01b17c&gt;] (lbs_cfg_register+0x80/0x164 [libertas]) from [&lt;bf020e64&gt;] (lbs_start_card+0x20/0x88 [libertas])
 [&lt;bf020e64&gt;] (lbs_start_card+0x20/0x88 [libertas]) from [&lt;bf02cbd8&gt;] (if_sdio_probe+0x898/0x9c0 [libertas_sdio])

Fix this by returning early. Also remove the out: label as it is
not any longer needed.

Signed-off-by: Sven Neumann &lt;s.neumann@raumfeld.com&gt;
Cc: linux-wireless@vger.kernel.org
Cc: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Cc: Daniel Mack &lt;daniel@zonque.org&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 a203c2aa4cefccb879c879b8e1cad1a09a679e55 upstream.

At the beginning of wiphy_update_regulatory() a check is performed
whether the request is to be ignored. Then the request is sent to
the driver nevertheless. This happens even if last_request points
to NULL, leading to a crash in the driver:

 [&lt;bf01d864&gt;] (lbs_set_11d_domain_info+0x28/0x1e4 [libertas]) from [&lt;c03b714c&gt;] (wiphy_update_regulatory+0x4d0/0x4f4)
 [&lt;c03b714c&gt;] (wiphy_update_regulatory+0x4d0/0x4f4) from [&lt;c03b4008&gt;] (wiphy_register+0x354/0x420)
 [&lt;c03b4008&gt;] (wiphy_register+0x354/0x420) from [&lt;bf01b17c&gt;] (lbs_cfg_register+0x80/0x164 [libertas])
 [&lt;bf01b17c&gt;] (lbs_cfg_register+0x80/0x164 [libertas]) from [&lt;bf020e64&gt;] (lbs_start_card+0x20/0x88 [libertas])
 [&lt;bf020e64&gt;] (lbs_start_card+0x20/0x88 [libertas]) from [&lt;bf02cbd8&gt;] (if_sdio_probe+0x898/0x9c0 [libertas_sdio])

Fix this by returning early. Also remove the out: label as it is
not any longer needed.

Signed-off-by: Sven Neumann &lt;s.neumann@raumfeld.com&gt;
Cc: linux-wireless@vger.kernel.org
Cc: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Cc: Daniel Mack &lt;daniel@zonque.org&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>cfg80211: fix deadlock with rfkill/sched_scan by adding new mutex</title>
<updated>2011-07-05T18:42:36+00:00</updated>
<author>
<name>Luciano Coelho</name>
<email>coelho@ti.com</email>
</author>
<published>2011-06-30T05:32:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c10841ca722a0bc960dc541c51582773f9a24f98'/>
<id>c10841ca722a0bc960dc541c51582773f9a24f98</id>
<content type='text'>
There was a deadlock when rfkill-blocking a wireless interface,
because we were locking the rdev mutex on NETDEV_GOING_DOWN to stop
sched_scans that were eventually running.  The rfkill block code was
already holding a mutex under rdev:

kernel: =======================================================
kernel: [ INFO: possible circular locking dependency detected ]
kernel: 3.0.0-rc1-00049-g1fa7b6a #57
kernel: -------------------------------------------------------
kernel: kworker/0:1/4525 is trying to acquire lock:
kernel: (&amp;rdev-&gt;mtx){+.+.+.}, at: [&lt;ffffffff8164c831&gt;] cfg80211_netdev_notifier_call+0x131/0x5b0
kernel:
kernel: but task is already holding lock:
kernel: (&amp;rdev-&gt;devlist_mtx){+.+.+.}, at: [&lt;ffffffff8164dcef&gt;] cfg80211_rfkill_set_block+0x4f/0xa0
kernel:
kernel: which lock already depends on the new lock.

To fix this, add a new mutex specifically for sched_scan, to protect
the sched_scan_req element in the rdev struct, instead of using the
global rdev mutex.

Reported-by: Duane Griffin &lt;duaneg@dghda.com&gt;
Signed-off-by: Luciano Coelho &lt;coelho@ti.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>
There was a deadlock when rfkill-blocking a wireless interface,
because we were locking the rdev mutex on NETDEV_GOING_DOWN to stop
sched_scans that were eventually running.  The rfkill block code was
already holding a mutex under rdev:

kernel: =======================================================
kernel: [ INFO: possible circular locking dependency detected ]
kernel: 3.0.0-rc1-00049-g1fa7b6a #57
kernel: -------------------------------------------------------
kernel: kworker/0:1/4525 is trying to acquire lock:
kernel: (&amp;rdev-&gt;mtx){+.+.+.}, at: [&lt;ffffffff8164c831&gt;] cfg80211_netdev_notifier_call+0x131/0x5b0
kernel:
kernel: but task is already holding lock:
kernel: (&amp;rdev-&gt;devlist_mtx){+.+.+.}, at: [&lt;ffffffff8164dcef&gt;] cfg80211_rfkill_set_block+0x4f/0xa0
kernel:
kernel: which lock already depends on the new lock.

To fix this, add a new mutex specifically for sched_scan, to protect
the sched_scan_req element in the rdev struct, instead of using the
global rdev mutex.

Reported-by: Duane Griffin &lt;duaneg@dghda.com&gt;
Signed-off-by: Luciano Coelho &lt;coelho@ti.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix rx-&gt;key NULL dereference during mic failure</title>
<updated>2011-06-27T18:45:25+00:00</updated>
<author>
<name>Arik Nemtsov</name>
<email>arik@wizery.com</email>
</author>
<published>2011-06-22T21:00:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a66b98db570a638afd909459e1e6bfa272344bd3'/>
<id>a66b98db570a638afd909459e1e6bfa272344bd3</id>
<content type='text'>
Sometimes when reporting a MIC failure rx-&gt;key may be unset. This
code path is hit when receiving a packet meant for a multicast
address, and decryption is performed in HW.

Fortunately, the failing key_idx is not used for anything up to
(and including) usermode, so we allow ourselves to drop it on the
way up when a key cannot be retrieved.

Signed-off-by: Arik Nemtsov &lt;arik@wizery.com&gt;
Cc: stable@kernel.org
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Sometimes when reporting a MIC failure rx-&gt;key may be unset. This
code path is hit when receiving a packet meant for a multicast
address, and decryption is performed in HW.

Fortunately, the failing key_idx is not used for anything up to
(and including) usermode, so we allow ourselves to drop it on the
way up when a key cannot be retrieved.

Signed-off-by: Arik Nemtsov &lt;arik@wizery.com&gt;
Cc: stable@kernel.org
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nl80211: fix overflow in ssid_len</title>
<updated>2011-06-07T18:19:07+00:00</updated>
<author>
<name>Luciano Coelho</name>
<email>coelho@ti.com</email>
</author>
<published>2011-06-07T17:42:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=57a27e1d6a3bb9ad4efeebd3a8c71156d6207536'/>
<id>57a27e1d6a3bb9ad4efeebd3a8c71156d6207536</id>
<content type='text'>
When one of the SSID's length passed in a scan or sched_scan request
is larger than 255, there will be an overflow in the u8 that is used
to store the length before checking.  This causes the check to fail
and we overrun the buffer when copying the SSID.

Fix this by checking the nl80211 attribute length before copying it to
the struct.

This is a follow up for the previous commit
208c72f4fe44fe09577e7975ba0e7fa0278f3d03, which didn't fix the problem
entirely.

Reported-by: Ido Yariv &lt;ido@wizery.com&gt;
Signed-off-by: Luciano Coelho &lt;coelho@ti.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 one of the SSID's length passed in a scan or sched_scan request
is larger than 255, there will be an overflow in the u8 that is used
to store the length before checking.  This causes the check to fail
and we overrun the buffer when copying the SSID.

Fix this by checking the nl80211 attribute length before copying it to
the struct.

This is a follow up for the previous commit
208c72f4fe44fe09577e7975ba0e7fa0278f3d03, which didn't fix the problem
entirely.

Reported-by: Ido Yariv &lt;ido@wizery.com&gt;
Signed-off-by: Luciano Coelho &lt;coelho@ti.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cfg80211: don't drop p2p probe responses</title>
<updated>2011-06-01T18:34:01+00:00</updated>
<author>
<name>Eliad Peller</name>
<email>eliad@wizery.com</email>
</author>
<published>2011-05-29T12:53:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=333ba7325213f0a09dfa5ceeddb056d6ad74b3b5'/>
<id>333ba7325213f0a09dfa5ceeddb056d6ad74b3b5</id>
<content type='text'>
Commit 0a35d36 ("cfg80211: Use capability info to detect mesh beacons")
assumed that probe response with both ESS and IBSS bits cleared
means that the frame was sent by a mesh sta.

However, these capabilities are also being used in the p2p_find phase,
and the mesh-validation broke it.

Rename the WLAN_CAPABILITY_IS_MBSS macro, and verify that mesh ies
exist before assuming this frame was sent by a mesh sta.

Signed-off-by: Eliad Peller &lt;eliad@wizery.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>
Commit 0a35d36 ("cfg80211: Use capability info to detect mesh beacons")
assumed that probe response with both ESS and IBSS bits cleared
means that the frame was sent by a mesh sta.

However, these capabilities are also being used in the p2p_find phase,
and the mesh-validation broke it.

Rename the WLAN_CAPABILITY_IS_MBSS macro, and verify that mesh ies
exist before assuming this frame was sent by a mesh sta.

Signed-off-by: Eliad Peller &lt;eliad@wizery.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem</title>
<updated>2011-05-27T19:18:35+00:00</updated>
<author>
<name>John W. Linville</name>
<email>linville@tuxdriver.com</email>
</author>
<published>2011-05-27T19:18:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=11ad2f52826ac6d58d6780d3d8a3e098c88d9142'/>
<id>11ad2f52826ac6d58d6780d3d8a3e098c88d9142</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
</feed>
