All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] fix information leak in wireless extensions on 64-bit  platforms
@ 2007-03-23  9:06 Johannes Berg
  2007-03-23 13:42 ` Johannes Berg
  0 siblings, 1 reply; 18+ messages in thread
From: Johannes Berg @ 2007-03-23  9:06 UTC (permalink / raw)
  To: John W. Linville, stable; +Cc: linux-wireless, Jean Tourrilhes

Wireless extensions on 64-bit platforms leak information from the kernel
stack due to padding in structs that is copied. This affects any
wireless event stream including scan results and so hence is available
to unprivileged users.

This patch is a quick fix for this that simply zeroes out the padding in
the structs before copying them until Jean comes up with the promised
better fix, at which time he can revert this one along with his new
patch.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: Jean Tourrilhes <jt@hpl.hp.com>

---
 include/net/iw_handler.h |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

--- wireless-dev.orig/include/net/iw_handler.h	2007-03-17 20:19:45.369309540 +0100
+++ wireless-dev/include/net/iw_handler.h	2007-03-17 20:19:59.429309540 +0100
@@ -484,6 +484,9 @@ iwe_stream_add_event(char *	stream,		/* 
 		     struct iw_event *iwe,	/* Payload */
 		     int	event_len)	/* Real size of payload */
 {
+	/* clear padding */
+	memset((char*)iwe + 4, 0, IW_EV_LCP_LEN - 4);
+
 	/* Check if it's possible */
 	if(likely((stream + event_len) < ends)) {
 		iwe->len = event_len;
@@ -505,6 +508,10 @@ iwe_stream_add_point(char *	stream,		/* 
 		     char *	extra)		/* More payload */
 {
 	int	event_len = IW_EV_POINT_LEN + iwe->u.data.length;
+
+	/* clear padding */
+	memset((char*)iwe + 4, 0, IW_EV_LCP_LEN - 4);
+
 	/* Check if it's possible */
 	if(likely((stream + event_len) < ends)) {
 		iwe->len = event_len;
@@ -531,6 +538,9 @@ iwe_stream_add_value(char *	event,		/* E
 		     struct iw_event *iwe,	/* Payload */
 		     int	event_len)	/* Real size of payload */
 {
+	/* clear padding */
+	memset((char*)iwe + 4, 0, IW_EV_LCP_LEN - 4);
+
 	/* Don't duplicate LCP */
 	event_len -= IW_EV_LCP_LEN;
 
@@ -558,6 +568,9 @@ iwe_stream_check_add_event(char *	stream
 			   int		event_len,	/* Size of payload */
 			   int *	perr)		/* Error report */
 {
+	/* clear padding */
+	memset((char*)iwe + 4, 0, IW_EV_LCP_LEN - 4);
+
 	/* Check if it's possible, set error if not */
 	if(likely((stream + event_len) < ends)) {
 		iwe->len = event_len;
@@ -582,6 +595,10 @@ iwe_stream_check_add_point(char *	stream
 			   int *	perr)		/* Error report */
 {
 	int	event_len = IW_EV_POINT_LEN + iwe->u.data.length;
+
+	/* clear padding */
+	memset((char*)iwe + 4, 0, IW_EV_LCP_LEN - 4);
+
 	/* Check if it's possible */
 	if(likely((stream + event_len) < ends)) {
 		iwe->len = event_len;
@@ -611,6 +628,9 @@ iwe_stream_check_add_value(char *	event,
 			   int		event_len,	/* Size of payload */
 			   int *	perr)		/* Error report */
 {
+	/* clear padding */
+	memset((char*)iwe + 4, 0, IW_EV_LCP_LEN - 4);
+
 	/* Don't duplicate LCP */
 	event_len -= IW_EV_LCP_LEN;
 



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] fix information leak in wireless extensions on 64-bit  platforms
  2007-03-23  9:06 [PATCH] fix information leak in wireless extensions on 64-bit platforms Johannes Berg
@ 2007-03-23 13:42 ` Johannes Berg
  2007-03-23 15:42   ` John W. Linville
  2007-03-23 15:48   ` Jean Tourrilhes
  0 siblings, 2 replies; 18+ messages in thread
From: Johannes Berg @ 2007-03-23 13:42 UTC (permalink / raw)
  To: John W. Linville; +Cc: stable, linux-wireless, Jean Tourrilhes

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

On Fri, 2007-03-23 at 14:40 +0100, Johannes Berg wrote:
> Wireless extensions on 64-bit platforms leak information from the kernel
> stack due to padding in structs that is copied. This affects any
> wireless event stream including scan results and so hence is available
> to unprivileged users.

Ignore this patch, I see Jean just posted one as well :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] fix information leak in wireless extensions on 64-bit platforms
  2007-03-23 13:42 ` Johannes Berg
@ 2007-03-23 15:42   ` John W. Linville
  2007-03-23 16:24     ` Jean Tourrilhes
  2007-03-23 15:48   ` Jean Tourrilhes
  1 sibling, 1 reply; 18+ messages in thread
From: John W. Linville @ 2007-03-23 15:42 UTC (permalink / raw)
  To: Johannes Berg; +Cc: stable, linux-wireless, Jean Tourrilhes

On Fri, Mar 23, 2007 at 02:42:42PM +0100, Johannes Berg wrote:
> On Fri, 2007-03-23 at 14:40 +0100, Johannes Berg wrote:
> > Wireless extensions on 64-bit platforms leak information from the kernel
> > stack due to padding in structs that is copied. This affects any
> > wireless event stream including scan results and so hence is available
> > to unprivileged users.
> 
> Ignore this patch, I see Jean just posted one as well :)

Hmmm...I seem to have missed it.  Perhaps I was too quick w/ the 'd'
this morning? :-)

Jean, could you bounce me another copy?

Thanks,

John
-- 
John W. Linville
linville@tuxdriver.com

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] fix information leak in wireless extensions on 64-bit platforms
  2007-03-23 13:42 ` Johannes Berg
  2007-03-23 15:42   ` John W. Linville
@ 2007-03-23 15:48   ` Jean Tourrilhes
  2007-03-23 15:56     ` Johannes Berg
  1 sibling, 1 reply; 18+ messages in thread
From: Jean Tourrilhes @ 2007-03-23 15:48 UTC (permalink / raw)
  To: Johannes Berg; +Cc: John W. Linville, stable, linux-wireless

On Fri, Mar 23, 2007 at 02:42:42PM +0100, Johannes Berg wrote:
> On Fri, 2007-03-23 at 14:40 +0100, Johannes Berg wrote:
> > Wireless extensions on 64-bit platforms leak information from the kernel
> > stack due to padding in structs that is copied. This affects any
> > wireless event stream including scan results and so hence is available
> > to unprivileged users.
> 
> Ignore this patch, I see Jean just posted one as well :)
> 
> johannes

	Yes, sorry for the delay, I wanted to make sure I had all the
parts fully fleshed out.
	Thanks !

	Jean


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] fix information leak in wireless extensions on 64-bit  platforms
  2007-03-23 15:48   ` Jean Tourrilhes
@ 2007-03-23 15:56     ` Johannes Berg
  2007-03-23 16:13       ` Jean Tourrilhes
  0 siblings, 1 reply; 18+ messages in thread
From: Johannes Berg @ 2007-03-23 15:56 UTC (permalink / raw)
  To: jt; +Cc: John W. Linville, stable, linux-wireless

[-- Attachment #1: Type: text/plain, Size: 286 bytes --]

On Fri, 2007-03-23 at 08:48 -0700, Jean Tourrilhes wrote:

> 	Yes, sorry for the delay, I wanted to make sure I had all the
> parts fully fleshed out.

:)

Could you maybe send yours to stable too? Both of them I guess. Or do
you want us (John I guess) to do that?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] fix information leak in wireless extensions on 64-bit platforms
  2007-03-23 15:56     ` Johannes Berg
@ 2007-03-23 16:13       ` Jean Tourrilhes
  2007-03-23 16:35         ` [stable] " Greg KH
                           ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: Jean Tourrilhes @ 2007-03-23 16:13 UTC (permalink / raw)
  To: Johannes Berg; +Cc: John W. Linville, stable, linux-wireless

On Fri, Mar 23, 2007 at 04:56:24PM +0100, Johannes Berg wrote:
> On Fri, 2007-03-23 at 08:48 -0700, Jean Tourrilhes wrote:
> 
> > 	Yes, sorry for the delay, I wanted to make sure I had all the
> > parts fully fleshed out.
> 
> :)
> 
> Could you maybe send yours to stable too? Both of them I guess. Or do
> you want us (John I guess) to do that?
> 
> johannes

	It seems that the lifetime of each stable branch is measured
in weeks (apart from 2.6.16), and being an old timer, gaining a few
weeks does not seem to me to be worth the trouble. It's not like the
bug is entirely new.
	I'm personally more concerned about distro. If getting it into
stable would make it go into a distro release, then I would see more
value. It seems that it's too late for the next release of Debian or
Fedora, and I don't know if any distro is going to be based on this
stable branch.
	The last thing is that I could not test those stuff myself,
and the testing done for me was limited. I would be more confident if
you were to give it a good beating before we push that into stable,
because you know what to test.
	Those are only my opinions. John is the man, so I let him
decide. John, if you feel like pushing it, please do it.

	Have fun...

	Jean

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] fix information leak in wireless extensions on 64-bit platforms
  2007-03-23 15:42   ` John W. Linville
@ 2007-03-23 16:24     ` Jean Tourrilhes
  0 siblings, 0 replies; 18+ messages in thread
From: Jean Tourrilhes @ 2007-03-23 16:24 UTC (permalink / raw)
  To: John W. Linville; +Cc: Johannes Berg, linux-wireless

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]

On Fri, Mar 23, 2007 at 11:42:37AM -0400, John W. Linville wrote:
> On Fri, Mar 23, 2007 at 02:42:42PM +0100, Johannes Berg wrote:
> > On Fri, 2007-03-23 at 14:40 +0100, Johannes Berg wrote:
> > > Wireless extensions on 64-bit platforms leak information from the kernel
> > > stack due to padding in structs that is copied. This affects any
> > > wireless event stream including scan results and so hence is available
> > > to unprivileged users.
> > 
> > Ignore this patch, I see Jean just posted one as well :)
> 
> Hmmm...I seem to have missed it.  Perhaps I was too quick w/ the 'd'
> this morning? :-)

	You too are getting far too much spam ?

> Jean, could you bounce me another copy?

	No problem. Original e-mails here, patches attached :
		http://marc.info/?l=linux-netdev&m=117460953806538&w=2
		http://marc.info/?l=linux-netdev&m=117460988706771&w=2
	Note that you decide if you want this in stable as well...

> Thanks,
> 
> John

	Have fun...

	Jean

[-- Attachment #2: iw261_wpa_compat_ioctl.diff --]
[-- Type: text/plain, Size: 1504 bytes --]

diff -u -p linux/fs/compat_ioctl.j1.c  linux/fs/compat_ioctl.c
--- linux/fs/compat_ioctl.j1.c	2007-03-06 17:49:33.000000000 -0800
+++ linux/fs/compat_ioctl.c	2007-03-06 17:56:19.000000000 -0800
@@ -2553,11 +2553,15 @@ HANDLE_IOCTL(I2C_RDWR, do_i2c_rdwr_ioctl
 HANDLE_IOCTL(I2C_SMBUS, do_i2c_smbus_ioctl)
 /* wireless */
 HANDLE_IOCTL(SIOCGIWRANGE, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCGIWPRIV, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCGIWSTATS, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCSIWSPY, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCGIWSPY, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCSIWTHRSPY, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCGIWTHRSPY, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCSIWMLME, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCGIWAPLIST, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCSIWSCAN, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCGIWSCAN, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCSIWESSID, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCGIWESSID, do_wireless_ioctl)
@@ -2565,6 +2569,11 @@ HANDLE_IOCTL(SIOCSIWNICKN, do_wireless_i
 HANDLE_IOCTL(SIOCGIWNICKN, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCSIWENCODE, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCGIWENCODE, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCSIWGENIE, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCGIWGENIE, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCSIWENCODEEXT, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCGIWENCODEEXT, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCSIWPMKSA, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCSIFBR, old_bridge_ioctl)
 HANDLE_IOCTL(SIOCGIFBR, old_bridge_ioctl)
 HANDLE_IOCTL(RTC_IRQP_READ32, rtc_ioctl)

[-- Attachment #3: iw261_we22_64bit_usp_leak-3.diff --]
[-- Type: text/plain, Size: 15111 bytes --]

diff -u -p linux/include/linux/wireless.j1.h linux/include/linux/wireless.h
--- linux/include/linux/wireless.j1.h	2007-03-08 10:34:32.000000000 -0800
+++ linux/include/linux/wireless.h	2007-03-21 11:01:14.000000000 -0700
@@ -1,10 +1,10 @@
 /*
  * This file define a set of standard wireless extensions
  *
- * Version :	21	14.3.06
+ * Version :	22	16.3.07
  *
  * Authors :	Jean Tourrilhes - HPL - <jt@hpl.hp.com>
- * Copyright (c) 1997-2006 Jean Tourrilhes, All Rights Reserved.
+ * Copyright (c) 1997-2007 Jean Tourrilhes, All Rights Reserved.
  */
 
 #ifndef _LINUX_WIRELESS_H
@@ -85,7 +85,7 @@
  * (there is some stuff that will be added in the future...)
  * I just plan to increment with each new version.
  */
-#define WIRELESS_EXT	21
+#define WIRELESS_EXT	22
 
 /*
  * Changes :
@@ -221,6 +221,10 @@
  *	- Add IW_RETRY_SHORT/IW_RETRY_LONG retry modifiers
  *	- Power/Retry relative values no longer * 100000
  *	- Add explicit flag to tell stats are in 802.11k RCPI : IW_QUAL_RCPI
+ *
+ * V21 to V22
+ * ----------
+ *	- Prevent leaking of kernel space in stream on 64 bits.
  */
 
 /**************************** CONSTANTS ****************************/
@@ -1085,4 +1089,15 @@ struct iw_event
 #define IW_EV_POINT_LEN	(IW_EV_LCP_LEN + sizeof(struct iw_point) - \
 			 IW_EV_POINT_OFF)
 
+/* Size of the Event prefix when packed in stream */
+#define IW_EV_LCP_PK_LEN	(4)
+/* Size of the various events when packed in stream */
+#define IW_EV_CHAR_PK_LEN	(IW_EV_LCP_PK_LEN + IFNAMSIZ)
+#define IW_EV_UINT_PK_LEN	(IW_EV_LCP_PK_LEN + sizeof(__u32))
+#define IW_EV_FREQ_PK_LEN	(IW_EV_LCP_PK_LEN + sizeof(struct iw_freq))
+#define IW_EV_PARAM_PK_LEN	(IW_EV_LCP_PK_LEN + sizeof(struct iw_param))
+#define IW_EV_ADDR_PK_LEN	(IW_EV_LCP_PK_LEN + sizeof(struct sockaddr))
+#define IW_EV_QUAL_PK_LEN	(IW_EV_LCP_PK_LEN + sizeof(struct iw_quality))
+#define IW_EV_POINT_PK_LEN	(IW_EV_LCP_LEN + 4)
+
 #endif	/* _LINUX_WIRELESS_H */
diff -u -p linux/include/net/iw_handler.j1.h linux/include/net/iw_handler.h
--- linux/include/net/iw_handler.j1.h	2007-03-16 17:36:22.000000000 -0700
+++ linux/include/net/iw_handler.h	2007-03-21 11:01:09.000000000 -0700
@@ -1,10 +1,10 @@
 /*
  * This file define the new driver API for Wireless Extensions
  *
- * Version :	7	18.3.05
+ * Version :	8	16.3.07
  *
  * Authors :	Jean Tourrilhes - HPL - <jt@hpl.hp.com>
- * Copyright (c) 2001-2006 Jean Tourrilhes, All Rights Reserved.
+ * Copyright (c) 2001-2007 Jean Tourrilhes, All Rights Reserved.
  */
 
 #ifndef _IW_HANDLER_H
@@ -207,7 +207,7 @@
  * will be needed...
  * I just plan to increment with each new version.
  */
-#define IW_HANDLER_VERSION	7
+#define IW_HANDLER_VERSION	8
 
 /*
  * Changes :
@@ -239,6 +239,10 @@
  *	- Remove (struct iw_point *)->pointer from events and streams
  *	- Remove spy_offset from struct iw_handler_def
  *	- Add "check" version of event macros for ieee802.11 stack
+ *
+ * V7 to V8
+ * ----------
+ *	- Prevent leaking of kernel space in stream on 64 bits.
  */
 
 /**************************** CONSTANTS ****************************/
@@ -500,7 +504,11 @@ iwe_stream_add_event(char *	stream,		/* 
 	/* Check if it's possible */
 	if(likely((stream + event_len) < ends)) {
 		iwe->len = event_len;
-		memcpy(stream, (char *) iwe, event_len);
+		/* Beware of alignement issues on 64 bits */
+		memcpy(stream, (char *) iwe, IW_EV_LCP_PK_LEN);
+		memcpy(stream + IW_EV_LCP_LEN,
+		       ((char *) iwe) + IW_EV_LCP_LEN,
+		       event_len - IW_EV_LCP_LEN);
 		stream += event_len;
 	}
 	return stream;
@@ -521,10 +529,10 @@ iwe_stream_add_point(char *	stream,		/* 
 	/* Check if it's possible */
 	if(likely((stream + event_len) < ends)) {
 		iwe->len = event_len;
-		memcpy(stream, (char *) iwe, IW_EV_LCP_LEN);
+		memcpy(stream, (char *) iwe, IW_EV_LCP_PK_LEN);
 		memcpy(stream + IW_EV_LCP_LEN,
 		       ((char *) iwe) + IW_EV_LCP_LEN + IW_EV_POINT_OFF,
-		       IW_EV_POINT_LEN - IW_EV_LCP_LEN);
+		       IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
 		memcpy(stream + IW_EV_POINT_LEN, extra, iwe->u.data.length);
 		stream += event_len;
 	}
@@ -574,7 +582,11 @@ iwe_stream_check_add_event(char *	stream
 	/* Check if it's possible, set error if not */
 	if(likely((stream + event_len) < ends)) {
 		iwe->len = event_len;
-		memcpy(stream, (char *) iwe, event_len);
+		/* Beware of alignement issues on 64 bits */
+		memcpy(stream, (char *) iwe, IW_EV_LCP_PK_LEN);
+		memcpy(stream + IW_EV_LCP_LEN,
+		       ((char *) iwe) + IW_EV_LCP_LEN,
+		       event_len - IW_EV_LCP_LEN);
 		stream += event_len;
 	} else
 		*perr = -E2BIG;
@@ -598,10 +610,10 @@ iwe_stream_check_add_point(char *	stream
 	/* Check if it's possible */
 	if(likely((stream + event_len) < ends)) {
 		iwe->len = event_len;
-		memcpy(stream, (char *) iwe, IW_EV_LCP_LEN);
+		memcpy(stream, (char *) iwe, IW_EV_LCP_PK_LEN);
 		memcpy(stream + IW_EV_LCP_LEN,
 		       ((char *) iwe) + IW_EV_LCP_LEN + IW_EV_POINT_OFF,
-		       IW_EV_POINT_LEN - IW_EV_LCP_LEN);
+		       IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
 		memcpy(stream + IW_EV_POINT_LEN, extra, iwe->u.data.length);
 		stream += event_len;
 	} else
diff -u -p linux/net/core/rtnetlink.j1.c linux/net/core/rtnetlink.c
--- linux/net/core/rtnetlink.j1.c	2007-03-21 10:59:07.000000000 -0700
+++ linux/net/core/rtnetlink.c	2007-03-21 11:00:27.000000000 -0700
@@ -621,7 +621,8 @@ static int rtnl_getlink(struct sk_buff *
 		if (err < 0)
 			goto errout;
 
-		iw += IW_EV_POINT_OFF;
+		/* Payload is at an offset in buffer */
+		iw = iw_buf + IW_EV_POINT_OFF;
 	}
 #endif	/* CONFIG_NET_WIRELESS_RTNETLINK */
 
diff -u -p linux/net/core/wireless.j1.c linux/net/core/wireless.c
--- linux/net/core/wireless.j1.c	2007-03-08 14:20:22.000000000 -0800
+++ linux/net/core/wireless.c	2007-03-16 18:29:33.000000000 -0700
@@ -2,7 +2,7 @@
  * This file implement the Wireless Extensions APIs.
  *
  * Authors :	Jean Tourrilhes - HPL - <jt@hpl.hp.com>
- * Copyright (c) 1997-2006 Jean Tourrilhes, All Rights Reserved.
+ * Copyright (c) 1997-2007 Jean Tourrilhes, All Rights Reserved.
  *
  * (As all part of the Linux kernel, this file is GPL)
  */
@@ -76,6 +76,9 @@
  *	o Change length in ESSID and NICK to strlen() instead of strlen()+1
  *	o Make standard_ioctl_num and standard_event_num unsigned
  *	o Remove (struct net_device *)->get_wireless_stats()
+ *
+ * v10 - 16.3.07 - Jean II
+ *	o Prevent leaking of kernel space in stream on 64 bits.
  */
 
 /***************************** INCLUDES *****************************/
@@ -427,6 +430,21 @@ static const int event_type_size[] = {
 	IW_EV_QUAL_LEN,			/* IW_HEADER_TYPE_QUAL */
 };
 
+/* Size (in bytes) of various events, as packed */
+static const int event_type_pk_size[] = {
+	IW_EV_LCP_PK_LEN,		/* IW_HEADER_TYPE_NULL */
+	0,
+	IW_EV_CHAR_PK_LEN,		/* IW_HEADER_TYPE_CHAR */
+	0,
+	IW_EV_UINT_PK_LEN,		/* IW_HEADER_TYPE_UINT */
+	IW_EV_FREQ_PK_LEN,		/* IW_HEADER_TYPE_FREQ */
+	IW_EV_ADDR_PK_LEN,		/* IW_HEADER_TYPE_ADDR */
+	0,
+	IW_EV_POINT_PK_LEN,		/* Without variable payload */
+	IW_EV_PARAM_PK_LEN,		/* IW_HEADER_TYPE_PARAM */
+	IW_EV_QUAL_PK_LEN,		/* IW_HEADER_TYPE_QUAL */
+};
+
 /************************ COMMON SUBROUTINES ************************/
 /*
  * Stuff that may be used in various place or doesn't fit in one
@@ -1217,7 +1235,7 @@ static int rtnetlink_standard_get(struct
 		memcpy(buffer + IW_EV_POINT_OFF, request, request_len);
 		/* Use our own copy of wrqu */
 		wrqu = (union iwreq_data *) (buffer + IW_EV_POINT_OFF
-					     + IW_EV_LCP_LEN);
+					     + IW_EV_LCP_PK_LEN);
 
 		/* No extra arguments. Trivial to handle */
 		ret = handler(dev, &info, wrqu, NULL);
@@ -1229,8 +1247,8 @@ static int rtnetlink_standard_get(struct
 
 		/* Get a temp copy of wrqu (skip pointer) */
 		memcpy(((char *) &wrqu_point) + IW_EV_POINT_OFF,
-		       ((char *) request) + IW_EV_LCP_LEN,
-		       IW_EV_POINT_LEN - IW_EV_LCP_LEN);
+		       ((char *) request) + IW_EV_LCP_PK_LEN,
+		       IW_EV_POINT_LEN - IW_EV_LCP_PK_LEN);
 
 		/* Calculate space needed by arguments. Always allocate
 		 * for max space. Easier, and won't last long... */
@@ -1240,7 +1258,7 @@ static int rtnetlink_standard_get(struct
 		   (wrqu_point.data.length > descr->max_tokens))
 			extra_size = (wrqu_point.data.length
 				      * descr->token_size);
-		buffer_size = extra_size + IW_EV_POINT_LEN + IW_EV_POINT_OFF;
+		buffer_size = extra_size + IW_EV_POINT_PK_LEN + IW_EV_POINT_OFF;
 #ifdef WE_RTNETLINK_DEBUG
 		printk(KERN_DEBUG "%s (WE.r) : Malloc %d bytes (%d bytes)\n",
 		       dev->name, extra_size, buffer_size);
@@ -1254,15 +1272,15 @@ static int rtnetlink_standard_get(struct
 
 		/* Put wrqu in the right place (just before extra).
 		 * Leave space for IWE header and dummy pointer...
-		 * Note that IW_EV_LCP_LEN==4 bytes, so it's still aligned...
+		 * Note that IW_EV_LCP_PK_LEN==4 bytes, so it's still aligned.
 		 */
-		memcpy(buffer + IW_EV_LCP_LEN + IW_EV_POINT_OFF,
+		memcpy(buffer + IW_EV_LCP_PK_LEN + IW_EV_POINT_OFF,
 		       ((char *) &wrqu_point) + IW_EV_POINT_OFF,
-		       IW_EV_POINT_LEN - IW_EV_LCP_LEN);
-		wrqu = (union iwreq_data *) (buffer + IW_EV_LCP_LEN);
+		       IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
+		wrqu = (union iwreq_data *) (buffer + IW_EV_LCP_PK_LEN);
 
 		/* Extra comes logically after that. Offset +12 bytes. */
-		extra = buffer + IW_EV_POINT_OFF + IW_EV_POINT_LEN;
+		extra = buffer + IW_EV_POINT_OFF + IW_EV_POINT_PK_LEN;
 
 		/* Call the handler */
 		ret = handler(dev, &info, wrqu, extra);
@@ -1270,11 +1288,11 @@ static int rtnetlink_standard_get(struct
 		/* Calculate real returned length */
 		extra_size = (wrqu->data.length * descr->token_size);
 		/* Re-adjust reply size */
-		request->len = extra_size + IW_EV_POINT_LEN;
+		request->len = extra_size + IW_EV_POINT_PK_LEN;
 
 		/* Put the iwe header where it should, i.e. scrap the
 		 * dummy pointer. */
-		memcpy(buffer + IW_EV_POINT_OFF, request, IW_EV_LCP_LEN);
+		memcpy(buffer + IW_EV_POINT_OFF, request, IW_EV_LCP_PK_LEN);
 
 #ifdef WE_RTNETLINK_DEBUG
 		printk(KERN_DEBUG "%s (WE.r) : Reply 0x%04X, hdr_len %d, tokens %d, extra_size %d, buffer_size %d\n", dev->name, cmd, hdr_len, wrqu->data.length, extra_size, buffer_size);
@@ -1331,10 +1349,10 @@ static inline int rtnetlink_standard_set
 #endif	/* WE_RTNETLINK_DEBUG */
 
 	/* Extract fixed header from request. This is properly aligned. */
-	wrqu = &request->u;
+	wrqu = (union iwreq_data *) (((char *) request) + IW_EV_LCP_PK_LEN);
 
 	/* Check if wrqu is complete */
-	hdr_len = event_type_size[descr->header_type];
+	hdr_len = event_type_pk_size[descr->header_type];
 	if(request_len < hdr_len) {
 #ifdef WE_RTNETLINK_DEBUG
 		printk(KERN_DEBUG
@@ -1359,7 +1377,7 @@ static inline int rtnetlink_standard_set
 
 		/* Put wrqu in the right place (skip pointer) */
 		memcpy(((char *) &wrqu_point) + IW_EV_POINT_OFF,
-		       wrqu, IW_EV_POINT_LEN - IW_EV_LCP_LEN);
+		       wrqu, IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
 		/* Don't forget about the event code... */
 		wrqu = &wrqu_point;
 
@@ -1483,7 +1501,7 @@ static inline int rtnetlink_private_get(
 		hdr_len = extra_size;
 		extra_size = 0;
 	} else {
-		hdr_len = IW_EV_POINT_LEN;
+		hdr_len = IW_EV_POINT_PK_LEN;
 	}
 
 	/* Check if wrqu is complete */
@@ -1514,7 +1532,7 @@ static inline int rtnetlink_private_get(
 		memcpy(buffer + IW_EV_POINT_OFF, request, request_len);
 		/* Use our own copy of wrqu */
 		wrqu = (union iwreq_data *) (buffer + IW_EV_POINT_OFF
-					     + IW_EV_LCP_LEN);
+					     + IW_EV_LCP_PK_LEN);
 
 		/* No extra arguments. Trivial to handle */
 		ret = handler(dev, &info, wrqu, (char *) wrqu);
@@ -1523,7 +1541,7 @@ static inline int rtnetlink_private_get(
 		char *	extra;
 
 		/* Buffer for full reply */
-		buffer_size = extra_size + IW_EV_POINT_LEN + IW_EV_POINT_OFF;
+		buffer_size = extra_size + IW_EV_POINT_PK_LEN + IW_EV_POINT_OFF;
 
 #ifdef WE_RTNETLINK_DEBUG
 		printk(KERN_DEBUG "%s (WE.r) : Malloc %d bytes (%d bytes)\n",
@@ -1538,15 +1556,15 @@ static inline int rtnetlink_private_get(
 
 		/* Put wrqu in the right place (just before extra).
 		 * Leave space for IWE header and dummy pointer...
-		 * Note that IW_EV_LCP_LEN==4 bytes, so it's still aligned...
+		 * Note that IW_EV_LCP_PK_LEN==4 bytes, so it's still aligned.
 		 */
-		memcpy(buffer + IW_EV_LCP_LEN + IW_EV_POINT_OFF,
-		       ((char *) request) + IW_EV_LCP_LEN,
-		       IW_EV_POINT_LEN - IW_EV_LCP_LEN);
-		wrqu = (union iwreq_data *) (buffer + IW_EV_LCP_LEN);
+		memcpy(buffer + IW_EV_LCP_PK_LEN + IW_EV_POINT_OFF,
+		       ((char *) request) + IW_EV_LCP_PK_LEN,
+		       IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
+		wrqu = (union iwreq_data *) (buffer + IW_EV_LCP_PK_LEN);
 
 		/* Extra comes logically after that. Offset +12 bytes. */
-		extra = buffer + IW_EV_POINT_OFF + IW_EV_POINT_LEN;
+		extra = buffer + IW_EV_POINT_OFF + IW_EV_POINT_PK_LEN;
 
 		/* Call the handler */
 		ret = handler(dev, &info, wrqu, extra);
@@ -1556,11 +1574,11 @@ static inline int rtnetlink_private_get(
 		if (!(descr->get_args & IW_PRIV_SIZE_FIXED))
 			extra_size = adjust_priv_size(descr->get_args, wrqu);
 		/* Re-adjust reply size */
-		request->len = extra_size + IW_EV_POINT_LEN;
+		request->len = extra_size + IW_EV_POINT_PK_LEN;
 
 		/* Put the iwe header where it should, i.e. scrap the
 		 * dummy pointer. */
-		memcpy(buffer + IW_EV_POINT_OFF, request, IW_EV_LCP_LEN);
+		memcpy(buffer + IW_EV_POINT_OFF, request, IW_EV_LCP_PK_LEN);
 
 #ifdef WE_RTNETLINK_DEBUG
 		printk(KERN_DEBUG "%s (WE.r) : Reply 0x%04X, hdr_len %d, tokens %d, extra_size %d, buffer_size %d\n", dev->name, cmd, hdr_len, wrqu->data.length, extra_size, buffer_size);
@@ -1641,14 +1659,14 @@ static inline int rtnetlink_private_set(
 	/* Does it fits in wrqu ? */
 	if((descr->set_args & IW_PRIV_SIZE_FIXED) &&
 	   (extra_size <= IFNAMSIZ)) {
-		hdr_len = IW_EV_LCP_LEN + extra_size;
+		hdr_len = IW_EV_LCP_PK_LEN + extra_size;
 		extra_size = 0;
 	} else {
-		hdr_len = IW_EV_POINT_LEN;
+		hdr_len = IW_EV_POINT_PK_LEN;
 	}
 
 	/* Extract fixed header from request. This is properly aligned. */
-	wrqu = &request->u;
+	wrqu = (union iwreq_data *) (((char *) request) + IW_EV_LCP_PK_LEN);
 
 	/* Check if wrqu is complete */
 	if(request_len < hdr_len) {
@@ -1675,7 +1693,7 @@ static inline int rtnetlink_private_set(
 
 		/* Put wrqu in the right place (skip pointer) */
 		memcpy(((char *) &wrqu_point) + IW_EV_POINT_OFF,
-		       wrqu, IW_EV_POINT_LEN - IW_EV_LCP_LEN);
+		       wrqu, IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
 
 		/* Does it fits within bounds ? */
 		if(wrqu_point.data.length > (descr->set_args &
@@ -1738,7 +1756,7 @@ int wireless_rtnetlink_get(struct net_de
 	iw_handler		handler;
 
 	/* Check length */
-	if(len < IW_EV_LCP_LEN) {
+	if(len < IW_EV_LCP_PK_LEN) {
 		printk(KERN_DEBUG "%s (WE.r) : RtNetlink request too short (%d)\n",
 		       dev->name, len);
 		return -EINVAL;
@@ -1822,7 +1840,7 @@ int wireless_rtnetlink_set(struct net_de
 	iw_handler		handler;
 
 	/* Check length */
-	if(len < IW_EV_LCP_LEN) {
+	if(len < IW_EV_LCP_PK_LEN) {
 		printk(KERN_DEBUG "%s (WE.r) : RtNetlink request too short (%d)\n",
 		       dev->name, len);
 		return -EINVAL;

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [stable] [PATCH] fix information leak in wireless extensions on 64-bit platforms
  2007-03-23 16:13       ` Jean Tourrilhes
@ 2007-03-23 16:35         ` Greg KH
  2007-03-23 16:53         ` Michael Buesch
  2007-03-23 19:36         ` [stable] " Chris Wright
  2 siblings, 0 replies; 18+ messages in thread
From: Greg KH @ 2007-03-23 16:35 UTC (permalink / raw)
  To: Jean Tourrilhes; +Cc: Johannes Berg, linux-wireless, John W. Linville, stable

On Fri, Mar 23, 2007 at 09:13:39AM -0700, Jean Tourrilhes wrote:
> On Fri, Mar 23, 2007 at 04:56:24PM +0100, Johannes Berg wrote:
> > On Fri, 2007-03-23 at 08:48 -0700, Jean Tourrilhes wrote:
> > 
> > > 	Yes, sorry for the delay, I wanted to make sure I had all the
> > > parts fully fleshed out.
> > 
> > :)
> > 
> > Could you maybe send yours to stable too? Both of them I guess. Or do
> > you want us (John I guess) to do that?
> > 
> > johannes
> 
> 	It seems that the lifetime of each stable branch is measured
> in weeks (apart from 2.6.16), and being an old timer, gaining a few
> weeks does not seem to me to be worth the trouble. It's not like the
> bug is entirely new.
> 	I'm personally more concerned about distro. If getting it into
> stable would make it go into a distro release, then I would see more
> value. It seems that it's too late for the next release of Debian or
> Fedora, and I don't know if any distro is going to be based on this
> stable branch.

Lots of distros watch the stable branches to see what they need to pick
up for their kernel releases.

So please don't just ignore them, lots of people depend on them, even
outside of the distros.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] fix information leak in wireless extensions on 64-bit platforms
  2007-03-23 16:13       ` Jean Tourrilhes
  2007-03-23 16:35         ` [stable] " Greg KH
@ 2007-03-23 16:53         ` Michael Buesch
  2007-03-23 17:57           ` Jean Tourrilhes
  2007-03-23 19:36         ` [stable] " Chris Wright
  2 siblings, 1 reply; 18+ messages in thread
From: Michael Buesch @ 2007-03-23 16:53 UTC (permalink / raw)
  To: jt; +Cc: Johannes Berg, John W. Linville, stable, linux-wireless

On Friday 23 March 2007 17:13, Jean Tourrilhes wrote:
> value. It seems that it's too late for the next release of Debian or
> Fedora,

Wtf? It's too late for a security fix?
How can it be too late for a security fix?

-- 
Greetings Michael.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] fix information leak in wireless extensions on 64-bit platforms
  2007-03-23 16:53         ` Michael Buesch
@ 2007-03-23 17:57           ` Jean Tourrilhes
  0 siblings, 0 replies; 18+ messages in thread
From: Jean Tourrilhes @ 2007-03-23 17:57 UTC (permalink / raw)
  To: Michael Buesch; +Cc: Johannes Berg, John W. Linville, stable, linux-wireless

On Fri, Mar 23, 2007 at 05:53:31PM +0100, Michael Buesch wrote:
> On Friday 23 March 2007 17:13, Jean Tourrilhes wrote:
> > value. It seems that it's too late for the next release of Debian or
> > Fedora,
> 
> Wtf? It's too late for a security fix?
> How can it be too late for a security fix?

	Note that I was making a prediction. We'll see if I'm right.

	Let's not make blanket statements like this about security,
security is all about level of risk, there are various level of
"security issues" and you need to assign the proper level to this one.
	One one hand of the scale you have issues that allow remote
penetration. Those require immediate attention.
	On the other end of the scale you have random information
leaks. Those are clearly important, but clearly not in the same
category. They don't allow remote penetration. They don't allow
priviledge escalation. They don't allow denial of service. The 4 bytes
leaked are comming from mostly random allocated buffers. The potential
of exploitation is very limited.

	Both the Debian release and Fedora release are well into their
respective freeze. In particular, the Debian kernel is frozen and
won't change until release. With the amount of issues and open bugs
those kernel packagers have, everything is prioritised, and many
things in their queue tend to be ignored.
	The priority those maintainers will assign to this issue will
mostly go along the lines outlined above. Risk of changes and
potential regression versus risk of attack.
	This is why I made this prediction.

> Greetings Michael.

	Jean

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [stable] [PATCH] fix information leak in wireless extensions on 64-bit platforms
  2007-03-23 16:13       ` Jean Tourrilhes
  2007-03-23 16:35         ` [stable] " Greg KH
  2007-03-23 16:53         ` Michael Buesch
@ 2007-03-23 19:36         ` Chris Wright
  2007-03-23 20:00           ` Jean Tourrilhes
  2 siblings, 1 reply; 18+ messages in thread
From: Chris Wright @ 2007-03-23 19:36 UTC (permalink / raw)
  To: Jean Tourrilhes; +Cc: Johannes Berg, linux-wireless, John W. Linville, stable

* Jean Tourrilhes (jt@hpl.hp.com) wrote:
> 	It seems that the lifetime of each stable branch is measured
> in weeks (apart from 2.6.16),

That's not accurate (apart from the fact that months are made of weeks ;-)

~2.5 months
2.6.15.1  Jan 15  2006
2.6.15.7  Mar 28  2006

[skipping 2.6.16 since it's still going]

~2 months
2.6.17.1  Aug 22  2006
2.6.17.14 Oct 13  2006

~3 months
2.6.18.1  Oct 14 2006
2.6.18.8  Feb 23 2007

~3 months
2.6.19.1  Dec 11 2006
2.6.19.7  Mar  3 2007

And to reiterate the sentiments of others.  Security relevant bugs are
always of interest to the stable team as well as distros.

> 	The last thing is that I could not test those stuff myself,
> and the testing done for me was limited. I would be more confident if
> you were to give it a good beating before we push that into stable,
> because you know what to test.

That's useful info.  Have you had any luck (it looks pretty straight
forward)?

thanks,
-chris

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [stable] [PATCH] fix information leak in wireless extensions on 64-bit platforms
  2007-03-23 19:36         ` [stable] " Chris Wright
@ 2007-03-23 20:00           ` Jean Tourrilhes
  2007-03-23 20:05             ` Johannes Berg
  2007-03-23 20:27             ` Michael Buesch
  0 siblings, 2 replies; 18+ messages in thread
From: Jean Tourrilhes @ 2007-03-23 20:00 UTC (permalink / raw)
  To: Chris Wright; +Cc: Johannes Berg, linux-wireless, John W. Linville, stable

On Fri, Mar 23, 2007 at 12:36:43PM -0700, Chris Wright wrote:
> * Jean Tourrilhes (jt@hpl.hp.com) wrote:
> 
> > 	The last thing is that I could not test those stuff myself,
> > and the testing done for me was limited. I would be more confident if
> > you were to give it a good beating before we push that into stable,
> > because you know what to test.
> 
> That's useful info.  Have you had any luck (it looks pretty straight
> forward)?

	Let's be more clear. I tested properly on 32 bits. But, 32
bits is not where there is issue, this issue is specific to 64 bits. I
don't have a 64 bits platfor. It seems that few people doing wireless
have access to 64 bits platform (actually, it seems most of them don't
have access to SMP either), otherwise this would have been found many
years ago.
	Johannes is one of the few having access to 64 bits stuff.

> thanks,
> -chris

	Have fun...

	Jean

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [stable] [PATCH] fix information leak in wireless extensions  on 64-bit platforms
  2007-03-23 20:00           ` Jean Tourrilhes
@ 2007-03-23 20:05             ` Johannes Berg
  2007-03-23 20:27             ` Michael Buesch
  1 sibling, 0 replies; 18+ messages in thread
From: Johannes Berg @ 2007-03-23 20:05 UTC (permalink / raw)
  To: jt; +Cc: Chris Wright, linux-wireless, John W. Linville, stable

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

On Fri, 2007-03-23 at 13:00 -0700, Jean Tourrilhes wrote:

> 	Let's be more clear. I tested properly on 32 bits. But, 32
> bits is not where there is issue, this issue is specific to 64 bits. I
> don't have a 64 bits platfor. It seems that few people doing wireless
> have access to 64 bits platform (actually, it seems most of them don't
> have access to SMP either), otherwise this would have been found many
> years ago.
> 	Johannes is one of the few having access to 64 bits stuff.

Few, heh. I'll give it a try next week. (actually, I don't have wireless
on the 64-bit quad powermac but I can always plug in USB things)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [stable] [PATCH] fix information leak in wireless extensions on 64-bit platforms
  2007-03-23 20:00           ` Jean Tourrilhes
  2007-03-23 20:05             ` Johannes Berg
@ 2007-03-23 20:27             ` Michael Buesch
  2007-03-23 20:31               ` Johannes Berg
  2007-03-23 20:51               ` Jean Tourrilhes
  1 sibling, 2 replies; 18+ messages in thread
From: Michael Buesch @ 2007-03-23 20:27 UTC (permalink / raw)
  To: jt; +Cc: Chris Wright, Johannes Berg, linux-wireless, John W. Linville, stable

On Friday 23 March 2007 21:00, Jean Tourrilhes wrote:
> On Fri, Mar 23, 2007 at 12:36:43PM -0700, Chris Wright wrote:
> > * Jean Tourrilhes (jt@hpl.hp.com) wrote:
> > 
> > > 	The last thing is that I could not test those stuff myself,
> > > and the testing done for me was limited. I would be more confident if
> > > you were to give it a good beating before we push that into stable,
> > > because you know what to test.
> > 
> > That's useful info.  Have you had any luck (it looks pretty straight
> > forward)?
> 
> 	Let's be more clear. I tested properly on 32 bits. But, 32
> bits is not where there is issue, this issue is specific to 64 bits. I
> don't have a 64 bits platfor. It seems that few people doing wireless
> have access to 64 bits platform (actually, it seems most of them don't
> have access to SMP either), otherwise this would have been found many
> years ago.
> 	Johannes is one of the few having access to 64 bits stuff.

I finally have an USB ZD stick now, too. So I can test stuff, too.
Should I test this somehow?

-- 
Greetings Michael.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [stable] [PATCH] fix information leak in wireless extensions  on 64-bit platforms
  2007-03-23 20:27             ` Michael Buesch
@ 2007-03-23 20:31               ` Johannes Berg
  2007-03-23 20:51               ` Jean Tourrilhes
  1 sibling, 0 replies; 18+ messages in thread
From: Johannes Berg @ 2007-03-23 20:31 UTC (permalink / raw)
  To: Michael Buesch; +Cc: jt, Chris Wright, linux-wireless, John W. Linville, stable

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

On Fri, 2007-03-23 at 21:27 +0100, Michael Buesch wrote:

> I finally have an USB ZD stick now, too. So I can test stuff, too.
> Should I test this somehow?

If you can, build libiw and wireless tools 32-bit programs and enable
the debug dump of the actual message (see one of my original mails),
then run them with scanning. You'll get a wrong message and some zeroes
where in my example the padding was not zeroed.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [stable] [PATCH] fix information leak in wireless extensions on 64-bit platforms
  2007-03-23 20:27             ` Michael Buesch
  2007-03-23 20:31               ` Johannes Berg
@ 2007-03-23 20:51               ` Jean Tourrilhes
  2007-03-24 16:50                 ` Michael Buesch
  1 sibling, 1 reply; 18+ messages in thread
From: Jean Tourrilhes @ 2007-03-23 20:51 UTC (permalink / raw)
  To: Michael Buesch
  Cc: Chris Wright, Johannes Berg, linux-wireless, John W. Linville, stable

On Fri, Mar 23, 2007 at 09:27:17PM +0100, Michael Buesch wrote:
> On Friday 23 March 2007 21:00, Jean Tourrilhes wrote:
> 
> I finally have an USB ZD stick now, too. So I can test stuff, too.
> Should I test this somehow?

	Ok, here it goes.
	Pick the latest version of wtools. You may want to compile it
static to avoid the need to install it.

	To test the wpa patch, you need 32 bit userspace on 64 bit
kernel, and you need to try :
		'iwlist genie'

	To test the leak patch, you need a 64 kernel and any
userspace. You need two changes to enable the debugging code.
	1) Put '#define DEBUG 1' on top of iwlib.c.
	2) Change '#if 0' to '#if 1' line 783 of iwlist.c, at the
bottom of print_scanning_info().
	Compile everything.
	If you do a 'iwlist scan', it should dump the full content of
the stream. The first 4 bytes is the header (length + type). The next
4 bytes on 64 bits should be all zero.
	This is what I don't want to see :
[19:00:1B:8B:50:8A:35:E0:09:00:01:00:50:8A:35:F0:47:6F:6C:6F:73:4E:65:74:7A
	This is what I want to see :
[19:00:1B:8B:00:00:00:00:09:00:01:00:50:8A:35:F0:47:6F:6C:6F:73:4E:65:74:7A
	Note that du to endian considerations you may have some of
your bytes swapped.

> Greetings Michael.

	Good luck...

	Jean

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [stable] [PATCH] fix information leak in wireless extensions on 64-bit platforms
  2007-03-23 20:51               ` Jean Tourrilhes
@ 2007-03-24 16:50                 ` Michael Buesch
  2007-03-26 15:45                   ` Jean Tourrilhes
  0 siblings, 1 reply; 18+ messages in thread
From: Michael Buesch @ 2007-03-24 16:50 UTC (permalink / raw)
  To: jt; +Cc: Chris Wright, Johannes Berg, linux-wireless, John W. Linville, stable

On Friday 23 March 2007 21:51, Jean Tourrilhes wrote:
> On Fri, Mar 23, 2007 at 09:27:17PM +0100, Michael Buesch wrote:
> > On Friday 23 March 2007 21:00, Jean Tourrilhes wrote:
> > 
> > I finally have an USB ZD stick now, too. So I can test stuff, too.
> > Should I test this somehow?
> 
> 	Ok, here it goes.
> 	Pick the latest version of wtools. You may want to compile it
> static to avoid the need to install it.
> 
> 	To test the wpa patch, you need 32 bit userspace on 64 bit
> kernel, and you need to try :
> 		'iwlist genie'
> 
> 	To test the leak patch, you need a 64 kernel and any

Ok, so the most important question: Where to get the latest
versions of these patches? :)
I kind of lost track of what was agreed on and what's latest, etc..
Some link to the mail?

> userspace. You need two changes to enable the debugging code.
> 	1) Put '#define DEBUG 1' on top of iwlib.c.
> 	2) Change '#if 0' to '#if 1' line 783 of iwlist.c, at the
> bottom of print_scanning_info().
> 	Compile everything.
> 	If you do a 'iwlist scan', it should dump the full content of
> the stream. The first 4 bytes is the header (length + type). The next
> 4 bytes on 64 bits should be all zero.
> 	This is what I don't want to see :
> [19:00:1B:8B:50:8A:35:E0:09:00:01:00:50:8A:35:F0:47:6F:6C:6F:73:4E:65:74:7A
> 	This is what I want to see :
> [19:00:1B:8B:00:00:00:00:09:00:01:00:50:8A:35:F0:47:6F:6C:6F:73:4E:65:74:7A
> 	Note that du to endian considerations you may have some of
> your bytes swapped.
> 
> > Greetings Michael.
> 
> 	Good luck...
> 
> 	Jean
> 
> 

-- 
Greetings Michael.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [stable] [PATCH] fix information leak in wireless extensions on 64-bit platforms
  2007-03-24 16:50                 ` Michael Buesch
@ 2007-03-26 15:45                   ` Jean Tourrilhes
  0 siblings, 0 replies; 18+ messages in thread
From: Jean Tourrilhes @ 2007-03-26 15:45 UTC (permalink / raw)
  To: Michael Buesch
  Cc: Chris Wright, Johannes Berg, linux-wireless, John W. Linville

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

On Sat, Mar 24, 2007 at 05:50:21PM +0100, Michael Buesch wrote:
> On Friday 23 March 2007 21:51, Jean Tourrilhes wrote:
> > 
> > 	To test the leak patch, you need a 64 kernel and any
> 
> Ok, so the most important question: Where to get the latest
> versions of these patches? :)
> I kind of lost track of what was agreed on and what's latest, etc..
> Some link to the mail?

	I should send less e-mail to the mailing list so they are
easier to find :
		http://marc.info/?l=linux-netdev&m=117460953806538&w=2
		http://marc.info/?l=linux-netdev&m=117460988706771&w=2
	You will find the same patch attached to this e-mail.

	Jean

[-- Attachment #2: iw261_wpa_compat_ioctl.diff --]
[-- Type: text/plain, Size: 1504 bytes --]

diff -u -p linux/fs/compat_ioctl.j1.c  linux/fs/compat_ioctl.c
--- linux/fs/compat_ioctl.j1.c	2007-03-06 17:49:33.000000000 -0800
+++ linux/fs/compat_ioctl.c	2007-03-06 17:56:19.000000000 -0800
@@ -2553,11 +2553,15 @@ HANDLE_IOCTL(I2C_RDWR, do_i2c_rdwr_ioctl
 HANDLE_IOCTL(I2C_SMBUS, do_i2c_smbus_ioctl)
 /* wireless */
 HANDLE_IOCTL(SIOCGIWRANGE, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCGIWPRIV, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCGIWSTATS, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCSIWSPY, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCGIWSPY, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCSIWTHRSPY, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCGIWTHRSPY, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCSIWMLME, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCGIWAPLIST, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCSIWSCAN, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCGIWSCAN, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCSIWESSID, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCGIWESSID, do_wireless_ioctl)
@@ -2565,6 +2569,11 @@ HANDLE_IOCTL(SIOCSIWNICKN, do_wireless_i
 HANDLE_IOCTL(SIOCGIWNICKN, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCSIWENCODE, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCGIWENCODE, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCSIWGENIE, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCGIWGENIE, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCSIWENCODEEXT, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCGIWENCODEEXT, do_wireless_ioctl)
+HANDLE_IOCTL(SIOCSIWPMKSA, do_wireless_ioctl)
 HANDLE_IOCTL(SIOCSIFBR, old_bridge_ioctl)
 HANDLE_IOCTL(SIOCGIFBR, old_bridge_ioctl)
 HANDLE_IOCTL(RTC_IRQP_READ32, rtc_ioctl)

[-- Attachment #3: iw261_we22_64bit_usp_leak-3.diff --]
[-- Type: text/plain, Size: 15111 bytes --]

diff -u -p linux/include/linux/wireless.j1.h linux/include/linux/wireless.h
--- linux/include/linux/wireless.j1.h	2007-03-08 10:34:32.000000000 -0800
+++ linux/include/linux/wireless.h	2007-03-21 11:01:14.000000000 -0700
@@ -1,10 +1,10 @@
 /*
  * This file define a set of standard wireless extensions
  *
- * Version :	21	14.3.06
+ * Version :	22	16.3.07
  *
  * Authors :	Jean Tourrilhes - HPL - <jt@hpl.hp.com>
- * Copyright (c) 1997-2006 Jean Tourrilhes, All Rights Reserved.
+ * Copyright (c) 1997-2007 Jean Tourrilhes, All Rights Reserved.
  */
 
 #ifndef _LINUX_WIRELESS_H
@@ -85,7 +85,7 @@
  * (there is some stuff that will be added in the future...)
  * I just plan to increment with each new version.
  */
-#define WIRELESS_EXT	21
+#define WIRELESS_EXT	22
 
 /*
  * Changes :
@@ -221,6 +221,10 @@
  *	- Add IW_RETRY_SHORT/IW_RETRY_LONG retry modifiers
  *	- Power/Retry relative values no longer * 100000
  *	- Add explicit flag to tell stats are in 802.11k RCPI : IW_QUAL_RCPI
+ *
+ * V21 to V22
+ * ----------
+ *	- Prevent leaking of kernel space in stream on 64 bits.
  */
 
 /**************************** CONSTANTS ****************************/
@@ -1085,4 +1089,15 @@ struct iw_event
 #define IW_EV_POINT_LEN	(IW_EV_LCP_LEN + sizeof(struct iw_point) - \
 			 IW_EV_POINT_OFF)
 
+/* Size of the Event prefix when packed in stream */
+#define IW_EV_LCP_PK_LEN	(4)
+/* Size of the various events when packed in stream */
+#define IW_EV_CHAR_PK_LEN	(IW_EV_LCP_PK_LEN + IFNAMSIZ)
+#define IW_EV_UINT_PK_LEN	(IW_EV_LCP_PK_LEN + sizeof(__u32))
+#define IW_EV_FREQ_PK_LEN	(IW_EV_LCP_PK_LEN + sizeof(struct iw_freq))
+#define IW_EV_PARAM_PK_LEN	(IW_EV_LCP_PK_LEN + sizeof(struct iw_param))
+#define IW_EV_ADDR_PK_LEN	(IW_EV_LCP_PK_LEN + sizeof(struct sockaddr))
+#define IW_EV_QUAL_PK_LEN	(IW_EV_LCP_PK_LEN + sizeof(struct iw_quality))
+#define IW_EV_POINT_PK_LEN	(IW_EV_LCP_LEN + 4)
+
 #endif	/* _LINUX_WIRELESS_H */
diff -u -p linux/include/net/iw_handler.j1.h linux/include/net/iw_handler.h
--- linux/include/net/iw_handler.j1.h	2007-03-16 17:36:22.000000000 -0700
+++ linux/include/net/iw_handler.h	2007-03-21 11:01:09.000000000 -0700
@@ -1,10 +1,10 @@
 /*
  * This file define the new driver API for Wireless Extensions
  *
- * Version :	7	18.3.05
+ * Version :	8	16.3.07
  *
  * Authors :	Jean Tourrilhes - HPL - <jt@hpl.hp.com>
- * Copyright (c) 2001-2006 Jean Tourrilhes, All Rights Reserved.
+ * Copyright (c) 2001-2007 Jean Tourrilhes, All Rights Reserved.
  */
 
 #ifndef _IW_HANDLER_H
@@ -207,7 +207,7 @@
  * will be needed...
  * I just plan to increment with each new version.
  */
-#define IW_HANDLER_VERSION	7
+#define IW_HANDLER_VERSION	8
 
 /*
  * Changes :
@@ -239,6 +239,10 @@
  *	- Remove (struct iw_point *)->pointer from events and streams
  *	- Remove spy_offset from struct iw_handler_def
  *	- Add "check" version of event macros for ieee802.11 stack
+ *
+ * V7 to V8
+ * ----------
+ *	- Prevent leaking of kernel space in stream on 64 bits.
  */
 
 /**************************** CONSTANTS ****************************/
@@ -500,7 +504,11 @@ iwe_stream_add_event(char *	stream,		/* 
 	/* Check if it's possible */
 	if(likely((stream + event_len) < ends)) {
 		iwe->len = event_len;
-		memcpy(stream, (char *) iwe, event_len);
+		/* Beware of alignement issues on 64 bits */
+		memcpy(stream, (char *) iwe, IW_EV_LCP_PK_LEN);
+		memcpy(stream + IW_EV_LCP_LEN,
+		       ((char *) iwe) + IW_EV_LCP_LEN,
+		       event_len - IW_EV_LCP_LEN);
 		stream += event_len;
 	}
 	return stream;
@@ -521,10 +529,10 @@ iwe_stream_add_point(char *	stream,		/* 
 	/* Check if it's possible */
 	if(likely((stream + event_len) < ends)) {
 		iwe->len = event_len;
-		memcpy(stream, (char *) iwe, IW_EV_LCP_LEN);
+		memcpy(stream, (char *) iwe, IW_EV_LCP_PK_LEN);
 		memcpy(stream + IW_EV_LCP_LEN,
 		       ((char *) iwe) + IW_EV_LCP_LEN + IW_EV_POINT_OFF,
-		       IW_EV_POINT_LEN - IW_EV_LCP_LEN);
+		       IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
 		memcpy(stream + IW_EV_POINT_LEN, extra, iwe->u.data.length);
 		stream += event_len;
 	}
@@ -574,7 +582,11 @@ iwe_stream_check_add_event(char *	stream
 	/* Check if it's possible, set error if not */
 	if(likely((stream + event_len) < ends)) {
 		iwe->len = event_len;
-		memcpy(stream, (char *) iwe, event_len);
+		/* Beware of alignement issues on 64 bits */
+		memcpy(stream, (char *) iwe, IW_EV_LCP_PK_LEN);
+		memcpy(stream + IW_EV_LCP_LEN,
+		       ((char *) iwe) + IW_EV_LCP_LEN,
+		       event_len - IW_EV_LCP_LEN);
 		stream += event_len;
 	} else
 		*perr = -E2BIG;
@@ -598,10 +610,10 @@ iwe_stream_check_add_point(char *	stream
 	/* Check if it's possible */
 	if(likely((stream + event_len) < ends)) {
 		iwe->len = event_len;
-		memcpy(stream, (char *) iwe, IW_EV_LCP_LEN);
+		memcpy(stream, (char *) iwe, IW_EV_LCP_PK_LEN);
 		memcpy(stream + IW_EV_LCP_LEN,
 		       ((char *) iwe) + IW_EV_LCP_LEN + IW_EV_POINT_OFF,
-		       IW_EV_POINT_LEN - IW_EV_LCP_LEN);
+		       IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
 		memcpy(stream + IW_EV_POINT_LEN, extra, iwe->u.data.length);
 		stream += event_len;
 	} else
diff -u -p linux/net/core/rtnetlink.j1.c linux/net/core/rtnetlink.c
--- linux/net/core/rtnetlink.j1.c	2007-03-21 10:59:07.000000000 -0700
+++ linux/net/core/rtnetlink.c	2007-03-21 11:00:27.000000000 -0700
@@ -621,7 +621,8 @@ static int rtnl_getlink(struct sk_buff *
 		if (err < 0)
 			goto errout;
 
-		iw += IW_EV_POINT_OFF;
+		/* Payload is at an offset in buffer */
+		iw = iw_buf + IW_EV_POINT_OFF;
 	}
 #endif	/* CONFIG_NET_WIRELESS_RTNETLINK */
 
diff -u -p linux/net/core/wireless.j1.c linux/net/core/wireless.c
--- linux/net/core/wireless.j1.c	2007-03-08 14:20:22.000000000 -0800
+++ linux/net/core/wireless.c	2007-03-16 18:29:33.000000000 -0700
@@ -2,7 +2,7 @@
  * This file implement the Wireless Extensions APIs.
  *
  * Authors :	Jean Tourrilhes - HPL - <jt@hpl.hp.com>
- * Copyright (c) 1997-2006 Jean Tourrilhes, All Rights Reserved.
+ * Copyright (c) 1997-2007 Jean Tourrilhes, All Rights Reserved.
  *
  * (As all part of the Linux kernel, this file is GPL)
  */
@@ -76,6 +76,9 @@
  *	o Change length in ESSID and NICK to strlen() instead of strlen()+1
  *	o Make standard_ioctl_num and standard_event_num unsigned
  *	o Remove (struct net_device *)->get_wireless_stats()
+ *
+ * v10 - 16.3.07 - Jean II
+ *	o Prevent leaking of kernel space in stream on 64 bits.
  */
 
 /***************************** INCLUDES *****************************/
@@ -427,6 +430,21 @@ static const int event_type_size[] = {
 	IW_EV_QUAL_LEN,			/* IW_HEADER_TYPE_QUAL */
 };
 
+/* Size (in bytes) of various events, as packed */
+static const int event_type_pk_size[] = {
+	IW_EV_LCP_PK_LEN,		/* IW_HEADER_TYPE_NULL */
+	0,
+	IW_EV_CHAR_PK_LEN,		/* IW_HEADER_TYPE_CHAR */
+	0,
+	IW_EV_UINT_PK_LEN,		/* IW_HEADER_TYPE_UINT */
+	IW_EV_FREQ_PK_LEN,		/* IW_HEADER_TYPE_FREQ */
+	IW_EV_ADDR_PK_LEN,		/* IW_HEADER_TYPE_ADDR */
+	0,
+	IW_EV_POINT_PK_LEN,		/* Without variable payload */
+	IW_EV_PARAM_PK_LEN,		/* IW_HEADER_TYPE_PARAM */
+	IW_EV_QUAL_PK_LEN,		/* IW_HEADER_TYPE_QUAL */
+};
+
 /************************ COMMON SUBROUTINES ************************/
 /*
  * Stuff that may be used in various place or doesn't fit in one
@@ -1217,7 +1235,7 @@ static int rtnetlink_standard_get(struct
 		memcpy(buffer + IW_EV_POINT_OFF, request, request_len);
 		/* Use our own copy of wrqu */
 		wrqu = (union iwreq_data *) (buffer + IW_EV_POINT_OFF
-					     + IW_EV_LCP_LEN);
+					     + IW_EV_LCP_PK_LEN);
 
 		/* No extra arguments. Trivial to handle */
 		ret = handler(dev, &info, wrqu, NULL);
@@ -1229,8 +1247,8 @@ static int rtnetlink_standard_get(struct
 
 		/* Get a temp copy of wrqu (skip pointer) */
 		memcpy(((char *) &wrqu_point) + IW_EV_POINT_OFF,
-		       ((char *) request) + IW_EV_LCP_LEN,
-		       IW_EV_POINT_LEN - IW_EV_LCP_LEN);
+		       ((char *) request) + IW_EV_LCP_PK_LEN,
+		       IW_EV_POINT_LEN - IW_EV_LCP_PK_LEN);
 
 		/* Calculate space needed by arguments. Always allocate
 		 * for max space. Easier, and won't last long... */
@@ -1240,7 +1258,7 @@ static int rtnetlink_standard_get(struct
 		   (wrqu_point.data.length > descr->max_tokens))
 			extra_size = (wrqu_point.data.length
 				      * descr->token_size);
-		buffer_size = extra_size + IW_EV_POINT_LEN + IW_EV_POINT_OFF;
+		buffer_size = extra_size + IW_EV_POINT_PK_LEN + IW_EV_POINT_OFF;
 #ifdef WE_RTNETLINK_DEBUG
 		printk(KERN_DEBUG "%s (WE.r) : Malloc %d bytes (%d bytes)\n",
 		       dev->name, extra_size, buffer_size);
@@ -1254,15 +1272,15 @@ static int rtnetlink_standard_get(struct
 
 		/* Put wrqu in the right place (just before extra).
 		 * Leave space for IWE header and dummy pointer...
-		 * Note that IW_EV_LCP_LEN==4 bytes, so it's still aligned...
+		 * Note that IW_EV_LCP_PK_LEN==4 bytes, so it's still aligned.
 		 */
-		memcpy(buffer + IW_EV_LCP_LEN + IW_EV_POINT_OFF,
+		memcpy(buffer + IW_EV_LCP_PK_LEN + IW_EV_POINT_OFF,
 		       ((char *) &wrqu_point) + IW_EV_POINT_OFF,
-		       IW_EV_POINT_LEN - IW_EV_LCP_LEN);
-		wrqu = (union iwreq_data *) (buffer + IW_EV_LCP_LEN);
+		       IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
+		wrqu = (union iwreq_data *) (buffer + IW_EV_LCP_PK_LEN);
 
 		/* Extra comes logically after that. Offset +12 bytes. */
-		extra = buffer + IW_EV_POINT_OFF + IW_EV_POINT_LEN;
+		extra = buffer + IW_EV_POINT_OFF + IW_EV_POINT_PK_LEN;
 
 		/* Call the handler */
 		ret = handler(dev, &info, wrqu, extra);
@@ -1270,11 +1288,11 @@ static int rtnetlink_standard_get(struct
 		/* Calculate real returned length */
 		extra_size = (wrqu->data.length * descr->token_size);
 		/* Re-adjust reply size */
-		request->len = extra_size + IW_EV_POINT_LEN;
+		request->len = extra_size + IW_EV_POINT_PK_LEN;
 
 		/* Put the iwe header where it should, i.e. scrap the
 		 * dummy pointer. */
-		memcpy(buffer + IW_EV_POINT_OFF, request, IW_EV_LCP_LEN);
+		memcpy(buffer + IW_EV_POINT_OFF, request, IW_EV_LCP_PK_LEN);
 
 #ifdef WE_RTNETLINK_DEBUG
 		printk(KERN_DEBUG "%s (WE.r) : Reply 0x%04X, hdr_len %d, tokens %d, extra_size %d, buffer_size %d\n", dev->name, cmd, hdr_len, wrqu->data.length, extra_size, buffer_size);
@@ -1331,10 +1349,10 @@ static inline int rtnetlink_standard_set
 #endif	/* WE_RTNETLINK_DEBUG */
 
 	/* Extract fixed header from request. This is properly aligned. */
-	wrqu = &request->u;
+	wrqu = (union iwreq_data *) (((char *) request) + IW_EV_LCP_PK_LEN);
 
 	/* Check if wrqu is complete */
-	hdr_len = event_type_size[descr->header_type];
+	hdr_len = event_type_pk_size[descr->header_type];
 	if(request_len < hdr_len) {
 #ifdef WE_RTNETLINK_DEBUG
 		printk(KERN_DEBUG
@@ -1359,7 +1377,7 @@ static inline int rtnetlink_standard_set
 
 		/* Put wrqu in the right place (skip pointer) */
 		memcpy(((char *) &wrqu_point) + IW_EV_POINT_OFF,
-		       wrqu, IW_EV_POINT_LEN - IW_EV_LCP_LEN);
+		       wrqu, IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
 		/* Don't forget about the event code... */
 		wrqu = &wrqu_point;
 
@@ -1483,7 +1501,7 @@ static inline int rtnetlink_private_get(
 		hdr_len = extra_size;
 		extra_size = 0;
 	} else {
-		hdr_len = IW_EV_POINT_LEN;
+		hdr_len = IW_EV_POINT_PK_LEN;
 	}
 
 	/* Check if wrqu is complete */
@@ -1514,7 +1532,7 @@ static inline int rtnetlink_private_get(
 		memcpy(buffer + IW_EV_POINT_OFF, request, request_len);
 		/* Use our own copy of wrqu */
 		wrqu = (union iwreq_data *) (buffer + IW_EV_POINT_OFF
-					     + IW_EV_LCP_LEN);
+					     + IW_EV_LCP_PK_LEN);
 
 		/* No extra arguments. Trivial to handle */
 		ret = handler(dev, &info, wrqu, (char *) wrqu);
@@ -1523,7 +1541,7 @@ static inline int rtnetlink_private_get(
 		char *	extra;
 
 		/* Buffer for full reply */
-		buffer_size = extra_size + IW_EV_POINT_LEN + IW_EV_POINT_OFF;
+		buffer_size = extra_size + IW_EV_POINT_PK_LEN + IW_EV_POINT_OFF;
 
 #ifdef WE_RTNETLINK_DEBUG
 		printk(KERN_DEBUG "%s (WE.r) : Malloc %d bytes (%d bytes)\n",
@@ -1538,15 +1556,15 @@ static inline int rtnetlink_private_get(
 
 		/* Put wrqu in the right place (just before extra).
 		 * Leave space for IWE header and dummy pointer...
-		 * Note that IW_EV_LCP_LEN==4 bytes, so it's still aligned...
+		 * Note that IW_EV_LCP_PK_LEN==4 bytes, so it's still aligned.
 		 */
-		memcpy(buffer + IW_EV_LCP_LEN + IW_EV_POINT_OFF,
-		       ((char *) request) + IW_EV_LCP_LEN,
-		       IW_EV_POINT_LEN - IW_EV_LCP_LEN);
-		wrqu = (union iwreq_data *) (buffer + IW_EV_LCP_LEN);
+		memcpy(buffer + IW_EV_LCP_PK_LEN + IW_EV_POINT_OFF,
+		       ((char *) request) + IW_EV_LCP_PK_LEN,
+		       IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
+		wrqu = (union iwreq_data *) (buffer + IW_EV_LCP_PK_LEN);
 
 		/* Extra comes logically after that. Offset +12 bytes. */
-		extra = buffer + IW_EV_POINT_OFF + IW_EV_POINT_LEN;
+		extra = buffer + IW_EV_POINT_OFF + IW_EV_POINT_PK_LEN;
 
 		/* Call the handler */
 		ret = handler(dev, &info, wrqu, extra);
@@ -1556,11 +1574,11 @@ static inline int rtnetlink_private_get(
 		if (!(descr->get_args & IW_PRIV_SIZE_FIXED))
 			extra_size = adjust_priv_size(descr->get_args, wrqu);
 		/* Re-adjust reply size */
-		request->len = extra_size + IW_EV_POINT_LEN;
+		request->len = extra_size + IW_EV_POINT_PK_LEN;
 
 		/* Put the iwe header where it should, i.e. scrap the
 		 * dummy pointer. */
-		memcpy(buffer + IW_EV_POINT_OFF, request, IW_EV_LCP_LEN);
+		memcpy(buffer + IW_EV_POINT_OFF, request, IW_EV_LCP_PK_LEN);
 
 #ifdef WE_RTNETLINK_DEBUG
 		printk(KERN_DEBUG "%s (WE.r) : Reply 0x%04X, hdr_len %d, tokens %d, extra_size %d, buffer_size %d\n", dev->name, cmd, hdr_len, wrqu->data.length, extra_size, buffer_size);
@@ -1641,14 +1659,14 @@ static inline int rtnetlink_private_set(
 	/* Does it fits in wrqu ? */
 	if((descr->set_args & IW_PRIV_SIZE_FIXED) &&
 	   (extra_size <= IFNAMSIZ)) {
-		hdr_len = IW_EV_LCP_LEN + extra_size;
+		hdr_len = IW_EV_LCP_PK_LEN + extra_size;
 		extra_size = 0;
 	} else {
-		hdr_len = IW_EV_POINT_LEN;
+		hdr_len = IW_EV_POINT_PK_LEN;
 	}
 
 	/* Extract fixed header from request. This is properly aligned. */
-	wrqu = &request->u;
+	wrqu = (union iwreq_data *) (((char *) request) + IW_EV_LCP_PK_LEN);
 
 	/* Check if wrqu is complete */
 	if(request_len < hdr_len) {
@@ -1675,7 +1693,7 @@ static inline int rtnetlink_private_set(
 
 		/* Put wrqu in the right place (skip pointer) */
 		memcpy(((char *) &wrqu_point) + IW_EV_POINT_OFF,
-		       wrqu, IW_EV_POINT_LEN - IW_EV_LCP_LEN);
+		       wrqu, IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
 
 		/* Does it fits within bounds ? */
 		if(wrqu_point.data.length > (descr->set_args &
@@ -1738,7 +1756,7 @@ int wireless_rtnetlink_get(struct net_de
 	iw_handler		handler;
 
 	/* Check length */
-	if(len < IW_EV_LCP_LEN) {
+	if(len < IW_EV_LCP_PK_LEN) {
 		printk(KERN_DEBUG "%s (WE.r) : RtNetlink request too short (%d)\n",
 		       dev->name, len);
 		return -EINVAL;
@@ -1822,7 +1840,7 @@ int wireless_rtnetlink_set(struct net_de
 	iw_handler		handler;
 
 	/* Check length */
-	if(len < IW_EV_LCP_LEN) {
+	if(len < IW_EV_LCP_PK_LEN) {
 		printk(KERN_DEBUG "%s (WE.r) : RtNetlink request too short (%d)\n",
 		       dev->name, len);
 		return -EINVAL;

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2007-03-26 15:48 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-23  9:06 [PATCH] fix information leak in wireless extensions on 64-bit platforms Johannes Berg
2007-03-23 13:42 ` Johannes Berg
2007-03-23 15:42   ` John W. Linville
2007-03-23 16:24     ` Jean Tourrilhes
2007-03-23 15:48   ` Jean Tourrilhes
2007-03-23 15:56     ` Johannes Berg
2007-03-23 16:13       ` Jean Tourrilhes
2007-03-23 16:35         ` [stable] " Greg KH
2007-03-23 16:53         ` Michael Buesch
2007-03-23 17:57           ` Jean Tourrilhes
2007-03-23 19:36         ` [stable] " Chris Wright
2007-03-23 20:00           ` Jean Tourrilhes
2007-03-23 20:05             ` Johannes Berg
2007-03-23 20:27             ` Michael Buesch
2007-03-23 20:31               ` Johannes Berg
2007-03-23 20:51               ` Jean Tourrilhes
2007-03-24 16:50                 ` Michael Buesch
2007-03-26 15:45                   ` Jean Tourrilhes

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.