linux.git/net/wireless, branch v2.6.36

wext: fix potential private ioctl memory content leak

2010-09-20T17:41:40+00:00

When a driver doesn't fill the entire buffer, old
heap contents may remain, and if it also doesn't
update the length properly, this old heap content
will be copied back to userspace.

It is very unlikely that this happens in any of
the drivers using private ioctls since it would
show up as junk being reported by iwpriv, but it
seems better to be safe here, so use kzalloc.

Reported-by: Jeff Mahoney 
Cc: stable@kernel.org
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

wireless: register wiphy rfkill w/o holding cfg80211_mutex

2010-08-31T18:48:47+00:00

Otherwise lockdep complains...

https://bugzilla.kernel.org/show_bug.cgi?id=17311

[ INFO: possible circular locking dependency detected ]
2.6.36-rc2-git4 #12
-------------------------------------------------------
kworker/0:3/3630 is trying to acquire lock:
 (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x14

but task is already holding lock:
 (rfkill_global_mutex){+.+.+.}, at: []
rfkill_switch_all+0x24/0x49 [rfkill]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (rfkill_global_mutex){+.+.+.}:
       [] lock_acquire+0x120/0x15b
       [] __mutex_lock_common+0x54/0x52e
       [] mutex_lock_nested+0x34/0x39
       [] rfkill_register+0x2b/0x29c [rfkill]
       [] wiphy_register+0x1ae/0x270 [cfg80211]
       [] ieee80211_register_hw+0x1b4/0x3cf [mac80211]
       [] iwl_ucode_callback+0x9e9/0xae3 [iwlagn]
       [] request_firmware_work_func+0x54/0x6f
       [] kthread+0x8c/0x94
       [] kernel_thread_helper+0x4/0x10

-> #1 (cfg80211_mutex){+.+.+.}:
       [] lock_acquire+0x120/0x15b
       [] __mutex_lock_common+0x54/0x52e
       [] mutex_lock_nested+0x34/0x39
       [] cfg80211_get_dev_from_ifindex+0x1b/0x7c [cfg80211]
       [] cfg80211_wext_giwscan+0x58/0x990 [cfg80211]
       [] ioctl_standard_iw_point+0x1a8/0x272
       [] ioctl_standard_call+0x91/0xa7
       [] T.723+0xbd/0x12c
       [] wext_handle_ioctl+0x31/0x6d
       [] dev_ioctl+0x63d/0x67a
       [] sock_ioctl+0x48/0x21d
       [] do_vfs_ioctl+0x4ba/0x509
       [] sys_ioctl+0x51/0x74
       [] system_call_fastpath+0x16/0x1b

-> #0 (rtnl_mutex){+.+.+.}:
       [] __lock_acquire+0xa93/0xd9a
       [] lock_acquire+0x120/0x15b
       [] __mutex_lock_common+0x54/0x52e
       [] mutex_lock_nested+0x34/0x39
       [] rtnl_lock+0x12/0x14
       [] cfg80211_rfkill_set_block+0x1a/0x7b [cfg80211]
       [] rfkill_set_block+0x80/0xd5 [rfkill]
       [] __rfkill_switch_all+0x3f/0x6f [rfkill]
       [] rfkill_switch_all+0x38/0x49 [rfkill]
       [] rfkill_op_handler+0x105/0x136 [rfkill]
       [] process_one_work+0x248/0x403
       [] worker_thread+0x139/0x214
       [] kthread+0x8c/0x94
       [] kernel_thread_helper+0x4/0x10

Signed-off-by: John W. Linville 
Acked-by: Johannes Berg

wireless extensions: fix kernel heap content leak

2010-08-30T20:35:17+00:00

Wireless extensions have an unfortunate, undocumented
requirement which requires drivers to always fill
iwp->length when returning a successful status. When
a driver doesn't do this, it leads to a kernel heap
content leak when userspace offers a larger buffer
than would have been necessary.

Arguably, this is a driver bug, as it should, if it
returns 0, fill iwp->length, even if it separately
indicated that the buffer contents was not valid.

However, we can also at least avoid the memory content
leak if the driver doesn't do this by setting the iwp
length to max_tokens, which then reflects how big the
buffer is that the driver may fill, regardless of how
big the userspace buffer is.

To illustrate the point, this patch also fixes a
corresponding cfg80211 bug (since this requirement
isn't documented nor was ever pointed out by anyone
during code review, I don't trust all drivers nor
all cfg80211 handlers to implement it correctly).

Cc: stable@kernel.org [all the way back]
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: fix locking in action frame TX

2010-08-09T19:18:57+00:00

Accesses to "wdev->current_bss" must be
locked with the wdev lock, which action
frame transmission is missing.

Cc: stable@kernel.org [2.6.33+]
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: Update of regulatory request initiator handling

2010-07-28T20:24:01+00:00

In some cases there could be possible dereferencing freed pointer. The
update is intended to avoid this issue.

Signed-off-by: Yuri Ershov 
Signed-off-by: John W. Linville

nl80211: Fix memory leaks

2010-07-28T20:24:01+00:00

In case of errors during message composing msg should be freed after canceling.

Signed-off-by: Yuri Kululin 
Signed-off-by: Yuri Ershov 
Signed-off-by: John W. Linville

wireless: Convert wiphy_debug macro to function

2010-07-27T19:14:13+00:00

Save a few bytes of text

(allyesconfig)
$ size drivers/net/wireless/built-in.o*
   text	   data	    bss	    dec	    hex	filename
3924568	 100548	 871056	4896172	 4ab5ac	drivers/net/wireless/built-in.o.new
3926520	 100548	 871464	4898532	 4abee4	drivers/net/wireless/built-in.o.old

$ size net/wireless/core.o*
   text	   data	    bss	    dec	    hex	filename
  12843	    216	   3768	  16827	   41bb	net/wireless/core.o.new
  12328	    216	   3656	  16200	   3f48	net/wireless/core.o

Signed-off-by: Joe Perches 
Signed-off-by: John W. Linville

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-next-2.6

2010-07-27T15:59:19+00:00

Conflicts:
	drivers/net/wireless/iwlwifi/iwl-commands.h

cfg80211: fix IBSS default management key

2010-07-26T19:32:41+00:00

When wireless extensions are used to control
an encrypted IBSS, we erroneously can try to
set the default management key. Fix this.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

wireless: remove unneeded variable from regulatory_hint_11d()

2010-07-26T19:32:41+00:00

The "rd" variable isn't needed any more since 4f366c5dabcb
"wireless: only use alpha2 regulatory information from country IE"

Signed-off-by: Dan Carpenter 
Signed-off-by: John W. Linville