netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jouni Malinen <j@w1.fi>
To: Jouni Malinen <j@w1.fi>
Cc: David Miller <davem@davemloft.net>,
	jouni.malinen@atheros.com, alex.williamson@hp.com,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT]: Networking (WEXT events and 64/32 compat)
Date: Wed, 17 Sep 2008 12:11:28 -0700	[thread overview]
Message-ID: <20080917191128.GA23239@hostap.isc.org> (raw)
In-Reply-To: <20080909040525.GA26151@hostap.isc.org>

On Mon, Sep 08, 2008 at 09:05:25PM -0700, Jouni Malinen wrote:
> OK. Interesting point here is that the old code was using IWEVCUSTOM
> which is defined as having header_type IW_HEADER_TYPE_POINT and so are
> the new IWEVASSOCREQIE and IWEVASSOCRESPIE. The only difference is in
> max_tokens specifying different maximum length for the data. Maybe the
> old code was also broken, but wpa_supplicant handled the bogus data
> without causing problems (text parsing failing instead of some
> parameters being set based on bogus binary data).

I was able to test this with a 64/32-bit setup and confirmed that both
IWEVCUSTOM and the new IWEVASSOCREQIE/IWEVASSOCRESPIE are indeed failing
when using 32-bit binary in userspace (and work with 64-bit). The length
field is parsed incorrectly for all these events.

wpa_supplicant has code for rejecting IWEVCUSTOM events that have too
large a value in the length field. However, same validation is not done
for IWEVASSOCREQIE/IWEVASSOCRESPIE (i.e., wpa_supplicant relies on
kernel providing the correct value for the length field). As the end
result, the new IWEVASSOCREQIE/IWEVASSOCRESPIE events will trigger a
segmentation fault in wpa_supplicant when the buffer is being read way
beyond its end.

I'll make wpa_supplicant validate the length field for all WEXT events
to avoid the crash. This was enough to make association work with the
reverted mac80211 patch since the values from these association info
events are not critical for many use cases.

Since we cannot fix the kernel code to handle the WEXT events for all
cases (e.g., 64-bit kernel and mix of 32-bit and 64-bit userspace
apps), I could consider adding a workaround in wpa_supplicant to handle
the 64-bit data being received in 32-bit app.. However, that would not
fix problems for anyone using older versions of wpa_supplicant.

Would it be acceptable to ever enable use of IWEVASSOCREQIE /
IWEVSSOCRESPIE in kernel if the workaround were available in new
wpa_supplicant versions? Or should we try to add a new WEXT event
type that uses fixed size for the length field and then replace the old
IWEVCUSTOM with the new type since IWEVCUSTOM does not work with
64/32-bit case (wpa_supplicant just knows how to avoid processing that
bogus event data)?

-- 
Jouni Malinen                                            PGP id EFC895FA

  parent reply	other threads:[~2008-09-17 19:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-27 23:46 [GIT]: Networking David Miller
2008-09-05 15:08 ` Alex Williamson
2008-09-05 17:45   ` Linus Torvalds
2008-09-05 18:17     ` John W. Linville
2008-09-09  2:44   ` Jouni Malinen
2008-09-09  2:46     ` David Miller
2008-09-09  2:55       ` Jouni Malinen
2008-09-09  3:43         ` David Miller
2008-09-09  4:05           ` Jouni Malinen
2008-09-09  4:15             ` David Miller
2008-09-09  5:34               ` Jouni Malinen
2008-09-17 19:11             ` Jouni Malinen [this message]
2008-09-17 20:11               ` [GIT]: Networking (WEXT events and 64/32 compat) David Miller
2008-09-18 13:41                 ` John W. Linville
2008-09-18 22:13                 ` Jouni Malinen
2008-09-09  3:08     ` [GIT]: Networking Alex Williamson
2008-09-09  3:06       ` Jouni Malinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080917191128.GA23239@hostap.isc.org \
    --to=j@w1.fi \
    --cc=akpm@linux-foundation.org \
    --cc=alex.williamson@hp.com \
    --cc=davem@davemloft.net \
    --cc=jouni.malinen@atheros.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).