kernel.git/net/wireless/wext.c, branch linux-2.6.32.y

wext: fix potential private ioctl memory content leak

2010-10-29T04:44:02Z

commit df6d02300f7c2fbd0fbe626d819c8e5237d72c62 upstream. 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 Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

wireless extensions: fix kernel heap content leak

2010-09-20T20:17:56Z

commit 42da2f948d949efd0111309f5827bf0298bcc9a4 upstream. 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). Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

wext: add back wireless/ dir in sysfs for cfg80211 interfaces

2009-09-28T20:55:07Z

The move away from having drivers assign wireless handlers, in favour of making cfg80211 assign them, broke the sysfs registration (the wireless/ dir went missing) because the handlers are now assigned only after registration, which is too late. Fix this by special-casing cfg80211-based devices, all of which are required to have an ieee80211_ptr, in the sysfs code, and also using get_wireless_stats() to have the same values reported as in procfs. Signed-off-by: Johannes Berg Reported-by: Hugh Dickins Tested-by: Hugh Dickins Signed-off-by: John W. Linville

wext: Add bound checks for copy_from_user

2009-09-28T20:55:06Z

The wireless extensions have a copy_from_user to a local stack array "essid", but both me and gcc have failed to find where the bounds for this copy are located in the code. This patch adds some basic sanity checks for the copy length to make sure that we don't overflow the stack buffer. Signed-off-by: Arjan van de Ven Cc: linux-wireless@vger.kernel.org Signed-off-by: John W. Linville

wext: remove extra return on wireless_nlevent_init()

2009-08-04T20:43:20Z

Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville

net/compat/wext: send different messages to compat tasks

2009-07-15T15:53:39Z

Wireless extensions have the unfortunate problem that events are multicast netlink messages, and are not independent of pointer size. Thus, currently 32-bit tasks on 64-bit platforms cannot properly receive events and fail with all kinds of strange problems, for instance wpa_supplicant never notices disassociations, due to the way the 64-bit event looks (to a 32-bit process), the fact that the address is all zeroes is lost, it thinks instead it is 00:00:00:00:01:00. The same problem existed with the ioctls, until David Miller fixed those some time ago in an heroic effort. A different problem caused by this is that we cannot send the ASSOCREQIE/ASSOCRESPIE events because sending them causes a 32-bit wpa_supplicant on a 64-bit system to overwrite its internal information, which is worse than it not getting the information at all -- so we currently resort to sending a custom string event that it then parses. This, however, has a severe size limitation we are frequently hitting with modern access points; this limitation would can be lifted after this patch by sending the correct binary, not custom, event. A similar problem apparently happens for some other netlink users on x86_64 with 32-bit tasks due to the alignment for 64-bit quantities. In order to fix these problems, I have implemented a way to send compat messages to tasks. When sending an event, we send the non-compat event data together with a compat event data in skb_shinfo(main_skb)->frag_list. Then, when the event is read from the socket, the netlink code makes sure to pass out only the skb that is compatible with the task. This approach was suggested by David Miller, my original approach required always sending two skbs but that had various small problems. To determine whether compat is needed or not, I have used the MSG_CMSG_COMPAT flag, and adjusted the call path for recv and recvfrom to include it, even if those calls do not have a cmsg parameter. I have not solved one small part of the problem, and I don't think it is necessary to: if a 32-bit application uses read() rather than any form of recvmsg() it will still get the wrong (64-bit) event. However, neither do applications actually do this, nor would it be a regression. Signed-off-by: Johannes Berg Signed-off-by: David S. Miller

wext: optimise, comment and fix event sending

2009-07-15T15:53:37Z

The current function for sending events first allocates the event stream buffer, and then an skb to copy the event stream into. This can be done in one go. Also, the current function leaks kernel data to userspace in a 4 uninitialised bytes, initialise those explicitly. Finally also add a few useful comments, as opposed to the current comments. Signed-off-by: Johannes Berg Signed-off-by: David S. Miller

wireless extensions: make netns aware

2009-07-15T15:53:32Z

This makes wireless extensions netns aware. The tasklet sending the events is converted to a work struct so that we can rtnl_lock() in it. Signed-off-by: Johannes Berg Signed-off-by: David S. Miller

wext: constify extra argument to wireless_send_event

2009-07-10T19:01:49Z

This is never changed by the function, so can be marked const. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville

wext: allow returning NULL stats

2009-07-10T19:01:48Z

Currently, wext drivers cannot return NULL for stats even though that would make the ioctl return -EOPNOTSUPP because that would mean they are no longer listed in /proc/net/wireless. This patch changes the wext core's behaviour to list them if they have any wireless_handlers, but only show their stats when available, so that drivers can start returning NULL if stats are currently not available, reducing confusion for e.g. IBSS. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville