* [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 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: [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: [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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).