linux-stable.git/net/wireless, branch v3.0.7

cfg80211: Fix validation of AKM suites

2011-10-03T18:41:10+00:00

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 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

wireless: Reset beacon_found while updating regulatory

2011-10-03T18:40:40+00:00

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 
Signed-off-by: Rajkumar Manoharan 
Acked-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

cfg80211: really ignore the regulatory request

2011-08-05T04:58:41+00:00

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:

 [] (lbs_set_11d_domain_info+0x28/0x1e4 [libertas]) from [] (wiphy_update_regulatory+0x4d0/0x4f4)
 [] (wiphy_update_regulatory+0x4d0/0x4f4) from [] (wiphy_register+0x354/0x420)
 [] (wiphy_register+0x354/0x420) from [] (lbs_cfg_register+0x80/0x164 [libertas])
 [] (lbs_cfg_register+0x80/0x164 [libertas]) from [] (lbs_start_card+0x20/0x88 [libertas])
 [] (lbs_start_card+0x20/0x88 [libertas]) from [] (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 
Cc: linux-wireless@vger.kernel.org
Cc: Johannes Berg 
Cc: Daniel Mack 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

cfg80211: fix deadlock with rfkill/sched_scan by adding new mutex

2011-07-05T18:42:36+00:00

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: (&rdev->mtx){+.+.+.}, at: [] cfg80211_netdev_notifier_call+0x131/0x5b0
kernel:
kernel: but task is already holding lock:
kernel: (&rdev->devlist_mtx){+.+.+.}, at: [] 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 
Signed-off-by: Luciano Coelho 
Signed-off-by: John W. Linville

mac80211: fix rx->key NULL dereference during mic failure

2011-06-27T18:45:25+00:00

Sometimes when reporting a MIC failure rx->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 
Cc: stable@kernel.org
Signed-off-by: John W. Linville

nl80211: fix overflow in ssid_len

2011-06-07T18:19:07+00:00

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 
Signed-off-by: Luciano Coelho 
Signed-off-by: John W. Linville

cfg80211: don't drop p2p probe responses

2011-06-01T18:34:01+00:00

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 
Signed-off-by: John W. Linville

Merge git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem

2011-05-27T19:18:35+00:00

nl80211: fix check for valid SSID size in scan operations

2011-05-26T19:43:28+00:00

In both trigger_scan and sched_scan operations, we were checking for
the SSID length before assigning the value correctly.  Since the
memory was just kzalloc'ed, the check was always failing and SSID with
over 32 characters were allowed to go through.

This was causing a buffer overflow when copying the actual SSID to the
proper place.

This bug has been there since 2.6.29-rc4.

Cc: stable@kernel.org
Signed-off-by: Luciano Coelho 
Signed-off-by: John W. Linville

Merge ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem

2011-05-24T20:47:54+00:00